Adaptive Queue Management Under Congestion

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.¶

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

[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.¶

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.¶

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

  +---------+----------+-------------------+
  | 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.

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.¶

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.¶

Acknowledgements

The authors acknowledge the IETF's work on queue management [RFC7567] [RFC7806] which established the framework this document builds upon.¶

Authors' Addresses