> On Mar 20, 2019, at 23:31, Jonathan Morton <chromati...@gmail.com> wrote:
>
>> On 21 Mar, 2019, at 12:12 am, Sebastian Moeller <moell...@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
>
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
