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

[Holland, Jake]

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" <moeller0 at gmx.de> wrote:

    
    
    > 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
    > 
    
    _______________________________________________
    Bloat mailing list
    Bloat at lists.bufferbloat.net
    https://lists.bufferbloat.net/listinfo/bloat