> > As Tero pointed out, there already is a way in ROHCoIPSec to send > > packets uncompressed. > > True. This would mean that the ROHCoIPsec path inherits the MTU of > the tunnel minus IPsec overhead. > But one might want to do better than that, making use of the fact that > for many packets IPsec tunneling overhead will be mostly cancelled out > by the inner ROHC compression. > > > The tunnel already keeps track of the MTU to > > compensate for the IP, ESP AH headers. So adding ROHC overhead should > > not a problem. Why not let the user decide whether or not to use ROHC > > segmentation, IP fragmentation or sending large packets through the > > uncompressed channel. > > ...where user is the person who configured the tunnel. > Sounds good to me. > As long as the signals that go to the end hosts allow them to do > (PL)PMTUD predictably. > > > We could list pros and cons and give some guidelines. > > ...which would pretty much elaborate on my previous sentence. > > Gruesse, Carsten
I agree with the discussion here. For the sake of these drafts, how about we add brief discussion on the following potential solutions: -- applying ROHC segmentation -- IP fragmenting packets post ROHC/IPsec processing Perhaps we simply document the benefits / considerations of these two alternatives. Also, now that ROHC segmentation is possible, we will also need to change some of the current wording (which specifies that segmentation is not used) in the IKEv2 and IPsec drafts. If we wanted to open it up further, we could also look at the following alternatives (however, these will deviate a bit more from what is currently in these drafts): --as Joe mentioned, if the ROHC packet exceeds the size of the MTU, just transmit the uncompressed packet. However, the drawback here is that ROHC is statefull compression algorithm... and we could run into problems in terms of context state invalidation (e.g., if the copy of the packet with no payload gets reordered or dropped in the unprotected domain). --inner fragmentation, where the packet is fragmented and then subsequently handed to the ROHC-enabled SA for compression and IPsec processing. However, AFAIK, I do not think that current ROHC profiles can compresses packets/packet fragments (e.g., MF is STATIC-KNOWN, and is always assumed to be 0), so such a solution could be a bit difficult as well. BR, Emre
