A few months ago a set of new RFCs were published @ IETF:
- RFC9330 Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service Architecture
- RFC9331 The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)
- RFC9332 Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)
- still in draft state: More Accurate Explicit Congestion Notification (ECN) Feedback in TCP

these RFCs define a solution for minimising queue buildup and therefore reducing queuing delay in congested networks. the core element of this is ECN marking and a so called "dual queue" coupled active queue management (Dual Coupled AQM) which allows "low latency" traffic with scalable congestion control to bypass queue building "legacy" traffic. Don't think of this like DSCP EF or dedicated low latency queueing: this is all about best effort traffic by default. and the most important feature of this dual arm mechanism is the coupling between the 'legacy' and 'L4S' queues: L4S traffic cannot dominate the link, it will not constrain the "regular" TCP flows in any way. the equal competition for bandwidth is still there (albeit TCP itself isn't truly fair).
the L4S traffic will have a very shallow queue, worth of a few milliseconds of packets, and if the queue length reaches the watermark, all packets will be marked to indicate the congestion to the receiver. then the receiver can count how many packets it received in a time window, and how many were ECN marked - thus establish not just the presence of a congestion in the forwarding path, but also the extent of the congestion, allowing the CCA to react very quickly and very accurately, compared to the existing delay+loss based CCAs.

The best implementation out there is freely available as a set of patches to the linux kernel, so probably importing these to the current code is doable.
why do i think this is so important?
Apple already has L4S support in IOS17/ipadOS17/macos14 for TCP and QUIC, and by the release of these this autumn will enable developers to turn their applications into L4S-capable simply by recompiling them with the up-to-date toolchain.
While many boast the Low latency aspect of L4S, usually linking it with AR/VR/ER applications, cloud rendered gaming solutions or a more traditional over-the-top real-time communication protocols, the other 2 L-s are equally important. we did many experiments comparing flows with L4S and classic CCA, and noticed that even non-real-time traffic can benefit from L4S: the ECN feedback is a very quick and accurate signal that can be used to enable the sender to "guess" the right bandwidth/rate, and thus reduce queue buildup and packet loss dramatically. the key was the scalable congestion control at the sender side.

and the best thing is: you don't need to have L4S everywhere in the forwarding path, only at the places where congestion is likely to occur, thus a phased deployment is totally doable.

L4S implementations are being worked on by the fixed and the mobile industry, cable labs is very active on this front, but apple, google, meta, nvidia are all there in the IETF hackatlons. i'd say Mikrotik would greatly benefit from having L4S enabled routerOS out on the market in 2023 - which would mean they're one of the first OEMs out there.

links to the documents:
https://www.rfc-editor.org/rfc/rfc9330.txt
https://www.rfc-editor.org/rfc/rfc9331.txt
https://www.rfc-editor.org/rfc/rfc9332.txt
https://www.ietf.org/archive/id/draft-i ... ecn-24.txt

How does one add votes?

I am at least very interested.

Kernel patches for L4S seems already under development

https://github.com/L4STeam/linux

What makes L4S superior to fq_codel and/or CAKE?

What makes L4S superior to fq_codel and/or CAKE?

A modified use of ECN supports congestion control algorithms that avoid queuing delays at the sender, thus eliminating the sawtooth variation in launching packets that you're likely familiar with. But it is a new architecture with the associated issues for its adoption. RFC 9330 is quite readable: https://datatracker.ietf.org/doc/rfc9330/

A modified use of ECN supports congestion control algorithms that avoid queuing delays at the sender, thus eliminating the sawtooth variation in launching packets that you're likely familiar with. But it is a new architecture with the associated issues for its adoption. RFC 9330 is quite readable: https://datatracker.ietf.org/doc/rfc9330/

FQ_Codel supports ECN bit flipping as well. I don't see how L4S makes sense for:
1. Backbone fibre networks
2. PON fibre networks
3. Or even LTE/5G

If anything, it seems L4S is pushed by the legacy coaxial cable companies who refuse to hop on to fibre optical networks.

I would prefer if MikroTik allows fq_codel offloading to ASIC — This would be an industry revolution and evolution as currently, not even Cisco, Juniper, Huawei, Nokia supports fq_codel on ASICs.

Heck, forget ASICs, MikroTik needs to add this first before any talk of algorithms comes into play:
https://blog.linuxplumbersconf.org/2011 ... ssions/171

I agree with all the features and comments written.


However, I really want MikroTik ASIC to reduce any more basic simple queue method such as pfifo, bfifo to the hardware level.

Even with or without fq_Codel, it should at least be processed on the side of a 'simple' queue asic today.


If this is achieved on the BNG side, it will be a huge success.

