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:
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. 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. 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. 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. 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
