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, . [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . [RFC7806] Baker, F. and R. Pan, "On Queuing, Marking, and Dropping", RFC 7806, DOI 10.17487/RFC7806, April 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, . [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, . [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, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . 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, . [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, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . 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]