[Bloat] [tsvwg] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Sebastian Moeller]

> On Mar 20, 2019, at 23:31, Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
>> On 21 Mar, 2019, at 12:12 am, Sebastian Moeller <moeller0 at gmx.de> wrote:
>> 
>> they see 20ms queue delay with a 7ms base link delay @ 40 Mbps
> 
> At 40Mbps you might as well be running Cake, and thereby getting 1ms inter-flow induced delay; an order of magnitude better.  And we achieved that o a shoestring budget while they were submarining for a patent application.
> 
> If we're supposed to be impressed…

Nah, there is this GEM:


Comparing Experiments 5, 7 with 6, 8, we can again conclude that our DualQ AQM very much approximates the fq CoDel AQM without the need for flow identi- fication and more complex processing. The main ad- vantage is DualQ’s lower queuing delay for L4S traffic.

So for normal traffic is is worse than fq_codel and better for traffic that does behave TCP-friendly, for which it was bespoke made. So at least they shoud have pimped fq_codel/cake to emit their required CE marking regime and do a test against that, if the goal is to compare apples and apples. I note that they do come into this with a grudge against fq "Per-flow queuing:  Similarly per-flow queuing is not incompatible with the L4S approach.  However, one queue for every flow can be thought of as overkill compared to the minimum of two queues for 
all traffic needed for the L4S approach.  The overkill of per-flow queuing has side-effects:" followed by a list of 4 more or less straw-man arguments. Heck these might be actually reasonable arguments at their core, but the short description in the RFC is fishy.
I believe the coupling between the two queues to be clever and elegant, but the whole premise seems odd to me. What they should have done, IMHO is teach their AQM something like SCE so it can easily react to CE and drops in a standard compliant TCP-friendly fashion, and only do the clever window/rate adjustments if the AQM signals ECT(1), add fair queueing to separate the different TCP variants behavior from each other, and bang no classification bit needed. And no patent (assuming the patent covers the coupling between the two queues)... I am sure I am missing something here, it can not be that simple.


Best Regards
	Sebastian

P.S.: How did the SCE-Talk go, interesting feed-back and discussions?



> 
> - Jonathan Morton
>