Re: AD comments on draft-ietf-rohc-hcoipsec-10

On May 14, 2009, at 18:08, Magnus Westerlund wrote:

> 1. I find there is a lack of discussion of how to handle Path MTU for
> these ROHC inside of a IPsec SA. The issue to me is the variable size
> compressed packet. That makes the actual MTU seen on the ingress of  
> the
> processing to jump up and down depending on what type of ROHC packet  
> is
> created for a particular packet. To me it appears that the MTU with  
> ROHC
> enabled in a IPsec SA is less than without ROHC when sending IR.
>
> There must be some discussion about this issue. How it affects path  
> MTU
> discovery, what to do about it so that one don't get spurious IP
> fragmentation or MTU losses for packets with DF bit set.

Magnus,

thank you for the quite thorough review of the ROHCoIPsec documents.

Let me focus on this one comment right now as it is quite dear to my  
heart.
I definitely agree that the MTU variability caused by header  
compression merits discussion.
(I'm just now running into a different manifestation of it in 6lowpan.)

I'm just not sure the discussion should be done as part of ROHCoIPsec.
There are other applications of header compression in tunnels, e.g.  
4901, 4170.
As I mentioned, adaptation layers also might run into problems here;  
I'm not even sure basic ROHC (3095/5225) is immune to this problem if  
there are relevant MTU restrictions coming from L2 (normally, PPP has  
a larger MTU than Ethernet and so we just don't notice).

I'd prefer to have this discussion in a more general form.
This would probably involve (PL)PMTUD experts and HC experts, both  
from ROHC and maybe from INT WGs such as 6lowpan.
Clearly, there is enough related work about tunnels in TSVWG right now.

I would change my mind if there was something specific that ROHCoIPsec  
can do that does not apply to the other versions of this issue, but  
right now I'm lacking imagination what that could be.

Gruesse, Carsten