Some background to this: after the L4S/TCP Prague/and dualpi experiments appeared stalled out indefinitely in the IETF, and with our own frustration with IETF processes,
bufferbloat.net project members publicly formed our own working group to look into the problems with ecn, back in august of last year.
Its charter is here:
https://www.bufferbloat.net/projects/ecn-sane/wiki/
We were unaware, until last month, that the cable industry had 16 months back gone and formed its own private working group also, and was intending to turn the tcp prague/l4s/dualpi IETF "experiments" into an actual DOCSIS standard.
Our SCE proposal appears to be backward compatible with the existing 10s-100s of millions of ecn-enabled fq_codel[1] and sch_cake[2] deployments, and doesn't require any changes to any RFC3168 tcps (or any tcp-friendly congestion control) at all in order to basically work. tcp-prague is subtly incompatible with that, and dualpi, more so. Our proposal is different also, it proposes some receiver side changes in order to get the full benefit of SCE while remaining backward compatible with the existing meaning of the CE codepoint.
In either case, either approach essentially permanently redefines the ECT_1 codepoint incompatibly, once and for all, and for all time. This is a final battle over the meaning of a single bit in IP, and I expect the debates to be as difficult as the ones described in
https://www.ietf.org/rfc/ien/ien137.txt - I would really, really, really prefer that they stay technical and not veer into politics, but I have little hope for that.
The members of the ecn-sane working group are delighted to finally hear that running code for tcp-prague might land this ietf, and look forward to finally testing the whole l4s/tcpprague/dualpi architecture in conjunction with the
flent.org 's and irtt's exhaustive suite of tests and servers in the cloud in the coming months, both against our existing, deployed, fq_codel, fq_pie, cake and pie derived solutions and our new SCE proposal. We hope to finally be able to write new tests for flent in particular, that can show tcpprague off in the ways that are important to those developing it. Flent has some basic dctcp tests, but nothing that can get down below a 20ms sample rate on modern hardware. (currently. It's easy to add tests, flent is written in python)
We also hope that more test tools and implementations in ns2 and ns3 show up for tcpprauge and dualpi show up soon also, from members of those projects.
Note: sunday's dual-pi linux submission was kicked back from the linux networking developers due to some technical and legal problems with linux net-next HEAD (
https://patchwork.ozlabs.org/patch/1054521/ ) , and I do hope that a corrected version lands soon, so we can safely test it with current versions of OpenWrt, etc.
Finally, running code. Will we find consensus?
Thx!
[2] sch_cake was available for 3 years out of tree and was mainlined last august, in linux 4.19. It is partially described by "Piece of CAKE: A Comprehensive Queue
Management Solution for Home Gateways" "
https://arxiv.org/pdf/1804.07617.pdf
A second paper describing its fq_codel-derived "cobalt" AQM algorithm is awaiting publication in a peer reviewed journal. It has been part of openwrt and the related sqm-scripts for many years and is widely deployed on multiple commercial products, such as those from eero and evenroute.
Cake has a docsis specific mode which we longed for cablelabs to evaluate.