Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay (L4S)

The information below is for an old version of the document
Document Type Expired Internet-Draft (tsvwg WG)
Authors Koen De Schepper  , Bob Briscoe 
Last updated 2020-09-10 (latest revision 2020-03-09)
Replaces draft-briscoe-tsvwg-ecn-l4s-id
Stream Internet Engineering Task Force (IETF)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document (wg milestone: Oct 2021 - Submit "Identifying ... )
Document shepherd Wesley Eddy
IESG IESG state Expired
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to Wesley Eddy <>

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


This specification defines the identifier to be used on IP packets for a new network service called low latency, low loss and scalable throughput (L4S). It is similar to the original (or 'Classic') Explicit Congestion Notification (ECN). 'Classic' ECN marking was required to be equivalent to a drop, both when applied in the network and when responded to by a transport. Unlike 'Classic' ECN marking, for packets carrying the L4S identifier, the network applies marking more immediately and more aggressively than drop, and the transport response to each mark is reduced and smoothed relative to that for drop. The two changes counterbalance each other so that the throughput of an L4S flow will be roughly the same as a non-L4S flow under the same conditions. Nonetheless, the much more frequent control signals and the finer responses to them result in much more fine-grained adjustments, so that ultra-low and consistently low queuing delay (typically sub-millisecond on average) becomes possible for L4S traffic without compromising link utilization. Thus even capacity-seeking (TCP-like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load. The L4S identifier defined in this document distinguishes L4S from 'Classic' (e.g. TCP-Reno-friendly) traffic. It gives an incremental migration path so that suitably modified network bottlenecks can distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it degrading the low queuing delay and loss of L4S traffic. This specification defines the rules that L4S transports and network elements need to follow to ensure they neither harm each other's performance nor that of Classic traffic. Examples of new active queue management (AQM) marking algorithms and examples of new transports (whether TCP-like or real-time) are specified separately.


Koen De Schepper (
Bob Briscoe (

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