Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-gre-mtu-04.txt

[Joe Touch]

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
fred.l.temp...@boeing.com


-----Original Message-----
From: Joe Touch [mailto:to...@isi.edu]
Sent: Tuesday, February 18, 2014 8:47 AM
To: Templin, Fred L
Cc: Ronald Bonica; int-area@ietf.org
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 <fred.l.temp...@boeing.com> 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
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area