On Sep 22, 2009, at 12:35, <Pasi(_dot_)Eronen(_at_)nokia(_dot_)com> wrote:
3) According to RFC 4224, ROHC segmentation does not work over
reordering channels. Thus, it seems suggesting that ROHC
segmentation could be used instead of pre-encryption fragmentation
(e.g. ipsec-extensions, Section 3.3) -- and in general, allowing
segmentation at all -- seems misguided (it's unnecessary
complexity that would be IMHO best left out).
Although I agree that ROHC segmentation is not a good idea, it is an
optional functionality in the spec. The implementer can decide
whether or not they want to code it.
If a vendor chooses not to implement the functionality, they can
hardwire the MRRU channel parameter to zero.
OK, let me phrase my question in another way: why does the spec
contain
a feature that does not really work? (Even as optional feature?)
Well, it actually does work.
RFC 4224, section 5.2.1 tells us that when a channel is reordering and
you don't notice, packets will be lost.
Now IPsec is a strange animal: It is reordering, but the order can be
reconstructed from the sequence number.
So a reassembler could (here really: SHOULD) use that to avoid
stitching together packets in the wrong order and then discarding them.
Is ROHC segmentation "better" than IP fragmentation?
It certainly has fewer of the problems of IP fragmentation.
It does require throwing some CPU at the data (it uses a CRC).
Because header compression creates a variable-MTU channel, being able
to segment in a pinch is a boon.
Since the ROHC framework has the functionality, and it is not hard to
make it work on IPsec, I would favor retaining it.
Gruesse, Carsten
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf