Re: Comments on current RoHC over IPSec draft
"Kristofer Sandlund" <[email protected]>
| Newsgroups | gmane.ietf.rohc |
|---|---|
| Message-ID | <A91F30A632473A47B40C18D2B107CA6F064E16BE@esealmw105.eemea.ericsson.se> |
Ertekin, Emre wrote on : >> MRRU - This parameter is unnecessary. The external interface of the >> IPSec device should be able to determine the MTU of its link and >> fragment as needed/necessary. None of the RoHCv2 PROFILES (found in >> RFC 5225) allow for the use of MRRU, so why use it? > > Fair comment. We'll remove this parameter. Hi, I haven't read the drafts in question nor the entire mail I'm replying to, I'd just like to point out that the statement above is incorrect. The following is a quote from 5225: The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU) MUST be set to 0, if the configuration of the ROHC channel contains at least one ROHCv2 profile in the list of supported profiles (i.e., the PROFILES parameter) and if the channel cannot guarantee in-order delivery of packets between compression endpoints. Therefore, it *is* allowed to use ROHC segmentation in v2, it is only disallowed if you have a reordering channel with v2 profiles. I'm not saying that ROHC segmentation is a very useful feature or that you have to allow it, I'd just like to avoid you making decisions based on an assumption that v2 *always* disallows segmentation. /k