Skip to main content

The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)
draft-ietf-tsvwg-ecn-l4s-id-29

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, Wesley Eddy <wes@mti-systems.com>, draft-ietf-tsvwg-ecn-l4s-id@ietf.org, martin.h.duke@gmail.com, rfc-editor@rfc-editor.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org, wes@mti-systems.com
Subject: Document Action: 'Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)' to Experimental RFC (draft-ietf-tsvwg-ecn-l4s-id-29.txt)

The IESG has approved the following document:
- 'Explicit Congestion Notification (ECN) Protocol for Very Low Queuing
   Delay (L4S)'
  (draft-ietf-tsvwg-ecn-l4s-id-29.txt) as Experimental RFC

This document is the product of the Transport Area Working Group.

The IESG contact persons are Zaheduzzaman Sarker and Martin Duke.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/


Ballot Text

Technical Summary
This specification defines the protocol to be used for a new network service called low latency, low loss and scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'scalable' congestion control, which induces much more frequent control signals from the network and it responds to them with much more fine-grained adjustments, so that very low (typically sub-millisecond on average) and consistently low queuing delay 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 low loss of L4S traffic. This specification defines the rules that L4S transports and network elements need to follow with the intention that L4S flows 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.

Working Group Summary

The working group largely supports and is enthusiastic about L4S technology,
which this document is a part of.  It was last called along with 2 other L4S
documents.  There is a wider than normal level of support that has been
expressed for this work, but it is not unanimous.  There are also some WG
participants who have concerns about L4S or prefer an alternative approach. 
The working group had many long email threads and conducted several interim
meetings focused on L4S, its goals, technical challenges, and concerns with the
approach and potential impact on Internet safety.  Full agreement was not
obtained in all cases, but significant work was done to address the issues that
were agreed upon, and each concern was considered in detail by the working
group, even if some resolutions were not unanimously agreed with.

Document Quality

There are multiple existing implementations of the technology described, and
around 25 vendors and operators have indicated intentions to experiment with
the overall L4S technology.

Personnel

Wesley Eddy is the document shepherd, and Martin Duke is the responsible AD.

RFC Editor Note