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.ietf.org/archive/id/draft-i ... ecn-24.txt