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
