Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Monday, July 01, 2013 1:18 AM > To: Templin, Fred L > Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > Subject: Re: [Int-area] New Version Notification for draft-bonica- > intarea-gre-mtu-00.txt > > Hi, Fred, > > On 6/26/2013 8:42 AM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:[email protected]] > >> Sent: Tuesday, June 25, 2013 8:10 PM > >> To: Templin, Fred L > >> Cc: Carlos Pignataro (cpignata); Ronald Bonica; Internet Area > >> Subject: Re: [Int-area] New Version Notification for draft-bonica- > >> intarea-gre-mtu-00.txt > >> > >> Hi, Fred, > >> > >> On 6/25/2013 3:32 PM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>> The constraint you seem to be missing is that RFC2460 only requires > >>> IPv6 nodes to reassemble as much as 1500 bytes. > >> > >> Right; sorry for not noticing that further. Had IPv4 on the brain. > > > > OK, but IPv4 also has a limit of minMRU=576. So, we have: > > > > IPv4 minMTU = 576 (*) > > IPv4 minMRU = 576 > > IPv6 minMTU = 1280 > > IPv6 minMRU = 1500 > > > > (*) Even though the specs say that IPv4 minMTU = 68, everyone > > seems to be saying that for practical purposes it is now 576. > > There needs to be a difference between the minMTU and the minMRU; if > not, then IP-in-IP tunnels will never succeed without a separate > fragmentation and reassembly layer - and although SEAL provides that, > we > currently do not require anything like that for X-in-X encapsulation.
With IPv4, there is no difference between minMTU and minMRU. Tunnels over IPv4 therefore set DF=0 to allow for in the network fragmentation if necessary. With IPv6, minMTU is smaller than minMRU but that does not guarantee that a packet sent by the ingress can be received by the egress without fragmentation. RFC2473 acknowledges this by using fragmentation at the ingress as a limiting condition for when the MTU within the tunnel becomes too small. This can happen for example if there is a 1280 MTU link within the tunnel, if there are nested encapsulations within the tunnel, etc. > >> ... > >>> Granted, my algorithm is asking GRE egress tunnel endpoints to > >>> configure a reassembly buffer size of 1500 *plus* the tunnel > >>> encapsulation overhead, which is more than RFC2460 ensures. > >> > >> Agreed. > > > > Right. So, then the fragmentation threshold for GRE over IPv6 > > needs to be (1500 - HLEN) instead of 1500. > > > >> ... > >>> Also think about it this way. Why should the tunnel work hard to > >>> pass a packet that is larger than 1500 bytes and also larger than > >>> the minimum link MTU within the tunneled path when the source could > >>> instead adjust the size of the packets it is sending downward? > >> > >> That's not a good argument. I agree that all that need be satisfied > is > >> the largest reassembled IPv6 packet, but not that we should assume > the > >> source can or will adjust downward - if that were the case, you > could > >> ignore the overhead of GRE and just claim that the MTU is 1280. > > > > In my lab, my implementation sends a single packet for packet > > sizes no larger than (1280 - HLEN). For packets that are larger > > than (1280 - HLEN) but no larger than 1500, it fragments the > > packet into two pieces and sends both pieces to the tunnel far > > end which then needs to reassemble. But, reassembly will be > > delayed by the inter-packet delay plus the time it takes to > > run the reassembly routine, and the delay is measurable. So, > > we really only want to use frag/reass when we absolutely have to. > > My view is that discovering the path MTU for the purposes of avoiding > frag/reassembly is either necessary or an optimization (such as you > mention above, to avoid delays and conserve resources). That's in > keeping with the "work first, optimize later" approach of the Internet. > > So frag/reassemble unless you CANNOT. Send too-big messages back to > help > the system optimize. But never deliberately drop anything you could > have > sent with frag/reassembly. What the SEAL approach fosters is a natural transition to larger packets where packets up to 1500 are accommodated using fragmentation if necessary but larger packets are allowed through in one piece as long as they fit the available MTU. Then, hosts can reasonably assume that their 1500 packets will get through, but to send anything larger than that they should use RFC4821. The hosts will notice that they get better performance using larger packets, and we will be well on our way to an 8KB Internet. Thanks - Fred [email protected] > Joe > > > > > Thanks - Fred > > [email protected] > > > >> Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
