Hi Joe, The constraint you seem to be missing is that RFC2460 only requires IPv6 nodes to reassemble as much as 1500 bytes. Nodes are permitted to reassemble more than that, but 1500 is all that can be expected unless there is specification stating that it needs to be more.
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. But, it will never ask for more than that. 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? Such "jumbos" should be dropped by the tunnel and not accommodated by a resource-intensive process such as frag/reass. "Take care of the smalls, and let the bigs take care of themselves." BTW, the algorithm I have articulated is exactly the SEAL algorithm. Thanks - Fred [email protected] > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, June 25, 2013 3:19 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:01 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:[email protected]] > >> Sent: Tuesday, June 25, 2013 2:38 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, > >> > >> ... > >>>> A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation > >> is. > >>>> > >>>> I.e., GRE over IP with no options has an MTU of 65535-40- > {gre_size}. > >>>> Beyond that it *cannot* reassemble. > >>> > >>> I have a slightly different view, but one that still involves > >>> fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU > >>> of 1280 bytes. > >> > >> In what it sends over IP (i.e., in the chunks it uses to transit > from > >> ingress to egress). There's no reason to impose that limit on what > it > >> receives at the ingress. > > > > What I am suggesting is that the tunnel ingress sets an indefinite > > MTU, meaning that all packets are admitted into the tunnel regardless > > of their size. But, see more below... > > > >>> But, to uphold the de facto Internet cell size of > >>> 1500 bytes we should extend this up to 1500. So, if the MTU within > >>> the tunnel is unknown and/or unknowable, then the ingress MUST use > >>> fragmentation to make sure that packets no larger than 1500 bytes > >>> get through - the egress then gets to reassemble. > >> > >> This is an artificial limit that is unnecessary. > > > > What I am after is a fragmentation threshold designed to set an > > upper bound on the amount the tunnel egress will have to reassemble. > > This also happens to be the size of packets that MUST make it through > > the tunnel. IPv6 says that this value must be set to 1280 at a > minimum. > > I am saying that it should be bumped up to 1500 to mirror the minimum > > MTU used on the vast majority of links in the Internet today. But, > see > > more below... > > You're introducing an artificial limit based on the assumption that GRE > should never transit more than the minimum, but there's no reason for > that limit; GRE is sourcing packets to the egress, and can easily > generate and reassemble fragments. The rest of the path may impose a > limit - such as based on transiting Ethernet, but there's no reason to > introduce that limit here. > > >> IMO, MTU is just that - "MAXIMUM". Not 'preferred'. So if GRE *can* > >> transit packets arriving at the ingress that are 65535-IP-GRE, why > >> should it do otherwise? > > > > What I am saying is that all packets are admitted into the tunnel > > regardless of their size, but the tunnel will use fragmentation only > > for those packets that MUST make it through to the other side, i.e., > > all packets that are no larger than 1500 bytes. > > Why? Why are you introducing that as an artificial constraint for GRE? > > > This means that the > > tunnel egress need only configure a reassembly buffer size of 1500 > > bytes plus the tunnel overhead. Packets larger than 1500 bytes will > > still make it through the tunnel (in one piece) if the MTU within the > > tunnel can accommodate that size. But, the most the ingress will ever > > ask the egress to reassemble is 1500 (plus overhead). > > IP reassembly requires tsupport for max-size IP packets, not just ones > whose sizes you like ;-) > > >> (yes, it *can* be configured lower if desired, just as with any > other > >> link, but there's no reason to assume 'lower than maximum' as a > >> default) > >> > >>> Packets larger than 1500 can be admitted into the tunnel > unfragmented > >>> and allowed to sink or swim on their own. > >> > >> Whether and how much GRE fragments what it receives at an ingress > ought > >> to be determined by its understanding of its own ingress-egress MTU > >> capability. However, those fragments are not directly related to > what > >> the tunnel can transit *because* the ingress can fragment and the > >> egress > >> can reassemble. > > > > Right. The egress has to reassemble whatever the ingress fragments. > > What I am saying is that the ingress put a conservative upper bound > > on the amount it will ever ask the egress to reassemble. > > If the egress supports IPv6, the upper bound is already 66635. Why are > you introducing a lower constraint when that's already required? > > >> Acting like the ingress and egress can't participate in > frag/reassembly > >> of the outer packet introduces an artificial limit to GRE tunnels. > If > >> that's what you want to do - or what has already been done - that's > >> fine, but *that* is what is suboptimal. > > > > No, I fully agree that *some* fragmentation and reassembly is > > necessary. I'm just saying that the ingress should set a limit > > on the most it would ever ask the egress to reassemble. But, > > that does *not* put an artificial limit on the tunnel MTU. > > But that's what you're doing; you will reject packets larger than 1500 > that transit, even though you can reassemble them (and you have to if > you implement IPv6 reassembly anyway). > > I understand what you're trying to save, but an IP encapsulation egress > is still required to support IPv6 host-side capabilities, so there's no > savings. > > >> > The ingress may or may not > >>> get ICMP PTBs if one of these is dropped, but the source should be > >>> using RFC4821 when it sends packets larger than 1500 bytes anyway, > >>> so loss of PTBs should not affect the hosts. > >> > >> Agreed on that point, but not the 1500-byte transit limit. > > > > Please reread the algorithm I proposed, Joe. What I am suggesting > > is an "infinite" tunnel ingress MTU - not a 1500 byte MTU. > > > > Thanks - Fred > > [email protected] > > > >> Joe > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
