Hi Joe, I can see that I am going to have to write a draft on generic tunnel fragmentation. It will be based on my e-mail from two messages ago. I have already written drafts on 6rd tunnel fragmentation and AERO tunnel fragmentation, and they are already consistent with the to- be-written draft on generic tunnel fragmentation. Your draft on GRE fragmentation can then also cite the generic tunnel fragmentation doc.
Thanks - Fred [email protected] > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, February 18, 2014 10:09 AM > To: Templin, Fred L > Cc: Ronald Bonica; [email protected] > Subject: Re: [Int-area] FW: New Version Notification for > draft-bonica-intarea-gre-mtu-04.txt > > > > On 2/18/2014 9:27 AM, Templin, Fred L wrote: > > Hi Joe, > > > > You seem to be talking past me - maybe it was because I wrote too much. > > The fragmentation story for tunnels is very simple as follows: > > Yes, IMO they are, and here's mine: > > - if a tunnel CAN transit a packet, it MUST try > > i.e., the MTU of a tunnel that uses IPv6 encapsulation > is 65535 - encapsulation headers > > - if a tunnel CANNOT transit a packet, it rejects it > > i.e., anything larger than "65535 - encap headers" > > Everything else mistakes MSS (maximum) for PSS (preferred). Preferred is > the min of the MSS's. An IPv6 tunnel limits MSS only insofar as packets > larger than 65535-headers cannot traverse it. > > So... > > > 1) IPv6 has a minimum MTU of 1280 bytes. So, packets that are no larger > > than this size MUST be accommodated even if a small amount of > > fragmentation is necessary. IPv4 has a much smaller minMTU, but > > IMHO tunnels SHOULD behave as if the IPv4 minMTU is also 1280. > > An IPv6 tunnel is a link to the IPv6 protocol. IPv6 requires that the > smallest MTU of all links must be no less than 1280. So agreed. > > > 2) Packets larger than 1500 bytes (with the exception of IPv4 packets > > with DF=0) should be allowed to sink or swim on their own. Tunnels > > therefore MUST NOT use fragmentation for packets larger than 1500. > > Completely disagree. The max size of the payload of GRE in IPv6 is much > larger than 1500. > > You're trying to do something at the tunnel layer that the path is > supposed to be in control of. > > > 3) Packets larger than 1280 but no larger than 1500 are in a "gray area" > > where the way the tunnel accommodates them depends on the specific > > tunnel orientation. In some cases the tunnel should send as a whole > > packet. In others, it should drop and send a PTB. In still others, > > it should fragment. The cases are easy to articulate. > > There is no grey area. Until the max payload of an IPv6 packet is > decreased, there's simply no justification to do other than the above. > > > That is really all there is to it. What is important to realize is > > that case 3) needs to be architected according to the specific tunnel > > orientation - there is no generic one-size-fits-all rule that can be > > applied to all tunnels in all orientations. > > First, if rules depend on orientations, then there would be no rule for > tunnels at all. You cannot specify the requirements of a tunnel if it > depends on network placement - that rule does not exist for any other > Internet component (excepting only endpoint vs. network, but that's > function, not just placement). > > Second, there is a rule. See above. > > Joe > > > > > > Thanks - Fred > > [email protected] > > > > > >> -----Original Message----- > >> From: Joe Touch [mailto:[email protected]] > >> Sent: Tuesday, February 18, 2014 8:47 AM > >> To: Templin, Fred L > >> Cc: Ronald Bonica; [email protected] > >> Subject: Re: [Int-area] FW: New Version Notification for > >> draft-bonica-intarea-gre-mtu-04.txt > >> > >> Hi, Fred, > >> > >> On Feb 17, 2014, at 10:51 AM, Templin, Fred L <[email protected]> > >> wrote: > >> > >>> Hi Ron, > >>> > >>> The document needs to talk about packet sizes for IP payload packets. > >> > >> Yes, and I'm hoping we can add additional detail. > >> > >> Here's my view: > >> > >> -- path MTU is based on the min of the largest packet each link in the > >> path can support > >> > >> -- links often transit packets larger than their native size, e.g., ATM's > >> MTU is 9K, not 48 bytes > >> > >> -- links do have a native transit size, though > >> > >> So there ought to be two very different concepts > >> > >> - MTU (maximum) > >> > >> - PTU (preferred) > >> > >> IMO, much of the confusion about how MTUs are handled by tunnels is based > >> on confusing MTU to mean > >> PTU. > >> > >> I.e., > >> > >> - a tunnel has a PTU based on avoiding ingress fragmentation > >> and egress reassemly > >> > >> - a tunnel as a MTU, which is the MTU of the path of the tunnel > >> minus the headers it adds at the ingress > >> > >>> For IP payload packets no larger than MINMTU bytes, the GRE tunnel > >>> MUST accommodate the packet even if a small amount of fragmentation > >>> is necessary. (Here, the mandatory MINMTU for IPv6 is 1280 and the > >>> recommended MINMTU for IPv4 is also 1280.) > >> > >> This artificially limits tunnel MTU based on trying to support a perceived > >> PTU, but doesn't match > PTU. > >> > >>> Beyond MINMTU, there needs to be a balance between avoiding path > >>> MTU related black holes for the source and avoiding excessive > >>> fragmentation at the GRE tunnel egress. > >> > >> If we really want to accomplish that, we need to flesh out the difference > >> between MTU and PTU and > >> teach our apps to focus on PTU, ala a new PLPTUD (vs. current PLMTUD). > >> > >> I don't think we should be guessing this at the time we specify the > >> tunnel, because the approach > >> varies based on what's transited (real IP packets or some other sort of > >> encapsulation, e.g., IPsec > in > >> UDP). > >> > >> > >>> This balance is situation > >>> dependent. For example, if the GRE tunnel ingress is located close > >>> to the source, it should be reasonable to expect that the source > >>> would be able to receive any ICMP PTB messages sent by the ingress. > >> > >> Tunnels transit packets; they're not connected to sources or destinations. > >> So are you proposing > that a > >> tunnel should now try to discover the length of the path in each direction > >> and handle different > >> addresses differently? IMO, that's worse than reassembly. > >> > >>> Or, if the GRE tunnel egress is located close to the destination, > >>> it should be reasonable to expect that the egress can perform a > >>> small amount of reassembly. > >> > >> Same problem, and worse- do you expect vendors to sell different tunnel > >> engines based on intended > >> traffic patterns? > >> > >> ---- > >> > >> In conclusion, I would urge this document to focus on MTU as the goal, at > >> which point the only > packets > >> that ought to be dropped at the ingress ought to be those that cannot be > >> encapsulated with another > >> IPv4 header, i.e., that exceed the *MAXIMUM* payload size. > >> > >> If we want to tune for preferred path size, we need to extend PLMTUD for > >> that purpose. > >> > >> Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
