The congestion-notification conflict
The congestion-notification conflict
Posted Mar 24, 2019 17:28 UTC (Sun) by ajb (subscriber, #9694)Parent article: The congestion-notification conflict
I think it's premature to decide that SCE "better matches the values" of the Linux networking stack, however. As I understand it, in L4S, the dual-q mechanism is a transition mechanism, and the end state is that everyone - except for old stacks - end up in the second, low-latency, bucket. Whereupon the behaviour of the system is controlled by the end-hosts - very much how the Linux networking community would have it. Linux - if, and it's a big if, the patent issue is solved - would move to the second bucket very fast, give how quickly Linux development goes.
SCE, however, appears to rely on per-flow queueing (FQ) being implemented at any hop that could end up being the bottleneck. FQ is fine if its on your home router and thus under your control. But if it's implemented everywhere, then the network, not the end clients, are controlling the behaviour of the system.
The bufferbloat guys are pushing for FQ to be implemented everywhere. So far, it's not happened because the fast path of ISP-class switches are mostly implemented in ASICs, where queues are a limited resource. If it were to happen, you can be sure that the facility to weight those queues according the the commercial policy of the ISPs would also be implemented also. Despite FQ coming from the grass-roots, the difficulty implementing it at the ISP level may well be, paradoxically, something the open community should be grateful for.