Joe, On Feb 18, 2014, at 1:08 PM, Joe Touch <[email protected]> wrote:
> > > 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 > Where is this specified (other than stated by you in your email with 2119 language)? This defeats the purpose of a configurable MTU, and frankly shows requirements that do not exist and are not met in real life. Take for example RFC 1812, Section 3.3.4., "MTU": The MTU of each logical interface MUST be configurable within the range of legal MTUs for the interface. Many Link Layer protocols define a maximum frame size that may be sent. In such cases, a router MUST NOT allow an MTU to be set which would allow sending of frames larger than those allowed by the Link Layer protocol. However, a router SHOULD be willing to receive a packet as large as the maximum frame size even if that is larger than the MTU. DISCUSSION ... Apologies as I have said the following on this list more than once, but to reiterate: if you consider a tunnel as a logical link, the "link max frame size" is 64k - tunnel encap. But that does *not* mean that's the MTU, nor that packets larger than the tunnel MTU need to be fragmented after encap because they fit this max link size. If the MTU is configured on an ethernet link to be 500 B, but the physical media can (capable) send larger sizes, what happens with a 1000B packet? > - 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. > Similarly, where is "preferred" specified? And these are segment sizes and not MTUs? Thanks, -- Carlos. > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
