Skip to main content

Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S)

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>, Wesley Eddy <>,,,,,,
Subject: Document Action: 'DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)' to Experimental RFC (draft-ietf-tsvwg-aqm-dualq-coupled-25.txt)

The IESG has approved the following document:
- 'DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput
  (draft-ietf-tsvwg-aqm-dualq-coupled-25.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:

Ballot Text

Technical Summary

This specification defines a framework for coupling the Active Queue Management (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for the Internet to transition from the scaling problems of standard TCP Reno-friendly ('Classic') congestion controls to the family of 'Scalable' congestion controls. These are designed for consistently very Low queuing Latency, very Low congestion Loss and Scaling of per-flow throughput (L4S) by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled DualQ, these L4S senders could only be deployed where a clean-slate environment could be arranged, such as in private data centres. The coupling acts like a semi-permeable membrane: isolating the sub-millisecond average queuing delay and zero congestion loss of L4S from Classic latency and loss; but pooling the capacity between any combination of Scalable and Classic flows with roughly equivalent throughput per flow. The DualQ achieves this indirectly, without having to inspect transport layer flow identifiers and without compromising the performance of the Classic traffic, relative to a single queue. The DualQ design has low complexity and requires no configuration for the public Internet.

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.


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

RFC Editor Note