Did someone say "tunnel MTU"? The problem is that the tunnel is a link, and the link needs to be consistent in its handling of packets of all sizes in order for end-to-end mechanisms like RFC4821 to work. Having the link sometimes able to pass, e.g., 1500 packets and other times not able to pass, e.g., 1480 packets is a recipe for confusion.
Someone said "use fragmentation", and we should take a look at that. Someone else said "but not all middleboxes pass fragments", and that may be true but I believe it is highly likely that even those middleboxes will pass *first* fragments (i.e., those with MF=1; Offest=0). Enter SEAL (draft-templin-seal). SEAL is specifically designed to ensure a solid MTU across the tunnel even if there may be fluctuations in MTU sizes *within* the tunnel. SEAL works by sensing outer IP fragmentation within the tunnel then adjusting its sizing parameters for SEAL segmentation accordingly. So, let's say that we set a static MTU of 1500 on the tunnel. Within the tunnel, the IPsec encapsulations and rohc headers are added to inflate the size of the packet beyond 1500. We now introduce the SEAL header as a thin layer inserted as: IP(inner)/ESP/SEAL/UDP/IP(outer) All SEAL is doing is inserting fields for controlling a mid-layer segmentation and reassembly process that occurs above the outer IP fragmentation layer but below the inner IP fragmentation layer. Another name for it is link adaptation. When a packet is sent into the tunnel, and the path MTU within the tunnel is not yet known, SEAL at the tunnel egress will listen for any outer IP fragmentation occurring within the tunnel and send a report back to the tunnel ingress. The ingress will automatically adjust its SEAL segment size to tune out the outer IP fragmentation, and the inner IP layer will continue to see a solid 1500 MTU. This means that DF=0 in the outer IP header always. Fred [email protected] > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, May 19, 2009 11:15 AM > To: Joe Touch > Cc: [email protected]; Carl Knutsson; [email protected]; TSV Area > Subject: Re: [tsv-area] [rohc] Path MTU discovery when having varying MTU > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, all, > > Here's what I'm wondering: > > - ----------------- > > Does ROHC allow through packets that are not ROHC-tagged? > > If so, the following may be a way forward: > > When ROHC gets a packet that would have fit without ROHC, but won't now > (i.e., a packet that needs to be sent with the full header to resync > state AND needs to be tagged with the stream ID to enable that sync), then: > > a) send the packet without ROHC > > b) send a copy of the packet with no payload > with the ROHC tags > > (b) is to resync the state > (a) is to get the payload with the full MTU through when it won't > otherwise fit > > Note that (b) is needed because a source may be sending a large flow of > MTU-sized packets, and there would be no way to send resync state otherwise. > > This has the net effect of doing "fragmentation" except that it doesn't > fragment - either piece can be lost, and no reassembly is needed. > > Would this suffice? > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkoS9xEACgkQE5f5cImnZrv6pwCgqxCtz8ipEaChzeQAjaAVbMZL > 1koAoKfN+hUua46yBG/XqMMNg3+MnS7S > =Jtb2 > -----END PGP SIGNATURE-----
