Adaptive Queue Management Under Congestion
draft-xu-tsvwg-adaptive-queue-mgmt-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bohua Xu , Chang Liu , Jie Ren , Chenyang Wen , Wei Cheng , Junjie Wang , Guoying Zhang , Yongtao Yang | ||
| Last updated | 2026-06-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xu-tsvwg-adaptive-queue-mgmt-00
TSVWG B. Xu
Internet-Draft C. Liu
Intended status: Standards Track J. Ren
Expires: 26 December 2026 C. Wen
China Unicom
W. Cheng
J. Wang
G. Zhang
Y. Yang
Centec
24 June 2026
Adaptive Queue Management Under Congestion
draft-xu-tsvwg-adaptive-queue-mgmt-00
Abstract
Active Queue Management (AQM) manages queue depth by controlling
packet admission at the point of enqueue. This document specifies a
complementary queue management behavior that operates on packets
already admitted to a queue: when the queue depth exceeds a
configurable threshold, the maximum time a packet may remain queued
before being dropped is reduced. When congestion subsides, the
duration reverts to its base value. This per-queue dropping behavior
helps manage queue depth during congestion by releasing resources
from queues where packets have been waiting longest, complementing
AQM without modifying its signaling semantics.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 December 2026.
Xu, et al. Expires 26 December 2026 [Page 1]
Internet-Draft Adaptive Queue Management June 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Per-Queue Parameters . . . . . . . . . . . . . . . . . . 5
4.2. Queue Depth Threshold Detection . . . . . . . . . . . . . 5
4.3. Duration Adaptation . . . . . . . . . . . . . . . . . . . 5
4.4. Interaction with AQM . . . . . . . . . . . . . . . . . . 6
4.5. Per-Class Differentiation . . . . . . . . . . . . . . . . 6
5. Telemetry . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Data Model Framework . . . . . . . . . . . . . . . . . . . . 7
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
[RFC7567] recommends the deployment of Active Queue Management (AQM)
to manage queue depth and reduce latency in network devices. AQM
operates at the point of enqueue: it decides whether to admit, drop,
or ECN-mark [RFC3168] an arriving packet based on current queue
state. [RFC7806] establishes that queuing and dropping are
conceptually separate operations that work in series. AQM procedures
such as CoDel [RFC8289] and PIE [RFC8033] focus on controlling queue
depth by signaling congestion to transport endpoints.
Xu, et al. Expires 26 December 2026 [Page 2]
Internet-Draft Adaptive Queue Management June 2026
A related but distinct concern is managing packets that have already
been admitted to a queue and have been waiting for transmission.
Each queued packet has a maximum queuing duration — the upper bound
on how long it may remain in the queue before being dropped. In many
implementations, this duration is a fixed value that does not vary
with queue state. During sustained congestion, packets continue to
occupy queue resources for the full duration even when their
transmission is unlikely, delaying the release of resources needed by
other queues.
This document specifies an adaptive queue management behavior that
addresses this concern: when the queue depth exceeds a congestion
threshold, the maximum queuing duration for packets in that queue is
reduced, enabling faster resource release. When congestion subsides,
the duration reverts to its base value. This behavior operates
within the dropping framework of [RFC7806] and complements, rather
than replaces, AQM.
The behavior is specified in terms of externally observable
characteristics — the per-queue maximum queuing duration and the
queue-depth thresholds that govern its value — rather than any
particular implementation. This follows the approach used for the
Differentiated Services per-hop behaviors in [RFC2597] and [RFC3246],
which likewise define node-local forwarding behavior by its
observable effect. The behavior is independent of, and may be
deployed alongside, AQM algorithms such as CoDel [RFC8289] and PIE
[RFC8033]; Section 4.4 describes the considerations when both are
active.
1.1. Scope
This document defines a per-queue dropping behavior. It does not
define new on-the-wire protocol elements, packet formats, or
congestion signals. The behavior is local to the device implementing
it and is transparent to endpoints.
This behavior MUST NOT be used as a trigger for ECN marking
[RFC3168]. Dropping of queued packets due to duration expiry is
local queue management, not congestion signaling.
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Xu, et al. Expires 26 December 2026 [Page 3]
Internet-Draft Adaptive Queue Management June 2026
2. Terminology
This document uses terminology consistent with [RFC7567] and
[RFC7806].
Maximum Queuing Duration: The upper bound on the time a packet may
remain in a queue before being dropped. This bounds the per-
packet queuing delay at the device.
Base Duration: The maximum queuing duration during normal (non-
congested) operation.
Reduced Duration: The shorter maximum queuing duration applied when
the queue depth exceeds the congestion threshold.
Congestion Threshold: The queue depth at which the maximum queuing
duration transitions from base to reduced.
Restoration Threshold: The queue depth at which the maximum queuing
duration reverts from reduced to base. Set lower than the
congestion threshold to provide hysteresis.
3. Problem Statement
Section 3 of [RFC7567] discusses the importance of managing queue
depth. When a device serves multiple output queues with different
traffic classes [RFC2474], sustained congestion in one queue has
broader effects:
* Packets unlikely to be transmitted continue to occupy queue
resources for the full base duration, contributing to
unnecessarily deep queues.
* Lower-priority queues may hold resources longer than higher-
priority queues require, delaying service for priority traffic.
* Deep queues on congested ports can reduce resource availability
for queues on other ports.
AQM addresses queue depth by controlling packet admission. This
document addresses the complementary problem: managing packets that
have already been admitted and are occupying queue resources during
congestion.
4. Behavior
Xu, et al. Expires 26 December 2026 [Page 4]
Internet-Draft Adaptive Queue Management June 2026
4.1. Per-Queue Parameters
Each output queue SHOULD have independently configurable parameters:
* Base Duration: maximum queuing duration during normal operation.
* Reduced Duration: maximum queuing duration during congestion.
MUST be less than or equal to the Base Duration.
* Congestion Threshold: queue depth triggering transition to Reduced
Duration.
* Restoration Threshold: queue depth triggering reversion to Base
Duration. SHOULD be lower than the Congestion Threshold.
4.2. Queue Depth Threshold Detection
The device monitors the queue depth of each output queue per
Section 3 of [RFC7567]. When the queue depth exceeds the Congestion
Threshold, the queue enters the congested state. When it falls below
the Restoration Threshold, the queue returns to the non-congested
state.
The hysteresis between thresholds prevents oscillation.
Implementations MAY additionally require the threshold to be exceeded
for a configurable minimum interval before transitioning (dampening).
4.3. Duration Adaptation
When a queue enters the congested state, the maximum queuing duration
for that queue MUST be set to the Reduced Duration. A packet whose
time in the queue has reached or exceeded the currently effective
maximum queuing duration SHOULD be dropped rather than transmitted.
Because packets are dequeued in order, this condition is evaluated at
the head of the queue; an implementation MAY also evaluate it
elsewhere in the queue, but is not required to.
When a queue returns to the non-congested state, the maximum queuing
duration MUST revert to the Base Duration. Reversion SHOULD be
applied after a configurable hold-down period to avoid oscillation.
A packet dropped under this behavior MUST NOT have its drop
substituted by an ECN mark [RFC3168]: unlike AQM congestion
signaling, a duration-expiry drop indicates that the packet is no
longer useful to deliver, and an ECN mark would not convey that.
Xu, et al. Expires 26 December 2026 [Page 5]
Internet-Draft Adaptive Queue Management June 2026
4.4. Interaction with AQM
This behavior and an AQM algorithm [RFC7567] act at different points:
AQM acts at enqueue, controlling admission and congestion signaling,
while this behavior acts on already-queued packets at dequeue. Both
may drop packets based on time in queue. When both are enabled on
the same queue, the Base Duration SHOULD be set no smaller than the
target delay of the AQM algorithm, so that the Base Duration does not
pre-empt normal AQM operation under light load and takes effect only
as a congestion backstop. Operators SHOULD monitor the drop counters
of both mechanisms (Section 5) to detect compounded loss.
4.5. Per-Class Differentiation
In devices supporting Differentiated Services [RFC2474], parameters
MAY be differentiated by traffic class. Higher-priority classes
SHOULD have longer Base Durations and less aggressive Reduced
Durations. The mapping is a local policy decision.
+---------+----------+-------------------+
| Traffic | Base | Reduced |
| Class | Duration | Duration |
+---------+----------+-------------------+
| EF | D | 50-75% of D |
| AF | D | 25-50% of D |
| BE | D | 10-25% of D |
+---------+----------+-------------------+
D = device default. Values are illustrative.
Figure 1: Example Per-Class Differentiation
5. Telemetry
Implementations SHOULD expose per-queue:
* Current mode (base or reduced).
* Current queue depth.
* Packets dropped due to duration expiry, differentiated by mode.
* Number of mode transitions.
* Notifications on mode transitions including queue identifier, new
mode, queue depth, and timestamp.
Xu, et al. Expires 26 December 2026 [Page 6]
Internet-Draft Adaptive Queue Management June 2026
6. Data Model Framework
A future document may define a YANG [RFC7950] data model:
module: ietf-adaptive-queue-mgmt
+--rw profiles* [name]
| +--rw name string
| +--rw base-duration uint32 (microseconds)
| +--rw reduced-duration uint32 (microseconds)
| +--rw congestion-threshold uint32 (percent)
| +--rw restoration-threshold uint32 (percent)
| +--rw hold-down uint32 (milliseconds)
+--rw bindings* [interface queue-id]
+--rw interface if:interface-ref
+--rw queue-id uint8
+--rw profile -> /profiles/name
+--ro state
+--ro mode enumeration {base, reduced}
+--ro depth uint64
+--ro drops-by-duration yang:counter64
+--ro transitions yang:counter64
7. Deployment Considerations
* Begin with conservative thresholds (80-90% of queue allocation).
* Monitor per-mode drop counters during initial deployment.
* For latency-sensitive traffic classes, configure longer Reduced
Durations.
* When AQM is also enabled, monitor both AQM drop counters and
duration-based drop counters to avoid compounding loss.
8. Security Considerations
The security considerations of [RFC7567] apply. Configuration MUST
be restricted to authorized administrators via standard access
control (e.g., [RFC8341]). Telemetry does not contain user traffic
but may reveal congestion patterns; access SHOULD be restricted.
Implementations SHOULD log mode transitions to detect anomalous
conditions.
9. IANA Considerations
This document has no IANA actions.
10. References
Xu, et al. Expires 26 December 2026 [Page 7]
Internet-Draft Adaptive Queue Management June 2026
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[RFC7806] Baker, F. and R. Pan, "On Queuing, Marking, and Dropping",
RFC 7806, DOI 10.17487/RFC7806, April 2016,
<https://www.rfc-editor.org/info/rfc7806>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/info/rfc3246>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
Xu, et al. Expires 26 December 2026 [Page 8]
Internet-Draft Adaptive Queue Management June 2026
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>.
[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J.
Iyengar, Ed., "Controlled Delay Active Queue Management",
RFC 8289, DOI 10.17487/RFC8289, January 2018,
<https://www.rfc-editor.org/info/rfc8289>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
Acknowledgements
The authors acknowledge the IETF's work on queue management [RFC7567]
[RFC7806] which established the framework this document builds upon.
Authors' Addresses
Bohua Xu
China Unicom
Beijing
100000
China
Email: xubh15@chinaunicom.cn
Chang Liu
China Unicom
Beijing
100000
China
Email: liuc131@chinaunicom.cn
Jie Ren
China Unicom
Beijing
100000
China
Email: renj30@chinaunicom.cn
Xu, et al. Expires 26 December 2026 [Page 9]
Internet-Draft Adaptive Queue Management June 2026
Chenyang Wen
China Unicom
Beijing
100000
China
Email: wency15@chinaunicom.cn
Wei Cheng
Centec
Suzhou
215000
China
Email: chengw@centec.com
Junjie Wang
Centec
Suzhou
215000
China
Email: wangjj@centec.com
Guoying Zhang
Centec
Suzhou
215000
China
Email: zhanggy@centec.com
Yongtao Yang
Centec
Suzhou
215000
China
Email: yangyt@centec.com
Xu, et al. Expires 26 December 2026 [Page 10]