L4S stands for Low Latency, Low Loss, and Scalable Throughput. It is defined in the IETF standard specification RFC 9330.
L4S is a specification/mechanism that enables lower latency delivery of packets over networks. To do that, it requires the ISP to have network infrastructure that is capable of marking packets dynamically during network congestion.
How does L4S work?
Network congestion may occur on the network path between the ISP to a user’s device in either direction. In such a case, there will be a few entities trying to use the same network resources but will be unable to do so due to limited network resources. These kinds of bottlenecks are usually found at the sender or the receiver – the user or the server on the other end. When the bottlenecks occur inside the network, they end up increasing latency and in the end cause packet losses.
L4S is a rather new entrant to the congestion control space which helps achieve consistently low network latencies. It does so by having end devices and servers mark their packets as ENC-Capable. This enables the infrastructure (which is L4S enabled) to make smarter decisions on packet routing priorities, contributing to the reduction of latencies where it really matters.
Today, most ISPs still don’t support L4S. This is work in progress.
L4S and WebRTC
In WebRTC, work is being done to make the WebRTC network congestion and bandwidth estimation mechanisms support L4S. WebRTC needs to give the sender of the packets feedback about which packets have so-called ECN markings (Explicit Congestion Notification) to the IP packets set on them using the RTCP feedback defined in RFC 8888. The sender can (and should) take this information into account to avoid the congestion.
WebRTC media servers need to add their own support for L4S in order to make use of this congestion control mechanism.