0) In general, I do recommend experimentation with these concepts. Get the L4S code - try it on your machines at home! But a few facts, where I will attempt to be unbiased. For the record, I originally backed an RFC3168 backward compatible version of this idea in the IETF, called SCE, but backed out of even that, after the red team showed how L4S in particular, re-introduced gross RTT unfairness where, in fq_codel, we in general manage to achieve the same bandwidth no matter if your destination is near or far. The diffserv stuff in cake I also deemed sufficient to handle most gaming needs. Ironically it turned at that another L4S component, the new NQB codepoint, cannot be emitted by windows platforms, which only support CS7, CS5, and CS1 (voice/video/background), which cake already supports. I plan to add NQB to cake at some point...

The design of L4S relentlessly attempts to give itself priority of all other traffic, and introduces backward compatibility problems across the internet. Something that attempts to document that, that may never make it to RFC status, but is desperately needed if an operator is to attempt to deploy it is here: https://datatracker.ietf.org/doc/draft- ... wg-l4sops/

The jury is very much out as to whether the L4S methods will better enable cloud gaming or not. A key component is that the bit twiddling of it and the NQB code land it in the DOCSIS-LL specific LL queue, which has an improved request/grant interval making cable almost competitive with fiber, reducing that r/g interval from about 10ms to 1ms. I wish very much that the docsis folk would just deploy that improved r/g interval rather than attempt to differentiate traffic in this way (as gpon and wireless tend already to be below 1ms)

See 0).

1) fq_codel in linux 6.1 has L4S support in it. It is 2 simple patches to backport, if you care. Presently a ce_threshold of about 2ms, maybe 2.5ms, is about right based on the published testing I have seen. Except, perhaps on virtualized instances, in which case, I really don't know. 8ms? Don't quote me. See 0) L4S was designed to be implemented more in hardware than software. A partial implementation in hardware is feasible if you can A) differentate traffic based on the ECN bits, and B) configure RED in a brick wall mode. I have not seen much that can do A). And if you can do B), but have no means to aqm or fq_codel the normal queue, you get a FIFO for regular traffic.

2) What is quite unclear in all the marketing about L4S is that its performance on normal, everyday traffic, like web,voip,gaming,etc, is *dismal* compared to fq_codel or cake in the general case, as normal traffic is both deprioritized and uses the single queued PIE AQM. So if you update your transport to use it, and update the bottleneck routers in between, you get at least some of the advantages promised for it, which is kind of a heavy lift. Otherwise it is step backwards from fq_codel or cake, which work with all existing transport congestion controls (such as reno/cubic/ledbat)

PIE alone is a step forwards from a FIFO. But, see: http://burntchrome.blogspot.com/2014/05 ... bloat.html

3) ALL the L4S code for linux (transports and AQMs) live outside the linux kernel mainline, (only available for linux 5.15) and there are significant barriers to adoption. Notably the codebase I reviewed two? (three?) years ago does not support GRO/TSO/GSO. Worse the dualpi AQM is explicitly *single threaded* in order for the dual-queue system to work at all - e.g. it does not scale across multicores correctly. Both of these are deal-killers, IMHO. The DCTCP transport concept (although perhaps not BBRv3) cannot possibly work with wifi prior to version 7. There was a raft of other problems the inadvertent red (SCE) team published code to duplicate as people attempted to implement it: https://github.com/heistp/l4s-tests?tab ... y-findings

Improvements since those benchmarks were published have happened. Research continues. I was pleased to see some progress on packet subwindows recently. I would rather like it if proponents and opponents benchmarked fq_codel vs dualpi on the hardware they have ported it to. Given that I primarily work on 6.8 right now, I am waiting for the submittal to the linux mainline, and a ton more code review, before I touch it. I sure as hell would not ship it in an embedded product until it gets more code review.

4) L4S-using transports, such as the apple one, will use ECN differently than RFC3168 ECN, but fq_codel as is, today, no patches, will, ultimately, twiddle the ECN bits and result in some kind of lossless signalling. My bet, personally, should L4S become a thing, given the huge backward compatability problem with RFC3168, that BBRv3 might become the righter thing, along with (ultimately) the fq_codel ce_threshold set to do L4S signalling (which at least does lossless signalling).

and, um, yea, BQL is really helpful for dualpi in software, too. BQL is the first step...

This is apparently getting imminent wider adoption. Learned about L4S from tech news today and after learning a bit it looks very promising.

Comcast/Xfinity has announced they are rolling it out: https://www.theverge.com/news/601100/co ... y-internet
Apple has had support in their OSs for a few months already and are encouraging developers to add support: https://www.youtube.com/watch?v=y6-Q449DlTQ

I basically only manage my home network, but I would suspect this to be a valuable feature for WISPs (and of course I'd want my home network to support it).

@dtaht - Good summary. Any guess on the current status of L4S among the key stakeholders? Can you picture a real-life scenario where BBRv3 coexists with fq_codel or L4S? And yeah, it would probably be a good idea to switch from in-house queue managers to BQL.