Re: [rohc] Path MTU discovery when having varying MTU

Carsten Bormann <[email protected]> Tue, 19 May 2009 12:59:50 +0200
Newsgroups gmane.ietf.tsv-area,gmane.ietf.rohc
Message-ID <[email protected]>
> 2. Set a commonly supported ROHC MTU for the tunnel and use ROHC
> segmentation to handle the packets that gets expanded beyond PMTUD.
> [...] Not
> certain that the ROHC segmentation mechanism can work over reordering
> transports.

As Carl pointed out, ROHC segmentation is efficient only for non- 
reordering links.
It is similar to AAL5, but does not use a length field.
Assuming the CRC is effective, it responds to undetected reordering  
with dropping the (reassembled) packet(s) affected with a likelihood  
of p ≈ 1-2**-32 (and delivering a bad one with q ≈ 2**-32).
I'm not happy about the security implications if it is not.

However, the IPsec sequence number might be good enough to reliably  
detect reordering or even to resequence before ROHC reassembly.  I  
think that might be the right thing to do, as ROHC segmentation is  
much better than IP fragmentation on a non-reordering link.

So there *was* something specific that ROHC could bring to the table...

The remaining problem is that the compressor needs to know the tunnel  
MTU.

On ROHC, I wrote:

> So what would you want the compressor to do?
> Run PLPMTUD (probes can be done by occasionally compressing badly*) on
> the tunnel and reject (ICMP unreachable/Frag needed) all DF/IPv6
> packets that would not fit with worst-case expansion?
> Probably safe, but somewhat expensive.
> [...]
>
> *) Yes, this needs way more text.
> You would need to compress badly whenever compressing a packet that,  
> badly compressed, would not fit the currently established safe  
> PMTU.  That unfortunately tends to shrink while compressing well,  
> which ROHC tends to do :-)

So let's replace that with:

> Run PLPMTUD (probes can be done by occasionally compressing badly*) on
> the tunnel and ROHC-segment all DF/IPv6 packets that would not fit  
> with worst-case expansion.
> *) This can be done by sending the packet on a separate CID with an  
> IR, with some impact on compression efficiency on the original CID.

Does that work?

Gruesse, Carsten