Re: [IPsec] [rohc] Comments on current RoHC over IPSec draft

["Carl Knutsson" <carlknut at gmail.com>]

Emre,

I believe MRRU should stay. I think we should have very good reasons
before we remove it. We should not make any assumptions about the link
layer. For some users it may more be convenient to use the ROHC
segmentation instead of fragmentation in other layers. Why would we
not allow it? Both the ROHCoIPSec draft and the framework already
discusses ROHC segmentation. The ROHCoIPSec drafts is quite clear
about the disadvantages with ROHC segmentation.

I agree with Robert that the MAX_HEADER parameter should be removed.
We have agreed on a set of negotiation parameters for the ROHC
framework (RFC 3095 and RFC 4995). All other parameters must be
negotiated within the protocol. If the MAX_HEADER parameter is really
needed, it should be included in the ROHC framework and not in
ROHCoIPSec drafts. If it becomes a problem for future ROHC profiles,
it could be solved by something similar to CONTEXT_MEMORY feedback
option for v2.

/Calle

On Mon, Sep 22, 2008 at 9:46 AM, Kristofer Sandlund
<kristofer.sandlund at ericsson.com> wrote:
>
> 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
> _______________________________________________
> Rohc mailing list
> Rohc at ietf.org
> https://www.ietf.org/mailman/listinfo/rohc
>
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec