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