Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

[Joe Touch <[e-mail]>]

> On Mar 16, 2020, at 10:22 PM, Rodney W. Grimes <[e-mail]> wrote:
> 
> 
>> 
>>>> On Mar 16, 2020, at 8:09 PM, Rodney W. Grimes <[e-mail]> wrote:
>>> 
>>>> 
>>>> 
>>>>> On Mar 16, 2020, at 2:42 PM, Jonathan Morton <[e-mail]> wrote:
>>>>> 
>>>>>> On 16 Mar, 2020, at 11:38 pm, Joseph Touch <[e-mail]> wrote:
>>>>>> 
>>>>>> That?s not always possible. If the net runs over minimal IPv6 links, there?s no way to ensure a traffic can support 1280B packets over 1280B tunnels.
>>> 
>>> True, not always possible, but very often practical and done as minimal IPv6 links generally only exist inside of tunneled tunnels :-)  ((Ie, GRE -> IPSec -> PPPoE))
>>> 
>>>>> 
>>>>> I think the 1280B minimum was intended to allow for the possibility of running through tunnels on conventional 1500B physical networks.
>>>> 
>>>> Actually, the 1280B is the path min; the receiver min is 1500B exactly to allow for this sort of frag/reassembly (where a tunnel egress *is* such a receiver). The 1500B comes from Ethernet; the 1280B is smaller deliberately.
>>> 
>>> receiver min?  I am not familiar with that term.
>> 
>> EMTU_R as defined in RFC 1122. See also draft-ietf-intarea-tunnels
> 
> EMTU_R as defined in RFC 1122 is greater than or equal to 576, not 1500 as you stated.

The term is defined originally in RFC1122. The 576 value applies to IPv4. It is 1500B in RFC8200 for IPv6.

> 
>> 
>>> And as you state 1500B no doubt comes from the Ethernet specification.
>>> 
>>> I shall endorse Jonathans position with this:
>>>    The 1280 IPv6 minMTU originated from a November 14, 1997 mailing
>>>    from Steve Deering to the IPng mailing list, which stated:
>>>    "In the ipngwg meeting in Munich, I proposed increasing the IPv6
>>>       minimum MTU from 576 bytes to something closer to the Ethernet MTU
>>>       of 1500 bytes, (i.e., 1500 minus room for a couple layers of
>>>       encapsulating headers, so that min- MTU-size packets that are
>>>       tunneled across 1500-byte-MTU paths won't be subject to
>>>       fragmentation/reassembly on ingress/egress from the tunnels, in most
>>>       cases).
>>> 
>>> So infact this is all meant to MINIMIZE fragmentation.
>> 
>> Except that it doesn?t unless you KNOW that the path supports 1500B. But there?s no rule in IPv6 that the EMTU_S min is 1280B *AND* the links MUST support 1500B.
>> 
>> I.e., that?s why the EMTU_S min is 1500B - so you can reassemble when you don?t know otherwise. But even when IPv6 was created there were problems with PMTUD.
> 
> EMTU_S min is not 1500B, and infact 1122 says:
>    It is generally desirable to avoid local fragmentation and to
>    choose EMTU_S low enough to avoid fragmentation in any gateway
>    along the path.  In the absence of actual knowledge of the
>    minimum MTU along the path, the IP layer SHOULD use
>    EMTU_S <= 576 whenever the destination address is not on a
>    connected network, and otherwise use the connected network's
> 
> Again the intent here appears to be to avoid framentation along the path,
> and iirc is what lead the the path MTU being cached by the BSD kernels
> route table code, which is one mechansim used by people to deal with
> the path MTU problem and tunnels.

Nobody is arguing that fragmentation should be avoided where possible. However, there’s no way to avoid it at a tunnel ingress over the tunnel path unless somehow the ingress KNOWS that EMTU_S can be 1500b. It’s normally 1280 for IPv6. It’s only larger when the tunnel path is engineered that way over known links or when the ingress runs PLPMTUD. 

The choice of 1280 allows for the POTENTIAL to avoid fragmentation *IF* the path is known engineered for 1500B or PLPMTUD runs between ingress and egress. But that choice doesn’t ENSURE fragmentation is avoided.

Joe