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

[Joseph Touch <[e-mail]>]

> On Mar 16, 2020, at 2:30 PM, Rodney W. Grimes <[e-mail]> wrote:
> 
>>> On Mar 16, 2020, at 2:12 AM, Sebastian Moeller <[e-mail]> wrote:
>>> 
>>>> [BB] I should add that PLPMTUD and clamping the max packet size complement each other. 
>>>> 
>>>> PLPMTUD without clamping would kill latency.
>>>> Clamping avoids triggering fragmentation, but smaller than max packet sizes are inefficient. 
>>>> Adding PLPMTUD eventually bumps up the MTU for each path to its max, removing the inefficiency.
>>> 
>>> 	[SM] Well, realistically the ONLY viable solution is to design all tunnels to allow the de facto real-world internet MTU of 1500 and just make sure the tunnel itself uses jumbo-frame capable links to make sure fragmentation is not required. But honestly, in our current context I still wonder whether an operator failing to implement a non-fragmenting tunnel will ever deploy an ECN-enabled AQM...
>> 
>> That won?t work either. Any tunnel that has an MTU of any type (e.g., even the max MTU for IP of 64KB) and can be used recursively either directly (X over X) or indirectly (X over Y over ? over X) MUST support fragmentation somewhere.
> 
> This is partially true, so long as the configuration of the networks that cause traffic to enter the inner tunnels use a proper MTU for that inner layer.  

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.

> This is a common problem with IPSec over PPPoE.  As long as you configure the sources(sender) to use a inner tunnel MTU no issue occurs.

You don’t always know where or when these are and doing this isn’t possible in some cases (see above; you’d end up claiming you support IPv6 but not supporting the min required MTU).

>  This is infact a very common situation with VPS's, often leading to end nodes with MTU's in the 14xx range.  In theory one could nest IPSec until the inner most MTU became the IPvX minimal MTU and so long as the inner most tunnel interface device had the properly adjusted MTU property no fragmentation would occur at any layer in the recursive tunnels.
> 
>> 
>> Intermediate recursion tunnels can implement fragmentation at any of the protocols. Directly recursive tunnels MUST implement fragmentation (because nobody else can in way that helps).
> 
> Again not always true.  One can properly configure things such that no fragmentation on the inner tunnel occurs by applying MTU's at the ends (usually the encap/decap points).

See above for a counterexample.

> 
>> Bob?s doc has the (IMO) correct approach - tunnels are a pair of devices that both do work.
> 
> This would be ideal, but even in todays internet Tunnels are riddled with MTU issues.

IMO, largely because of mistakes as were quoted before - e.g., ignoring DF and trying to fragment the arriving packet rather than fragment/reassembly at the tunnel edges.

> 
> Further note my assertions above do not apply to arbitrary tunnels between unknown end systems, only to tunnels between known end systems, which I believe is the norm.

I don’t know what this refers to; a tunnel is often between endpoints that don’t do a lot to coordinate in advance other than know they are there.

Joe