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

[Sebastian Moeller <[e-mail]>]

Hi Bob,


> On Mar 15, 2020, at 12:12, Bob Briscoe <[e-mail]> wrote:
> 
> Sebastian,
> 
> Snipped all the comments you're agreeing with. Two responses below...
> 
> On 15/03/2020 00:03, Sebastian Moeller wrote:
>>> [BB] In the absence of the IP layer solving this problem, Gorry's group found that about 20% of end-systems are just clamping the IPv4 TCP max segment size lower than necessary. And for IPv6 most are just using the min segment size. See:
>>> 
>>> https://iain.learmonth.me/stuff/pubs/UsableMTU2018.pdf
>>> 
>>> Again only for TCP, middleboxes can edit the MSS advertised in each packet to fool the hosts into using a smaller max segment size.
>>> 
>> 	[SM] Yes, except given the issues with otherwise signaling too large packets a long a path, that might still be the cleanest solution...
> 
> [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...


> 
>>> PLPMTUD solves this problem end-to-end (see [RFC4821] for TCP etc. and [draft-ietf-tsvwg-datagram-plpmtud] not yet published for UDP). However, where a tunnel already solves the problem (sub-optimally) for IPv4 using fragmentation, I can't imagine that anyone would disable it, because it is still necessary and it still works.
>>> 
>> 	[SM] Well transient fragmentation (where the tunnel endpoints create the appearance of no fragmentation) comes at a considerable processing cost, and carrying fragments (especially in degenerate cases like your caida example above) skews the payload/overhead ratio badly (by artificially blowing up the packet rate), so I am confident tunnel operators would be happy to be able to drop that crutch in a heart-beat, IF they could be sure it would not be required anymore (or in a belts and suspender fashion, would keep the mechanism operational but would use PLPMTUD to make it unlikely that fragmentation actually is triggered)
>> 
>> 
>> 
> [BB] Just need to point out that the /operator/ cannot use PLPMTUD to make triggering fragmentation unlikely.

	[SM] The operator can however make sure its tunnels can transport ~1500 Byte ethernet payload equivalent payloads, at which points in all likelihood the tunnel will not cause additional fragmentation and the whole issue (if an ECN AQM is operatin on the tunneled packets) becomes some one else's problem.

> That has to be done at the origin sender. That's precisely why operators don't drop this crutch - because they can't be sure the sender has their own crutch.

	[SM] The operator could just drop packets if they would require fragmentation... or functionally make a fragmentation requirement exceedingly unlikely... But I accept that that is a log standing issue that probably has no solution that is all three of simple/robust, cheap and fully backward compatible...

But I do not see this as a big problem for either L4S or SCE as none of these tunnels currently uses an ECN-AQM there is next to zero legacy and hence tunnel operators can be taught to properly deal with ECN bits at the defragmentation and decapsulation stages. Sure, L4S seems coved by the existing rules (but assumes that defragmenter/decapsulators actually follow these rules!) but the rule changes for SCE seem rather straight forward to me.


BTW, I am puzzled about your claim, that L4S was carefully designed to avoid this issue for two reasons:
a) while according to the current RFCs CE-marks from a fragmented outer tunnel should propagate correctly into the inner packets ECN field on decapsulation there is little proof that all deployed tunnel defragmenting decapsulators actually do so correctly, and

b) this seems less of a conscious design decision and more a fortunate side-effect of selecting to change the meaning of CE, as far as I can see the strongest rationale for doing that was to be able to just hoist the DCTCP work into the common internet. Or do you claim that you opted to overload the CE codepoint specifically to deal wit fragmenting tunnels with ECN-using AQMs?


Best Regards
	Sebastian

> 
> 
> 
> 
> Bob
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/