Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture

The information below is for an old version of the document
Document Type Expired Internet-Draft (tsvwg WG)
Authors Bob Briscoe  , Koen De Schepper  , Marcelo Bagnulo  , Greg White 
Last updated 2020-01-09 (latest revision 2019-07-08)
Replaces draft-briscoe-tsvwg-l4s-arch
Stream IETF
Intended RFC status (None)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document (wg milestone: Oct 2020 - Submit "Low Latency,... )
Document shepherd Wesley Eddy
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to Wesley Eddy <wes@mti-systems.com>

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


This document describes the L4S architecture for the provision of a new Internet service that could eventually replace best efforts for all traffic: Low Latency, Low Loss, Scalable throughput (L4S). It is becoming common for _all_ (or most) applications being run by a user at any one time to require low latency. However, the only solution the IETF can offer for ultra-low queuing delay is Diffserv, which only favours a minority of packets at the expense of others. In extensive testing the new L4S service keeps average queuing delay under a millisecond for _all_ applications even under very heavy load, without sacrificing utilization; and it keeps congestion loss to zero. It is becoming widely recognized that adding more access capacity gives diminishing returns, because latency is becoming the critical problem. Even with a high capacity broadband access, the reduced latency of L4S remarkably and consistently improves performance under load for applications such as interactive video, conversational video, voice, Web, gaming, instant messaging, remote desktop and cloud-based apps (even when all being used at once over the same access link). The insight is that the root cause of queuing delay is in TCP, not in the queue. By fixing the sending TCP (and other transports) queuing latency becomes so much better than today that operators will want to deploy the network part of L4S to enable new products and services. Further, the network part is simple to deploy - incrementally with zero-config. Both parts, sender and network, ensure coexistence with other legacy traffic. At the same time L4S solves the long-recognized problem with the future scalability of TCP throughput. This document describes the L4S architecture, briefly describing the different components and how the work together to provide the aforementioned enhanced Internet service.


Bob Briscoe (ietf@bobbriscoe.net)
Koen De Schepper (koen.de_schepper@nokia.com)
Marcelo Bagnulo (marcelo@it.uc3m.es)
Greg White (g.white@cablelabs.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)