I think it's a fair point that even as close as the non-home side
of the access network, fq would need a lot of queues, and if you
want something in hardware it's going to be tricky. I hear
they're up to an average of ~6k homes per OLT.
I don't think the default assumption here should be that they
missed something obvious, but rather that they're trying to
solve a hard problem, and something with a classifier has a
legitimate value.
The question to me is about how much it breaks other things to
extract that value, and how much you get out of it in the end. If
you need fq and therefore the only viable place for AQM with good
results is on the home side of the router, that's got some bad
deployment problems too.
Just my 2c.
-Jake
On 2019-03-20, 15:56, "Sebastian Moeller" <moell...@gmx.de> wrote:
> 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
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
