Re: [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Jonathan Morton <chromatix99@gmail.com>]

> On 15 Mar, 2019, at 3:01 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
> 
> That said, having read through the L4S architecture description and the related appendices of draft-ietf-tsvwg-ecn-l4s-id-05 I came to the conclusion, that this is a mess.
> 
> The L4S project proposes a really wide-ranging change of basically the internet (but allow a concurrent operation with legacy probably to cater to the fact that an internet-wide flag-day seems daunting to organize). But then they chicken out when figuring out how to differentiate between their new and the old by proposing to use ECT(1)…

I think I would be less annoyed by L4S if it proposed to assign a DSCP or three to identify its traffic.  In fact, I'd be interested to hear a defence of why DSCP identification of L4S flows was *not* adopted.  I suspect it would revolve around the widespread practice of re-marking DSCPs by ISPs, which renders DSCP too unreliable for L4S' purposes.

But using the ECN field for this purpose is *also* unreliable, because it is *intended* to be altered on route (in prescribed ways).  In particular, both ECT codepoints can be replaced by CE, erasing the distinction between them when it comes to choosing which half of a "dual queue" AQM to pass it through.  I'm not convinced they've spent very much of the past several years thinking about that.

Fortunately, L4S flows should work with flow-isolating AQMs (including Cake) without modifying the latter, and without needing to specifically identify which flows are L4S or otherwise.  That really says more about the robustness of proper flow isolation than anything else.  But Codel-type AQMs don't provide the ideal ECN signal for L4S (and nor do RED-type AQMs without specific tuning for L4S), and any single-queue AQM is going to end up with L4S flows outcompeting standard ones quite seriously.

Since very little "big iron" hardware supports flow-isolating AQM so far, that puts a damper on any "incremental deployment" argument to be made for L4S, even if they claim their dual-queue AQM is easier to implement at high link rates than full flow isolation.  The fact is that either dual-queue or flow-isolation is required in middleboxes *before* endpoint deployment of L4S can begin.

SCE explicitly avoids these problems, as both SCE-aware endpoints and SCE-aware middleboxes can safely be deployed without waiting for each other.  Work remains on figuring out precisely how SCE information should be produced and consumed, and verifying that the resulting system behaves as intended when fully deployed - but its interaction with existing deployed hardware and software is explicitly defined to be benign.

 - Jonathan Morton