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