RFC 7928

Characterization Guidelines for Active Queue Management (AQM)

📅 published July 2016, from ietf

RFC 7928 🎀 Characterization Guidelines for Active Queue Management (AQM)

okay so this is an IETF doc from July 2016 📅, and it's Informational 🌸, which means it's published for info and isn't a standards-track spec. The ISSN is 2070-1721. The authors are N. Kuhn, Ed. (CNES, Telecom Bretagne), P. Natarajan, Ed. (Cisco Systems), N. Khademi, Ed. (University of Oslo), and D. Ros (Simula Research Laboratory AS). Its header doesn't list anything it obsoletes or updates, so it's just doing its own thing 💅

Abstract 💖

Unmanaged large buffers in today's networks have caused a whole slew of performance issues 😭 These can be fixed with some kind of Active Queue Management (AQM) mechanism, optionally paired with a packet-scheduling scheme like fair queuing 🧚 This doc lays out different criteria for characterizing AQM schemes, which you can use in lab testing during development, before anything gets deployed.

Status of This Memo ✨

ngl this section is the boring-but-important part. This document is not an Internet Standards Track specification; it's published for informational purposes.

It's a product of the Internet Engineering Task Force (IETF) 🦋 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 🙈

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7928 🔗

Copyright Notice 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these docs carefully, bestie, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚠️

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Reducing the Latency and Maximizing the Goodput . . . . .   5
  1.2.  Goals of This Document  . . . . . . . . . . . . . . . . .   5
  1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   6
  1.4.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . .   7
2.  End-to-End Metrics  . . . . . . . . . . . . . . . . . . . . .   7
  2.1.  Flow Completion Time  . . . . . . . . . . . . . . . . . .   8
  2.2.  Flow Startup Time . . . . . . . . . . . . . . . . . . . .   8
  2.3.  Packet Loss . . . . . . . . . . . . . . . . . . . . . . .   9
  2.4.  Packet Loss Synchronization . . . . . . . . . . . . . . .   9
  2.5.  Goodput . . . . . . . . . . . . . . . . . . . . . . . . .  10
  2.6.  Latency and Jitter  . . . . . . . . . . . . . . . . . . .  11
  2.7.  Discussion on the Trade-Off between Latency and Goodput .  11
3.  Generic Setup for Evaluations . . . . . . . . . . . . . . . .  12
  3.1.  Topology and Notations  . . . . . . . . . . . . . . . . .  12
  3.2.  Buffer Size . . . . . . . . . . . . . . . . . . . . . . .  14
  3.3.  Congestion Controls . . . . . . . . . . . . . . . . . . .  14
4.  Methodology, Metrics, AQM Comparisons, Packet Sizes,
    Scheduling, and ECN . . . . . . . . . . . . . . . . . . . . .  14
  4.1.  Methodology . . . . . . . . . . . . . . . . . . . . . . .  14
  4.2.  Comments on Metrics Measurement . . . . . . . . . . . . .  15
  4.3.  Comparing AQM Schemes . . . . . . . . . . . . . . . . . .  15
    4.3.1.  Performance Comparison  . . . . . . . . . . . . . . .  15
    4.3.2.  Deployment Comparison . . . . . . . . . . . . . . . .  16
  4.4.  Packet Sizes and Congestion Notification  . . . . . . . .  16
  4.5.  Interaction with ECN  . . . . . . . . . . . . . . . . . .  17
  4.6.  Interaction with Scheduling . . . . . . . . . . . . . . .  17
5.  Transport Protocols . . . . . . . . . . . . . . . . . . . . .  18
  5.1.  TCP-Friendly Sender . . . . . . . . . . . . . . . . . . .  19
    5.1.1.  TCP-Friendly Sender with the Same Initial Congestion
            Window  . . . . . . . . . . . . . . . . . . . . . . .  19

    5.1.2.  TCP-Friendly Sender with Different Initial Congestion
            Windows . . . . . . . . . . . . . . . . . . . . . . .  19
  5.2.  Aggressive Transport Sender . . . . . . . . . . . . . . .  19
  5.3.  Unresponsive Transport Sender . . . . . . . . . . . . . .  20
  5.4.  Less-than-Best-Effort Transport Sender  . . . . . . . . .  20
6.  Round-Trip Time Fairness  . . . . . . . . . . . . . . . . . .  21
  6.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .  21
  6.2.  Recommended Tests . . . . . . . . . . . . . . . . . . . .  21
  6.3.  Metrics to Evaluate the RTT Fairness  . . . . . . . . . .  22
7.  Burst Absorption  . . . . . . . . . . . . . . . . . . . . . .  22
  7.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .  22
  7.2.  Recommended Tests . . . . . . . . . . . . . . . . . . . .  23
8.  Stability . . . . . . . . . . . . . . . . . . . . . . . . . .  24
  8.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .  24
  8.2.  Recommended Tests . . . . . . . . . . . . . . . . . . . .  24
    8.2.1.  Definition of the Congestion Level  . . . . . . . . .  25
    8.2.2.  Mild Congestion . . . . . . . . . . . . . . . . . . .  25
    8.2.3.  Medium Congestion . . . . . . . . . . . . . . . . . .  25
    8.2.4.  Heavy Congestion  . . . . . . . . . . . . . . . . . .  25
    8.2.5.  Varying the Congestion Level  . . . . . . . . . . . .  26
    8.2.6.  Varying Available Capacity  . . . . . . . . . . . . .  26
  8.3.  Parameter Sensitivity and Stability Analysis  . . . . . .  27
9.  Various Traffic Profiles  . . . . . . . . . . . . . . . . . .  27
  9.1.  Traffic Mix . . . . . . . . . . . . . . . . . . . . . . .  28
  9.2.  Bidirectional Traffic . . . . . . . . . . . . . . . . . .  28
10. Example of a Multi-AQM Scenario . . . . . . . . . . . . . . .  29
  10.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . .  29
  10.2.  Details on the Evaluation Scenario . . . . . . . . . . .  29
11. Implementation Cost . . . . . . . . . . . . . . . . . . . . .  30
  11.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . .  30
  11.2.  Recommended Discussion . . . . . . . . . . . . . . . . .  30
12. Operator Control and Auto-Tuning  . . . . . . . . . . . . . .  30
  12.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . .  30
  12.2.  Recommended Discussion . . . . . . . . . . . . . . . . .  31
13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
14. Security Considerations . . . . . . . . . . . . . . . . . . .  32
15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
  15.1.  Normative References . . . . . . . . . . . . . . . . . .  32
  15.2.  Informative References . . . . . . . . . . . . . . . . .  33
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  36
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1. Introduction 🦋

Active Queue Management (AQM) deals with the problems that come from using unnecessarily large and unmanaged buffers, which hurt network and application performance. The Section 1.2 of the AQM recommendations document [RFC7567] has the details 💅 A bunch of AQM algorithms have been proposed over the past years, most notably Random Early Detection (RED) [FLOY1993], BLUE [FENG2002], Proportional Integral controller (PI) [HOLLO2001], and more recently Controlled Delay (CoDel) [CODEL] and Proportional Integral controller Enhanced (PIE) [AQMPIE]. Generally, these algorithms actively interact with the Transmission Control Protocol (TCP) and any other transport protocol that uses a congestion control scheme to manage how much data they keep in the network ✨ The available buffer space in the routers and switches should be large enough to handle the short-term buffering requirements. AQM schemes aim to reduce buffer occupancy, and therefore end-to-end delay 🧚 Some of these algorithms, notably RED, have also been widely implemented in network devices. But the potential benefits of RED haven't really been realized, since RED is reported to be usually turned off 🙈

A buffer is a physical volume of memory where a queue or a set of queues gets stored. When this doc talks about a specific queue, "buffer occupancy" means the amount of data (measured in bytes or packets) sitting in the queue, and the "maximum buffer size" means the maximum buffer occupancy. In switches and routers, a global memory space is often shared between the available interfaces, so the maximum buffer size for any given interface can change over time 🌸

Bufferbloat [BB2011] is what happens when large, unmanaged buffers get deployed on the Internet. The buffering has often been measured at ten times or a hundred times larger than needed 😭 Large buffer sizes combined with TCP and/or unresponsive flows increase end-to-end delay, which is bad news for latency-sensitive apps like real-time multimedia (voice, video, gaming, etc.). This affects modern networking gear, especially consumer-grade equipment, and it causes problems even with commonly used web services. So yeah, Active Queue Management is essential for controlling queuing delay and cutting network latency 👑

The Active Queue Management and Packet Scheduling Working Group (AQM WG) was chartered to tackle the problems with large unmanaged buffers on the Internet. Specifically, the AQM WG is tasked with standardizing AQM schemes that don't just address concerns with those buffers, but also stay robust under a wide variety of operating conditions 🌈 This document gives characterization guidelines that you can use to assess the applicability, performance, and deployability of an AQM, whether or not it's a candidate for standardization at the IETF.

The AQM algorithm in a router can be separated from the scheduling of packets that the router sends out, as discussed in the AQM recommendations document [RFC7567]. The rest of this memo treats the AQM as a dropping/marking policy, separate from any interface-scheduling scheme ⭐ This document may be complemented by another one on guidelines for assessing the combination of packet scheduling and AQM. Such a document will inherit all the guidelines from this one, plus any additional scenarios relevant to packet scheduling, like flow-starvation evaluation or the impact of the number of hash buckets 🫶

1.1. Reducing the Latency and Maximizing the Goodput 💖

okay so the big tradeoff here is latency vs. goodput 🥺. It's baked right into every AQM scheme, which makes it the key to judging how well one performs 💅. To keep an AQM safe to deploy, you gotta test its behavior across a bunch of different scenarios ✨. Whenever it's possible, solutions ought to aim for maximizing goodput AND minimizing latency at the same time 🦋.

1.2. Goals of This Document 🎀

okay this is the part that tells you what to test 📋. This document recommends a generic list of scenarios that an AQM proposal should be evaluated against, looking at both its potential performance gain and how safe it is to deploy 🛡️. The guidelines help you quantify performance in terms of latency reduction, goodput maximization, and the tradeoff between the two 📈. The doc also covers the central parts of an AQM algorithm you should always think about, no matter the context, like burst absorption capacity, RTT fairness, and resilience to fluctuating network conditions 🌊.

The main goal is figuring out whether a specific AQM is not only better than drop-tail (meaning no AQM, with a BDP-sized buffer), but also safe to deploy 👑. The guidelines can be used to compare several AQM proposals with each other, but they should be used to compare a proposal with drop-tail 💜.

This memo lays out generic characterization scenarios that any AQM proposal should be evaluated against, whether or not the AQM is standardized by the IETF 🌸. It recommends the relevant scenarios and metrics to look at, and it covers those same central aspects like burst absorption capacity, RTT fairness, and resilience to fluctuating network conditions, no matter the context 🧚.

These guidelines aren't tied to one particular deployment scenario or evaluation toolset 🍓. Instead, they can be used to assert the potential gain of introducing an AQM for the particular environment the testers care about ✨. They don't cover every possible aspect of a particular algorithm 🙈. They also don't present context-dependent scenarios, such as IEEE 802.11 WLANs, data centers, or rural broadband networks 📡. To keep things generic, a bunch of potential router components and algorithms, like Diffserv, are left out 🫶.

The goals of this document can be summed up like this:

The present characterization guidelines provide a non-exhaustive list of scenarios to help ascertain whether an AQM is not only better than drop-tail (with a BDP-sized buffer), but also safe to deploy. The guidelines can also be used to compare several AQM proposals with each other.
The present characterization guidelines (1) are not bound to a particular evaluation toolset and (2) can be used for various deployment contexts. Testers are free to select a toolset that is best suited for the environment in which their proposal will be deployed.
The present characterization guidelines are intended to provide guidance for better selecting an AQM for a specific environment. It is not required that an AQM proposal is evaluated following these guidelines for its standardization.

1.3. Requirements Language 📜

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🤓.

1.4. Glossary 📖

Application-limited traffic: A type of traffic that does not have an unlimited amount of data to transmit 🍃.
AQM: The Active Queue Management (AQM) algorithm implemented in a router can be separated from the scheduling of packets sent by the router. The rest of this memo refers to the AQM as a dropping/marking policy as a separate feature to any interface scheduling scheme [RFC7567] 🎯.
BDP: Bandwidth Delay Product 📏.
Buffer: A physical volume of memory in which a queue or set of queues are stored 🧺.
Buffer Occupancy: The amount of data stored in a buffer, measured in bytes or packets 📦.
Buffer Size: The maximum buffer occupancy, that is the maximum amount of data that may be stored in a buffer, measured in bytes or packets 📐.
Initial Window 10 (IW10): TCP initial congestion window set to 10 packets 🪟.
Latency: One-way delay of packets across Internet paths. This definition suits transport layer definition of the latency, which should not be confused with an application-layer view of the latency ⏱️.
Goodput: Goodput is defined as the number of bits per unit of time forwarded to the correct destination, minus any bits lost or retransmitted [RFC2647]. The goodput should be determined for each flow and not for aggregates of flows 💸.
SQRT: The square root function 🌱.
ROUND: The round function 🔄.

2. End-to-End Metrics 📊

End-to-end delay is the result of propagation delay, serialization delay, service delay in a switch, medium-access delay, and queuing delay, summed over the network elements along the path 🛤️. AQM schemes may reduce the queuing delay by providing signals to the sender on the emergence of congestion, but any impact on the goodput must be carefully considered ⚖️. This section presents the metrics that could be used to better quantify (1) the reduction of latency, (2) maximization of goodput, and (3) the trade-off between these two 📏. This section provides normative requirements for metrics that can be used to assess the performance of an AQM scheme 💅.

Some metrics listed in this section are not suited to every type of traffic detailed in the rest of this document. It is therefore not necessary to measure all of the following metrics: the chosen metric may not be relevant to the context of the evaluation scenario (e.g., latency vs. goodput trade-off in application-limited traffic scenarios). Guidance is provided for each metric 🫶.

2.1. Flow Completion Time ⏳

The flow completion time is an important performance metric for the end-user when the flow size is finite 🙋. The definition of the flow size may be a source of contradictions, thus, this metric can consider a flow as a single file 📁. Considering the fact that an AQM scheme may drop/mark packets, the flow completion time is directly linked to the dropping/marking policy of the AQM scheme 🔗. This metric helps to better assess the performance of an AQM depending on the flow size 🎯. The Flow Completion Time (FCT) is related to the flow size (Fs) and the goodput for the flow (G) as follows:

FCT [s] = Fs [byte] / ( G [bit/s] / 8 [bit/byte] )

Where flow size is the size of the transport-layer payload in bits and goodput is the transport-layer payload transfer time (described in Section 2.5) 🧮.

If this metric is used to evaluate the performance of web transfers, it is suggested to rather consider the time needed to download all the objects that compose the web page, as this makes more sense in terms of user experience, rather than assessing the time needed to download each object 🌐✨.

2.2. Flow Startup Time 🚀

The flow startup time is the time between when the request was sent from the client and when the server starts to transmit data 📨. The amount of packets dropped by an AQM may seriously affect the waiting period during which the data transfer has not started 😭. This metric would specifically focus on the operations such as DNS lookups, TCP opens, and Secure Socket Layer (SSL) handshakes 🤝.

2.3. Packet Loss 🫠

Packet loss can occur en route, and this can impact the end-to-end performance measured at the receiver end 🛣️.

The tester should evaluate the loss experienced at the receiver end using one of two metrics:

The packet loss ratio: This metric is to be frequently measured during the experiment. The long-term loss ratio is of interest for steady-state scenarios only;
The interval between consecutive losses: The time between two losses is to be measured.

The packet loss ratio can be assessed by simply evaluating the loss ratio as a function of the number of lost packets and the total number of packets sent 🧮. This might not be easily done in laboratory testing, so these guidelines advise the tester to:

Check that for every packet, a corresponding packet was received within a reasonable time, as presented in the document that proposes a metric for one-way packet loss across Internet paths [RFC7680] 🔍.
Keep a count of all packets sent, and a count of the non-duplicate packets received, as discussed in [RFC2544], which presents a benchmarking methodology 📝.

The interval between consecutive losses, which is also called a "gap", is a metric of interest for Voice over IP (VoIP) traffic [RFC3611] 📞💜.

2.4. Packet Loss Synchronization 🌀

One goal of an AQM algorithm is to help avoid global synchronization of flows sharing a bottleneck buffer on which the AQM operates ([RFC2309] and [RFC7567]) 🫧. The "degree" of packet-loss synchronization between flows should be assessed, with and without the AQM under consideration 🔬.

Loss synchronization among flows may be quantified by several slightly different metrics that capture different aspects of the same issue [HASS2008]. However, in real-world measurements the choice of metric could be imposed by practical considerations -- e.g., whether fine-grained information on packet losses at the bottleneck is available or not. For the purpose of AQM characterization, a good candidate metric is the global synchronization ratio, measuring the proportion of flows losing packets during a loss event. This metric can be used in real-world experiments to characterize synchronization along arbitrary Internet paths [JAY2006] 🌍.

If an AQM scheme is evaluated using real-life network environments, it is worth pointing out that some network events, such as failed link restoration, may cause synchronized losses between active flows, and thus confuse the meaning of this metric 😵‍💫💅.

2.5. Goodput

The goodput has been defined as the number of bits per the unit of time forwarded to the correct destination interface, minus any bits lost or retransmitted, such as proposed in Section 3.17 of [RFC2647], which describes the benchmarking terminology for firewall performances. This definition requires that the test setup needs to be qualified to assure that it is not generating losses on its own.

Measuring the end-to-end goodput provides an appreciation of how well an AQM scheme improves transport and application performance. The measured end-to-end goodput is linked to the dropping/marking policy of the AQM scheme -- e.g., the fewer the number of packet drops, the fewer packets need retransmission, minimizing the impact of AQM on transport and application performance. Additionally, an AQM scheme may resort to Explicit Congestion Notification (ECN) marking as an initial means to control delay. Again, marking packets instead of dropping them reduces the number of packet retransmissions and increases goodput. End-to-end goodput values help to evaluate the AQM scheme's effectiveness in minimizing packet drops that impact application performance and to estimate how well the AQM scheme works with ECN.

The measurement of the goodput allows the tester to evaluate to what extent an AQM is able to maintain a high bottleneck utilization. This metric should also be obtained frequently during an experiment, as the long-term goodput is relevant for steady-state scenarios only and may not necessarily reflect how the introduction of an AQM actually impacts the link utilization during a certain period of time. Fluctuations in the values obtained from these measurements may depend on other factors than the introduction of an AQM, such as link-layer losses due to external noise or corruption, fluctuating bandwidths (IEEE 802.11 WLANs), heavy congestion levels, or the transport layer's rate reduction by the congestion control mechanism.

2.6. Latency and Jitter

The latency, or the one-way delay metric, is discussed in [RFC7679]. There is a consensus on an adequate metric for the jitter that represents the one-way delay variations for packets from the same flow: the Packet Delay Variation (PDV) serves well in all use cases [RFC5481].

The end-to-end latency includes components other than just the queuing delay, such as the signal-processing delay, transmission delay, and processing delay. Moreover, the jitter is caused by variations in queuing and processing delay (e.g., scheduling effects). The introduction of an AQM scheme would impact end-to-end latency and jitter, and therefore these metrics should be considered in the end-to-end evaluation of performance.

2.7. Discussion on the Trade-Off between Latency and Goodput

The metrics presented in this section may be considered in order to discuss and quantify the trade-off between latency and goodput.

With regards to the goodput, and in addition to the long-term stationary goodput value, it is recommended to take measurements at every multiple of the minimum RTT (minRTT) between A and B. It is suggested to take measurements at least every K * minRTT (to smooth out the fluctuations), with K=10. Higher values for K can be considered whenever it is more appropriate for the presentation of the results, since the value for K may depend on the network's path characteristics. The measurement period must be disclosed for each experiment, and when results/values are compared across different AQM schemes, the comparisons should use exactly the same measurement periods. With regards to latency, it is recommended to take the samples on a per-packet basis whenever possible, depending on the features provided by the hardware and software and the impact of sampling itself on the hardware performance.

From each of these sets of measurements, the cumulative density function (CDF) of the considered metrics should be computed. If the considered scenario introduces dynamically varying parameters, temporal evolution of the metrics could also be generated. For each scenario, the following graph may be generated: the x-axis shows a queuing delay (that is, the average per-packet delay in excess of minimum RTT), the y-axis the goodput. Ellipses are computed as detailed in [WINS2014]: "We take each individual [...] run [...] as one point, and then compute the 1-epsilon elliptic contour of the maximum-likelihood 2D Gaussian distribution that explains the points. [...] we plot the median per-sender throughput and queueing delay as a circle. [...] The orientation of an ellipse represents the covariance between the throughput and delay measured for the protocol." This graph provides part of a better understanding of (1) the delay/goodput trade-off for a given congestion control mechanism (Section 5), and (2) how the goodput and average queue delay vary as a function of the traffic load (Section 8.2).

Generic Setup for Evaluations

This section presents the topology that can be used for each of the following scenarios, the corresponding notations, and discusses various assumptions that have been made in the document.

3.1. Topology and Notations

+--------------+ +--------------+

sender A_i	receive B_i
SEN.Flow1.1 +---------+ +-----------+ REC.Flow1.1
+		+
+		+
SEN.Flow1.X +-----+	+--------+ REC.Flow1.X

+--------------+ | | | | +--------------+

+-+---+---+ +--+--+---+ +

	Router L	Router R
	AQM
	BuffSize	BuffSize
	(Bsize) +-----+ (Bsize)
+-----+--++ ++-+------+

| | | | + +--------------+ | | | | +--------------+

sender A_n
SEN.FlowN.1 +---------+	+-----------+ REC.FlowN.1
+		+
+		+
SEN.FlowN.Y +------------+ +-------------+ REC.FlowN.Y

+--------------+ +--------------+

Figure 1: Topology and Notations

Figure 1 is a generic topology where:

o The traffic profile is a set of flows with similar characteristics -- RTT, congestion control scheme, transport protocol, etc.;

o Senders with different traffic characteristics (i.e., traffic profiles) can be introduced;

o The timing of each flow could be different (i.e., when does each flow start and stop?);

o Each traffic profile can comprise various number of flows;

o Each link is characterized by a couple (one-way delay, capacity);

o Sender A_i is instantiated for each traffic profile. A corresponding receiver B_i is instantiated for receiving the flows in the profile;

o Flows share a bottleneck (the link between routers L and R);

o The tester should consider both scenarios of asymmetric and symmetric bottleneck links in terms of bandwidth. In the case of an asymmetric link, the capacity from senders to receivers is higher than the one from receivers to senders; the symmetric link scenario provides a basic understanding of the operation of the AQM mechanism, whereas the asymmetric link scenario evaluates an AQM mechanism in a more realistic setup;

o In asymmetric link scenarios, the tester should study the bidirectional traffic between A and B (downlink and uplink) with the AQM mechanism deployed in one direction only. The tester may additionally consider a scenario with the AQM mechanism being deployed in both directions. In each scenario, the tester should investigate the impact of the drop policy of the AQM on TCP ACK packets and its impact on the performance (Section 9.2).

Although this topology may not perfectly reflect actual topologies, the simple topology is commonly used in the world of simulations and small testbeds. It can be considered as adequate to evaluate AQM proposals [TCPEVAL]. Testers ought to pay attention to the topology used to evaluate an AQM scheme when comparing it with a newly proposed AQM scheme.

3.2. Buffer Size

The size of the buffers should be carefully chosen, and may be set to the bandwidth-delay product; the bandwidth being the bottleneck capacity and the delay being the largest RTT in the considered network. The size of the buffer can impact the AQM performance and is a dimensioning parameter that will be considered when comparing AQM proposals.

If a specific buffer size is required, the tester must justify and detail the way the maximum queue size is set. Indeed, the maximum size of the buffer may affect the AQM's performance and its choice should be elaborated for a fair comparison between AQM proposals. While comparing AQM schemes, the buffer size should remain the same across the tests.

3.3. Congestion Controls

This document considers running three different congestion control algorithms between A and B:

o Standard TCP congestion control: The base-line congestion control is TCP NewReno with selective acknowledgment (SACK) [RFC5681].

o Aggressive congestion controls: A base-line congestion control for this category is CUBIC [CUBIC].

o Less-than-Best-Effort (LBE) congestion controls: Per [RFC6297], an LBE service "results in smaller bandwidth and/or delay impact on standard TCP than standard TCP itself, when sharing a bottleneck with it." A base-line congestion control for this category is Low Extra Delay Background Transport (LEDBAT) [RFC6817].

Other transport congestion controls can OPTIONALLY be evaluated in addition. Recent transport layer protocols are not mentioned in the following sections, for the sake of simplicity.

Methodology, Metrics, AQM Comparisons, Packet Sizes, Scheduling, and ECN

4.1. Methodology

A description of each test setup should be detailed to allow this test to be compared with other tests. This also allows others to replicate the tests if needed. This test setup should detail software and hardware versions. The tester could make its data available.

The proposals should be evaluated on real-life systems, or they may be evaluated with event-driven simulations (such as ns-2, ns-3, OMNET, etc.). The proposed scenarios are not bound to a particular evaluation toolset.

The tester is encouraged to make the detailed test setup and the results publicly available.

4.2. Comments on Metrics Measurement ✨

okay so bestie, this part is all about the metrics we should actually be looking at 📊 the end-to-end numbers are the main event, the ones that show the latency vs. goodput trade-off from Section 2 🎀 but the queue-level stuff (what's happening inside the device running the AQM) gives you so much extra insight into how the AQM is behaving and what its internal knobs are doing 🧚 so whenever your hardware or software lets you grab it, go for link utilization, queuing delay, queue size, and packet drop/mark stats alongside the AQM-specific parameters 💅 BUT the evaluation has to be mainly based on what you can observe from the outside, end-to-end 🫶 and no, these guidelines don't tell you how to measure any of this, because that depends on whatever evaluation toolset you're using 🙈

4.3. Comparing AQM Schemes 💖

this doc is totally on board with these guidelines being used to compare AQM schemes 🌸 and honestly comparing them is a whole thing, because you need to look at both performance AND deployment 🔥 this section spells out how to do a fair comparison and how to dodge the pitfalls that make comparisons sneaky-unfair 🦋

4.3.1. Performance Comparison ⭐

AQM schemes should be compared against the generic scenarios summarized in Section 13 ✨ they can also be compared for specific network environments like data centers or home networks 🏠 and if an AQM scheme has parameter(s) that were externally tuned for optimization or whatever other reason, those values MUST be disclosed 💜

okay here's the lowkey tricky part 💀 AQM schemes come in different varieties, like queue-length based ones (RED, for example) or queuing-delay based ones (CoDel and PIE, for example) 🌈 they expose different control knobs with different meanings, and that's so easy to overlook when you're comparing them 😭 for example, PIE and CoDel are both queuing-delay based and each has a knob to control queuing delay (PIE's "queuing delay reference" vs. CoDel's "queuing delay target") but those two tuning parameters have different semantics, which means different control points 🎀

this doc recommends these procedures for a fair performance comparison:

Similar control parameters and implications: testers should know which control parameters across the different schemes control similar behavior 🧚 they should also know the input value ranges and what each one implies 💅 like, imagine (A) a queue-length based scheme and (B) a queuing-delay based scheme 🌸 A and B will probably have different kinds of inputs for the target delay, such as a target queue length in A vs. a target queuing delay in B 💖 so setting 100 MB for A vs. 10 ms for B will mean totally different things depending on the evaluation context 😳 those context-dependent implications MUST be considered before you draw any performance conclusions 🔥 also, it'd be preferable if an AQM proposal listed these parameters and talked about how each one relates to network characteristics like capacity, average RTT, etc. 🫶
Compare over a range of input configurations: sometimes the set of control parameters that affect a specific behavior has different semantics between two AQM schemes 🦋 like we said, PIE's queue delay tuning parameters mean something different from CoDel's 🙈 in those situations, the schemes need to be compared over a range of input configurations 🌈 for example, compare PIE vs. CoDel across the range of target delay input configurations ✨

4.3.2. Deployment Comparison 🍓

AQM schemes MUST be compared against deployment criteria like parameter sensitivity (Section 8.3), auto-tuning (Section 12), or implementation cost (Section 11) 💅

4.4. Packet Sizes and Congestion Notification 🎀

an AQM scheme may consider packet sizes when generating congestion signals [RFC7141] 🧚 control packets like DNS requests/responses and TCP SYNs/ACKs are tiny, but losing them can seriously hurt application performance 😭 so an AQM might be biased toward small packets by dropping them with lower probability than larger ones 🫶 BUT that's unfair to senders that generate larger packets 💀 and senders, malicious or not, are motivated to exploit that by sending smaller packets, which could lead to unsafe deployments and unhealthy transport and/or application designs 🔥

an AQM scheme SHOULD follow the Best Current Practice for dropping and marking packets [BCP41] and SHOULD NOT give undue advantage to flows with smaller packets, as discussed in Section 4.4 of the AQM recommendation document [RFC7567] 💖 to check whether an AQM is biased toward flows with smaller packets, you can generate traffic (as defined in Section 8.2.2) where half of the flows use smaller packets (e.g., 500-byte packets) and the other half use larger ones (e.g., 1500-byte packets) 🦋 the reported metrics could be the same as in Section 6.3, where Category I is the set of flows with smaller packets and Category II is the set with larger packets 🌸 the bidirectional scenario could also be considered (Section 9.2) ✨

4.5. Interaction with ECN 🦢

ECN [RFC3168] is an alternative that lets AQM schemes signal congestion to receivers without using packet drops 💜 there are real benefits to giving an AQM scheme ECN support [WELZ2015] 🌈

if the tested AQM scheme can support ECN, the testers MUST discuss and describe that ECN support, as discussed in the AQM recommendation document [RFC7567] 🫶 the AQM's ECN support can also be studied and verified by replicating the tests in Section 6.2 with ECN turned ON at the TCP senders ✨ the results can show how the tested AQM performs with and without ECN markings, and also help quantify how worth it enabling ECN is 🔥

4.6. Interaction with Scheduling 🧚

a network device may use per-flow or per-class queuing with a scheduling algorithm to prioritize certain applications or classes of traffic, limit the transmission rate, or isolate different traffic flows within a common class 💅 (see Section 2.1 of the AQM recommendation document [RFC7567] for more on that) 🌸

the scheduling and the AQM work together to shape end-to-end performance 🎀 so the AQM proposal MUST discuss the feasibility of adding scheduling on top of the AQM algorithm 💖 it can also be explained whether the dropping policy is applied when packets are enqueued or dequeued 🦋

these guidelines do NOT propose ways to assess scheduling algorithms, and that's on purpose 🙈 characterizing AQM schemes is about how well they control queuing delay in a queue, whereas characterizing schedulers is about the scheduler itself and how it interacts with the AQM 🌈 for example, the scheduler might create sub-queues and the AQM could run on each sub-queue, on the whole queue, or both ✨ schedulers like FQ-CoDel [HOEI2015] or FavorQueue [ANEL2014] can also introduce flow prioritization 🍓 in those cases, specific scenarios should be proposed to confirm these schedulers not only help tackle bufferbloat but are also robust across a wide variety of operating conditions 🔥 that's out of scope here, since this document focuses on AQM schemes that drop and/or mark 💅

Transport Protocols 🚀

network and end-devices need a reasonable amount of buffer space to absorb transient bursts 🫶 sometimes network providers configure devices with large buffers to avoid drops caused by a full buffer and to maximize link utilization for standard loss-based TCP traffic 😬

AQM algorithms are often evaluated using the Transmission Control Protocol (TCP) [RFC793] with a limited number of applications 💖 TCP is widely deployed 🌸 it keeps filling up the available buffers until a sender transferring a bulk flow over TCP gets a signal (a packet drop) that slows its sending rate 🦋 the bigger the buffer, the higher the buffer occupancy, and so the higher the queuing delay 😭 an efficient AQM scheme sends early congestion signals to TCP to get the queuing delay under control 👑

not every endpoint (or application) using TCP uses the same flavor of TCP 🎀 a bunch of senders generate different classes of traffic, and some may not react to congestion signals (aka non-responsive flows in Section 3 of the AQM recommendation document [RFC7567]) or may not reduce their sending rate as expected (aka transport flows that are less responsive than TCP, as proposed in Section 3 of [RFC7567], also called "aggressive flows") 💅 in these cases, AQM schemes still try to control the queuing delay 🧚

this section gives guidelines for assessing an AQM proposal across different traffic profiles 🌈 that means different types of senders (with different TCP congestion control variants, unresponsive, and aggressive) ✨

5.1. TCP-Friendly Sender 🦢

5.1.1. TCP-Friendly Sender with the Same Initial Congestion Window 💖

this scenario helps evaluate how an AQM scheme reacts to a TCP-friendly transport sender 🌸 a single, long-lived, non-application-limited TCP NewReno flow, with an Initial congestion Window (IW) set to 3 packets, transfers data between sender A and receiver B 🎀 other TCP-friendly congestion control schemes, such as TCP-Friendly Rate Control [RFC5348], may also be considered 🫶

for each TCP-friendly transport considered, the graph described in Section 2.7 could be generated 📈

5.1.2. TCP-Friendly Sender with Different Initial Congestion Windows 🌈

this scenario can be used to see how an AQM scheme adapts to a traffic mix of TCP flows with different IW values 🧚

for this scenario, two types of flows MUST be generated between sender A and receiver B 👑

a single, long-lived non-application-limited TCP NewReno flow;
a single, application-limited TCP NewReno flow, with an IW set to 3 or 10 packets. The size of the data transferred MUST be strictly higher than 10 packets and SHOULD be lower than 100 packets 💅

the transmission of the non-application-limited flow MUST start first, and the transmission of the application-limited flow starts after the non-application-limited flow has reached steady state 🔥 steady state can be assumed when the goodput is stable ✨

for each of these scenarios, the graph described in Section 2.7 could be generated for each class of traffic (application-limited and non-application-limited) 📊 the completion time of the application-limited TCP flow could be measured 🦋

5.2. Aggressive Transport Sender 🔥

okay so this scenario helps testers see how an AQM scheme reacts to a transport sender that is way more aggressive than a single TCP-friendly sender 💅. "Aggressiveness" here means a higher-than-standard increase factor after a successful transmission and/or a lower-than-standard decrease factor after an unsuccessful one. For example, with AIMD-style congestion controls, that means a larger AI and/or MD factor 👑. One long-lived, non-application-limited CUBIC flow transfers data between sender A and receiver B. other aggressive congestion control schemes could be considered too ✨.

For each flavor of aggressive transport, the graph described in Section 2.7 could be generated 🦋.

5.3. Unresponsive Transport Sender 🙈

this scenario is all about how an AQM scheme handles a transport sender that is less responsive than TCP 💀. Faulty transport implementations on an end host, and/or faulty network elements en route that "hide" congestion signals in packet headers, can also lead to a similar situation. so the AQM scheme needs to adapt to unresponsive traffic (see Section 3 of the AQM recommendation document [RFC7567]) 🫶. To this end, these guidelines propose the two following scenarios:

The first scenario can be used to evaluate queue build up. It considers unresponsive flow(s) whose sending rate is greater than the bottleneck link capacity between routers L and R. This scenario consists of a long-lived non-application-limited UDP flow that transmits data between sender A and receiver B. The graph described in Section 2.7 could be generated.
The second scenario can be used to evaluate if the AQM scheme is able to keep the responsive fraction under control. This scenario considers a mixture of TCP-friendly and unresponsive traffic. It consists of a long-lived UDP flow from unresponsive application and a single long-lived, non-application-limited (unlimited data available to the transport sender from the application layer), TCP New Reno flow that transmit data between sender A and receiver B. As opposed to the first scenario, the rate of the UDP traffic should not be greater than the bottleneck capacity, and should be higher than half of the bottleneck capacity. For each type of traffic, the graph described in Section 2.7 could be generated.

5.4. Less-than-Best-Effort Transport Sender 🌸

this scenario helps evaluate how an AQM scheme reacts to LBE congestion control that "results in smaller bandwidth and/or delay impact on standard TCP than standard TCP itself, when sharing a bottleneck with it" [RFC6297] 🧚. There are potential fateful interactions when AQM and LBE techniques are combined [GONG2014], so this scenario checks whether the proposed AQM and LBE techniques can coexist 👀.

A single long-lived non-application-limited TCP NewReno flow transfers data between sender A and receiver B. Other TCP-friendly congestion control schemes may also be considered. Single long-lived non-application-limited LEDBAT [RFC6817] flows transfer data between sender A and receiver B. We recommend setting the target delay and gain values of LEDBAT to 5 ms and 10, respectively [TRAN2014]. Other LBE congestion control schemes may also be considered and are listed in the IETF survey of LBE protocols [RFC6297] 💜.

For each of the TCP-friendly and LBE transports, the graph described in Section 2.7 could be generated ✨.

6. Round-Trip Time Fairness 🌈

6.1. Motivation

okay so an AQM scheme's congestion signals (via drops or ECN marks) have to reach the transport sender, so that a responsive sender can kick off its congestion control and adjust its sending rate 🦋. This whole procedure depends on the end-to-end path RTT. When the RTT varies, the onset of congestion control gets affected, and that in turn affects how well an AQM scheme can control the queue 😭. So it's important to assess AQM schemes across a set of RTTs between A and B (e.g., from 5 to 200 ms) 🍓.

The asymmetry in intrinsic RTT between various paths sharing the same bottleneck should be considered, so the fairness between the flows can be discussed 💅. In this scenario, a flow on a shorter RTT path may react faster to congestion and recover faster from it than a flow on a longer RTT path. The introduction of AQM schemes may potentially improve RTT fairness ✨.

Introducing an AQM scheme may cause unfairness between the flows, even if the RTTs are identical. This potential unfairness should be investigated as well 👑.

6.2. Recommended Tests

The recommended topology is detailed in Figure 1 🎀.

To evaluate RTT fairness, for each run, two flows are divided into two categories. Category I is the one whose RTT between sender A and receiver B should be 100 ms. Category II is the one in which the RTT between sender A and receiver B should be in the range [5 ms, 560 ms] inclusive. The maximum value for the RTT represents the RTT of a satellite link [RFC2488] 🛰️.

A set of evaluated flows must use the same congestion control algorithm: all the generated flows could be single long-lived non-application-limited TCP NewReno flows 🫶.

6.3. Metrics to Evaluate the RTT Fairness

the outputs that must be measured are: (1) the cumulative average goodput of the flow from Category I, goodput_Cat_I (see Section 2.5 for the estimation of the goodput); (2) the cumulative average goodput of the flow from Category II, goodput_Cat_II (see Section 2.5 for the estimation of the goodput); (3) the ratio goodput_Cat_II/goodput_Cat_I; and (4) the average packet drop rate for each category (Section 2.3) 📊🔥.

7. Burst Absorption 💥

"AQM mechanisms might need to control the overall queue sizes to ensure that arriving bursts can be accommodated without dropping packets" [RFC7567].

7.1. Motivation

an AQM scheme can face bursts of packet arrivals for various reasons 🌊. Dropping one or more packets from a burst can cause performance penalties for the corresponding flows, since dropped packets have to be retransmitted 😩. Performance penalties can mean failing to meet Service Level Agreements (SLAs), and that can be a disincentive to AQM adoption 🥀.

The ability to accommodate bursts translates to a larger queue length and hence more queuing delay. On the one hand, it's important that an AQM scheme quickly brings bursty traffic under control. On the other hand, a peak in the packet drop rate, used to bring a packet burst quickly under control, could result in multiple drops per flow and seriously hurt transport and application performance 😵. So an AQM scheme ought to bring bursts under control by balancing both aspects: (1) queuing delay spikes are minimized and (2) performance penalties for ongoing flows in terms of packet drops are minimized ⚖️💖.

An AQM scheme that maintains short queues leaves some remaining space in the buffer for bursts of arriving packets. The tolerance to bursts of packets depends on the number of packets in the queue, which is directly linked to the AQM algorithm. Moreover, an AQM scheme may implement a feature that controls the maximum size of accepted bursts, which can depend on the buffer occupancy or the currently estimated queuing delay. The impact of the buffer size on the burst allowance may be evaluated 🧁.

7.2. Recommended Tests

For this scenario, the tester must evaluate how the AQM performs with a traffic mix. The traffic mix could be composed of the following (from sender A to receiver B):

Burst of packets at the beginning of a transmission, such as web traffic with IW10;
Applications that send large bursts of data, such as bursty video frames;
Background traffic, such as Constant Bit Rate (CBR) UDP traffic and/or A single non-application-limited bulk TCP flow as background traffic.

Figure 2 presents the various cases for the traffic that must be generated between sender A and receiver B 🎬.

   +-------------------------------------------------+
   |Case| Traffic Type                               |
   |    +-----+------------+----+--------------------+
   |    |Video|Web  (IW 10)| CBR| Bulk TCP Traffic   |
   +----|-----|------------|----|--------------------|
   |I   |  0  |     1      |  1 |         0          |
   +----|-----|------------|----|--------------------|
   |II  |  0  |     1      |  1 |         1          |
   |----|-----|------------|----|--------------------|
   |III |  1  |     1      |  1 |         0          |
   +----|-----|------------|----|--------------------|
   |IV  |  1  |     1      |  1 |         1          |
   +----+-----+------------+----+--------------------+

                    Figure 2: Bursty Traffic Scenarios

a new web page download could start after the previous web page download is finished. Each web page could be composed of at least 50 objects, and the size of each object should be at least 1 KB. Six TCP parallel connections should be generated to download the objects, with each parallel connection having an initial congestion window set to 10 packets 🌐.

For each of these scenarios, the graph described in Section 2.7 could be generated for each application. Metrics such as end-to-end latency, jitter, and flow completion time may be generated. For the cases of frame generation of bursty video traffic, as well as the choice of web traffic pattern, these details and their presentation are left to the testers 🎀.

8. Stability 🦢

8.1. Motivation

the safety of an AQM scheme is directly related to its stability under varying operating conditions, such as varying traffic profiles and fluctuating network conditions 🛡️. Since operating conditions can vary often, the AQM needs to remain stable under these conditions without the need for additional external tuning 💪.

Network devices can experience varying operating conditions depending on factors such as time of day, deployment scenario, etc. For example:

Traffic and congestion levels are higher during peak hours than off-peak hours.
In the presence of a scheduler, the draining rate of a queue can vary depending on the occupancy of other queues: a low load on a high-priority queue implies a higher draining rate for the lower-priority queues.
The capacity available can vary over time (e.g., a lossy channel, a link supporting traffic in a higher Diffserv class).

Whether or not the target context is a stable environment, the ability of an AQM scheme to maintain its control over the queuing delay and buffer occupancy can be challenged. This document proposes guidelines to assess the behavior of AQM schemes under varying congestion levels and varying draining rates 🌙.

8.2. Recommended Tests

note that the traffic profiles explained below comprise non-application-limited TCP flows. For each of the scenarios below, the graphs described in Section 2.7 should be generated, and the goodput of the various flows should be cumulated. For Section 8.2.5 and Section 8.2.6, they should incorporate the results on a per-phase basis as well 🧩.

Wherever the notion of time has been explicitly mentioned in this subsection, time 0 starts from the moment all TCP flows have already reached their congestion avoidance phase ⏱️💜.

8.2.1. Definition of the Congestion Level

okay so the congestion levels here are measured by the projected packet drop rate, and that gets worked out when there's no AQM scheme, just a plain drop-tail queue 🫶 When the bottleneck is shared among non-application-limited TCP flows, l_r (the loss rate projection) can be written as a function of N (the number of bulk TCP flows) and S (the sum of the bandwidth-delay product and the maximum buffer size, both counted in packets). This is based on Eq. 3 of [MORR2000] ✨

l_r = 0.76 * N^2 / S^2

N = S * SQRT(1/0.76) * SQRT(l_r)

ngl, these guidelines use loss rate to define the different congestion levels, but they don't claim that in other situations, measuring the congestion level gives you an accurate loss rate estimate, or the other way around 💅

8.2.2. Mild Congestion

this scenario is for checking how an AQM scheme reacts to a light load of incoming traffic that causes mild congestion, where packet drop rates are around 0.1% 🌸 The number of bulk flows needed to hit this level, N_mild, is:

N_mild = ROUND (0.036*S)

8.2.3. Medium Congestion

this one checks how an AQM scheme handles incoming traffic causing medium congestion, where packet drop rates are around 0.5% 🦋 The number of bulk flows needed for this level, N_med, is:

N_med = ROUND (0.081*S)

8.2.4. Heavy Congestion

and this is the heavy congestion scenario, for seeing how an AQM scheme reacts to incoming traffic causing heavy congestion, where packet drop rates are around 1% 🔥 The number of bulk flows needed for this level, N_heavy, is:

N_heavy = ROUND (0.114*S)

8.2.5. Varying the Congestion Level

this scenario is about how an AQM scheme copes with the congestion level changing during the experiment 🎀 Here the congestion level shifts on a large timescale. The phases you could use are: phase I -- mild congestion during 0-20 s; phase II -- medium congestion during 20-40 s; phase III -- heavy congestion during 40-60 s; phase I again, and so on 🌈

8.2.6. Varying Available Capacity

this scenario helps characterise how the AQM behaves and adapts when bandwidth changes 🦋 The experiments aren't meant to match the exact conditions of Wi-Fi environments, since it's hard to design repeatable experiments or accurate simulations for those ✨

To copy varying draining rates, the bottleneck capacity between nodes 'Router L' and 'Router R' changes over the course of the experiment like this:

Experiment 1: The capacity varies between two values within a large timescale. As an example, the phases could be: phase I -- 100 Mbps during 0-20 s; phase II -- 10 Mbps during 20-40 s; phase I again, and so on.
Experiment 2: The capacity varies between two values within a short timescale. As an example, the phases could be: phase I -- 100 Mbps during 0-100 ms; phase II -- 10 Mbps during 100-200 ms; phase I again, and so on.

The tester can pick a phase time-interval value that's different from the one above if the network's path conditions (like the bandwidth-delay product) call for it. If they do, the choice of interval should be stated and explained 🧚

The tester can also check the two scenarios above (short-term and long-term capacity variations) during and/or including the TCP slow-start phase 💜

More realistic fluctuating capacity patterns are also fair game. The tester can build in realistic scenarios based on common bandwidth fluctuations in state-of-the-art technologies 🌸

The scenario uses TCP NewReno flows between sender A and receiver B. To better assess how draining rates affect AQM behaviour, the tester must compare its performance with drop-tail, and should provide a reference document for their proposal that discusses performance and deployment compared to drop-tail 👑 Burst traffic, like the kind presented in Section 7.2, could also be used to see how varying available capacity affects the AQM's burst absorption 💅

8.3. Parameter Sensitivity and Stability Analysis

the control law an AQM uses is the main way queuing delay gets controlled, so understanding the control law is key to understanding how the AQM behaves 🧠 The control law can include several input parameters whose values affect the AQM scheme's output behaviour and its stability. On top of that, AQM schemes may auto-tune parameter values to stay stable under different network conditions (like different congestion levels, draining rates, or network environments). Understanding the stability of those auto-tuning techniques matters too 🫶

Transports running under AQM control feel the effect of multiple control loops that react over different timescales. So it's important that proposed AQM schemes are seen to be stable when they're deployed at multiple points of potential congestion along an Internet path 🔥 The pattern of congestion signals (loss or ECN-marking) coming from AQM methods also needs to not adversely interact with the dynamics of the transport protocols they control 💀

AQM proposals should provide background material with a theoretical analysis of the AQM control law and the input parameter space the control law operates in, or they should use another way to discuss the stability of the control law. For parameters that are auto-tuned, the material should also include a stability analysis of the auto-tuning mechanism(s). This kind of analysis helps everyone understand an AQM control law better, plus the network conditions and deployments where the AQM stays stable ✨

9. Various Traffic Profiles 🌈

This section gives guidelines for assessing the performance of an AQM proposal across various traffic profiles, like traffic from different applications or bidirectional traffic 💖

9.1. Traffic Mix

this scenario checks how an AQM scheme reacts to a traffic mix made of different applications, such as:

Bulk TCP transfer
Web traffic
VoIP
Constant Bit Rate (CBR) UDP traffic
Adaptive video streaming (either unidirectional or bidirectional)

You can consider various traffic mixes. These guidelines recommend examining at least this example: 1 bidirectional VoIP; 6 web page downloads (such as those detailed in Section 7.2); 1 CBR; 1 Adaptive Video; 5 bulk TCP. Any other combinations can be considered too, but they should be carefully documented 🎀

For each scenario, the graph described in Section 2.7 could be generated for each class of traffic. Metrics like end-to-end latency, jitter, and flow completion time may be reported 📊

9.2. Bidirectional Traffic

control packets like DNS requests/responses and TCP SYNs/ACKs are small, but losing them can seriously hurt application performance 😭 The scenario in this section helps assess whether introducing an AQM scheme increases the loss probability of these important packets 🫶

For this scenario, traffic must be generated in both downlink and uplink, as defined in Section 3.1. How asymmetric the uplink and downlink are depends on the context. These guidelines recommend considering a mild congestion level and the traffic presented in Section 8.2.2 in both directions. In this case, the metrics reported must be the same as in Section 8.2 for each direction 🦋

The traffic mix presented in Section 9.1 may also be generated in both directions 🌸

10. Example of a Multi-AQM Scenario 🧚

10.1. Motivation

transports running under AQM control feel the effect of multiple control loops that react over different timescales. So it's important that proposed AQM schemes are seen to be stable when they're deployed at multiple points of potential congestion along an Internet path 💜 The pattern of congestion signals (loss or ECN-marking) coming from AQM methods also needs to not adversely interact with the dynamics of the transport protocols they control 👑

10.2. Details on the Evaluation Scenario

   +---------+                              +-----------+
   |senders A|---+                      +---|receivers A|
   +---------+   |                      |   +-----------+
           +-----+---+  +---------+  +--+-----+
           |Router L |--|Router M |--|Router R|
           |AQM A    |  |AQM M    |  |No AQM  |
           +---------+  +--+------+  +--+-----+
   +---------+             |            |   +-----------+
   |senders B|-------------+            +---|receivers B|
   +---------+                              +-----------+

               Figure 3: Topology for the Multi-AQM Scenario

Figure 3 shows topology options for evaluating multi-AQM scenarios 🗺️ The AQM schemes are applied in sequence, and they affect the induced latency reduction, the induced goodput maximization, and the trade-off between the two. Note that the AQM schemes A and B introduced in Routers L and M could be (I) the same scheme with identical parameter values, (ii) the same scheme with different parameter values, or (iii) two different schemes 💅 To best understand the interactions and implications, the mild congestion scenario described in Section 8.2.2 is recommended, with the number of flows equally shared among senders A and B. Other relevant combinations of congestion levels could also be considered. We recommend measuring the metrics presented in Section 8.2 ✨

11. Implementation Cost 🛠️

11.1. Motivation

successful AQM deployment is directly tied to how much it costs to implement. Network devices may need hardware or software implementations of the AQM mechanism. Depending on a device's capabilities and limitations, the device may or may not be able to implement some or all parts of its AQM logic 🤔

AQM proposals should provide pseudocode for the complete AQM scheme, highlighting generic implementation-specific aspects like "drop-tail" vs. "drop-head", inputs (e.g., current queuing delay, and queue length), computations involved, need for timers, etc. This helps identify the costs of implementing the AQM scheme on a particular hardware or software device. It also helps with discussions about which kinds of devices can easily support the AQM and which can't 🧠

11.2. Recommended Discussion

AQM proposals should highlight the parts of their AQM logic that depend on the device, and discuss whether and how AQM behaviour could be affected by the device 🫶 For example, a queuing-delay-based AQM scheme needs the current queuing delay as input from the device. If the device already keeps this value, implementing the AQM logic on the device can be trivial 🙌 If the device only offers indirect ways to estimate the queuing delay (for example, timestamps and dequeuing rate), then the AQM behaviour is sensitive to the precision of the queuing delay estimations for that device. Highlighting how sensitive an AQM scheme is to queuing delay estimations helps implementers figure out good ways to put the mechanism on a device 💖

12. Operator Control and Auto-Tuning 👑

12.1. Motivation ✨

Okay bestie, the BIGGEST hurdle with RED was (and honestly still is 😭) its parameter sensitivity to operating conditions. It is really hard to tune RED parameters for a deployment so you actually get good benefit from it. Fluctuating congestion levels and network conditions make it even messier. Wrong parameter values lead to poor performance, no cap. 💀

Any AQM scheme is likely to have parameters that change how its control law and behavior work. If you expose all of them as control parameters to a network operator (or user), it can easily lead to an unsafe AQM deployment 🙈. Unexpected AQM behavior shows up when the values are set improperly. So a minimal number of control parameters means fewer ways someone can break the system where the AQM is deployed 🎀. Fewer control parameters make the AQM more user-friendly and easier to deploy and debug. That's the energy we want 💅

As stated in Section 4 of the AQM recommendation document [RFC7567]: "AQM algorithms SHOULD NOT require tuning of initial or configuration parameters in common use cases." 🫶 A scheme ought to expose only the parameters that control the macroscopic AQM behavior, such as queue delay threshold, queue length threshold, etc.

Also, the safety of an AQM scheme is directly tied to how stable it stays under varying operating conditions, like varying traffic profiles and fluctuating network conditions (see Section 8 🦋). Operating conditions change constantly, so the AQM needs to stay stable under them without extra external tuning. If AQM parameters do need tuning under these conditions, then the AQM must self-adapt the necessary parameter values by using auto-tuning techniques. ✨ Auto-tuning is the main character here.

12.2. Recommended Discussion

In order to understand an AQM's deployment considerations and performance in a specific environment, AQM proposals should describe the parameters that control the macroscopic AQM behavior, and identify any parameters that require tuning to operational conditions. 🧚 It could be interesting to also discuss that, even if an AQM scheme may not adequately auto-tune its parameters, the resulting performance may not be optimal, but close to something reasonable.

If there are any fixed parameters within the AQM, their settings should be discussed and justified, so people can understand whether a fixed parameter value is applicable for a particular environment 🌸.

If an AQM scheme is evaluated with parameter(s) that were externally tuned for optimization or other purposes, these values must be disclosed. No hiding the receipts 👀📝.

13. Summary 💜

Figure 4 lists the scenarios for an extended characterization of an AQM scheme. This table comes along with a set of requirements to present more clearly the weight and importance of each scenario. The requirements listed here are informational, and their relevance may depend on the deployment scenario. ✨

+------------------------------------------------------------------+
|Scenario                   |Sec.  |Informational requirement      |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
|Interaction with ECN       | 4.5  |must be discussed if supported |
+------------------------------------------------------------------+
|Interaction with Scheduling| 4.6  |should be discussed            |
+------------------------------------------------------------------+
|Transport Protocols        | 5    |                               |
| TCP-friendly sender       | 5.1  |scenario must be considered    |
| Aggressive sender         | 5.2  |scenario must be considered    |
| Unresponsive sender       | 5.3  |scenario must be considered    |
| LBE sender                | 5.4  |scenario may be considered     |
+------------------------------------------------------------------+
|Round-Trip Time Fairness   | 6.2  |scenario must be considered    |
+------------------------------------------------------------------+
|Burst Absorption           | 7.2  |scenario must be considered    |
+------------------------------------------------------------------+
|Stability                  | 8    |                               |
| Varying congestion levels | 8.2.5|scenario must be considered    |
| Varying available capacity| 8.2.6|scenario must be considered    |
| Parameters and stability  | 8.3  |this should be discussed       |
+------------------------------------------------------------------+
|Various Traffic Profiles   | 9    |                               |
| Traffic mix               | 9.1  |scenario is recommended        |
| Bidirectional traffic     | 9.2  |scenario may be considered     |
+------------------------------------------------------------------+
|Multi-AQM                  | 10.2 |scenario may be considered     |
+------------------------------------------------------------------+

Figure 4: Summary of the Scenarios and their Requirements 📊🌈

14. Security Considerations 🔐

Some security considerations for AQM are identified in [RFC7567]. This document, by itself, presents no new privacy or security issues. Phew, lowkey relieved 😮‍💨🫶

15. References 📚

15.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, 1997.

[RFC2544]  Bradner, S. and J. McQuaid, "Benchmarking Methodology for
           Network Interconnect Devices", RFC 2544,
           DOI 10.17487/RFC2544, March 1999,
           <http://www.rfc-editor.org/info/rfc2544>.

[RFC2647]  Newman, D., "Benchmarking Terminology for Firewall
           Performance", RFC 2647, DOI 10.17487/RFC2647, August 1999,
           <http://www.rfc-editor.org/info/rfc2647>.

[RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
           Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
           March 2009, <http://www.rfc-editor.org/info/rfc5481>.

[RFC7567]  Baker, F., Ed. and G. Fairhurst, Ed., "IETF
           Recommendations Regarding Active Queue Management",
           BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
           <http://www.rfc-editor.org/info/rfc7567>.

[RFC7679]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
           Ed., "A One-Way Delay Metric for IP Performance Metrics
           (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
           2016, <http://www.rfc-editor.org/info/rfc7679>.

[RFC7680]  Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
           Ed., "A One-Way Loss Metric for IP Performance Metrics
           (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
           2016, <http://www.rfc-editor.org/info/rfc7680>.

15.2. Informative References 📚✨

Okay bestie, here's the extra-credit reading list 🧠💖 These are the ones that give background and context but aren't required to understand the main ideas.

   [ANEL2014] Anelli, P., Diana, R., and E. Lochin, "FavorQueue: a
              Parameterless Active Queue Management to Improve TCP
              Traffic Performance", Computer Networks Vol. 60,
              DOI 10.1016/j.bjp.2013.11.008, 2014.

   [AQMPIE]   Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A
              Lightweight Control Scheme To Address the Bufferbloat
              Problem", Work in Progress, draft-ietf-aqm-pie-08, June
              2016.

   [BB2011]   Cerf, V., Jacobson, V., Weaver, N., and J. Gettys,
              "BufferBloat: what's wrong with the internet?", ACM
              Queue Vol. 55, DOI 10.1145/2076450.2076464, 2012.

   [BCP41]    Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, September 2000.

              Briscoe, B. and J.  Manner, "Byte and Packet Congestion
              Notification", BCP 41, RFC 7141, February 2014.

              <http://www.rfc-editor.org/info/bcp41>

   [CODEL]    Nichols, K., Jacobson, V., McGregor, A., and J. Iyengar,
              "Controlled Delay Active Queue Management", Work in
              Progress, draft-ietf-aqm-codel-04, June 2016.

   [CUBIC]    Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
              R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
              Work in Progress, draft-ietf-tcpm-cubic-01, January 2016.

   [FENG2002] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE
              active queue management algorithms", IEEE Transactions on
              Networking Vol.10 Issue 4, DOI 10.1109/TNET.2002.801399,
              2002, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=1026008>.

   [FLOY1993] Floyd, S. and V. Jacobson, "Random Early Detection (RED)
              Gateways for Congestion Avoidance", IEEE Transactions on
              Networking Vol. 1 Issue 4, DOI 10.1109/90.251892, 1993,
              <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=251892>.

   [GONG2014] Gong, Y., Rossi, D., Testa, C., Valenti, S., and D. Taht,
              "Fighting the bufferbloat: on the coexistence of AQM and
              low priority congestion control", Computer Networks,
              Elsevier, 2014, pp.115-128 Vol. 60,
              DOI 10.1109/INFCOMW.2013.6562885, 2014.

   [HASS2008] Hassayoun, S. and D. Ros, "Loss Synchronization and Router
              Buffer Sizing with High-Speed Versions of TCP",
              IEEE INFOCOM Workshops, DOI 10.1109/INFOCOM.2008.4544632,
              2008, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=4544632>.

   [HOEI2015] Hoeiland-Joergensen, T., McKenney, P.,
              dave.taht@gmail.com, d., Gettys, J., and E. Dumazet, "The
              FlowQueue-CoDel Packet Scheduler and Active Queue
              Management Algorithm", Work in Progress, draft-ietf-aqm-
              fq-codel-06, March 2016.

   [HOLLO2001]
              Hollot, C., Misra, V., Towsley, V., and W. Gong, "On
              Designing Improved Controller for AQM Routers Supporting
              TCP Flows", IEEE INFOCOM, DOI 10.1109/INFCOM.2001.916670,
              2001, <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=916670>.

   [JAY2006]  Jay, P., Fu, Q., and G. Armitage, "A preliminary analysis
              of loss synchronisation between concurrent TCP flows",
              Australian Telecommunication Networks and Application
              Conference (ATNAC), 2006.

   [MORR2000] Morris, R., "Scalable TCP congestion control",
              IEEE INFOCOM, DOI 10.1109/INFCOM.2000.832487, 2000,
              <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=832487>.

   [RFC793]   Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2309]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
              S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
              Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
              S., Wroclawski, J., and L. Zhang, "Recommendations on
              Queue Management and Congestion Avoidance in the
              Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
              <http://www.rfc-editor.org/info/rfc2309>.

   [RFC2488]  Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
              Over Satellite Channels using Standard Mechanisms",
              BCP 28, RFC 2488, DOI 10.17487/RFC2488, January 1999,
              <http://www.rfc-editor.org/info/rfc2488>.

   [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,
              <http://www.rfc-editor.org/info/rfc3168>.

   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
              "RTP Control Protocol Extended Reports (RTCP XR)",
              RFC 3611, DOI 10.17487/RFC3611, November 2003,
              <http://www.rfc-editor.org/info/rfc3611>.

   [RFC5348]  Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
              Friendly Rate Control (TFRC): Protocol Specification",
              RFC 5348, DOI 10.17487/RFC5348, September 2008,
              <http://www.rfc-editor.org/info/rfc5348>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
              <http://www.rfc-editor.org/info/rfc5681>.

   [RFC6297]  Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort
              Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June
              2011, <http://www.rfc-editor.org/info/rfc6297>.

   [RFC6817]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
              "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
              DOI 10.17487/RFC6817, December 2012,
              <http://www.rfc-editor.org/info/rfc6817>.

   [RFC7141]  Briscoe, B. and J. Manner, "Byte and Packet Congestion
              Notification", BCP 41, RFC 7141, DOI 10.17487/RFC7141,
              February 2014, <http://www.rfc-editor.org/info/rfc7141>.

   [TCPEVAL]  Hayes, D., Ros, D., Andrew, L., and S. Floyd, "Common TCP
              Evaluation Suite", Work in Progress, draft-irtf-iccrg-
              tcpeval-01, July 2014.

   [TRAN2014] Trang, S., Kuhn, N., Lochin, E., Baudoin, C., Dubois, E.,
              and P. Gelard, "On The Existence Of Optimal LEDBAT
              Parameters", IEEE ICC 2014 - Communication
              QoS, Reliability and Modeling Symposium,
              DOI 10.1109/ICC.2014.6883487, 2014,
              <http://ieeexplore.ieee.org/xpl/
              articleDetails.jsp?arnumber=6883487>.

   [WELZ2015] Welzl, M. and G. Fairhurst, "The Benefits to Applications
              of using Explicit Congestion Notification (ECN)", Work in
              Progress, draft-welzl-ecn-benefits-02, March 2015.

   [WINS2014] Winstein, K., "Transport Architectures for an Evolving
              Internet", PhD thesis, Massachusetts Institute of
              Technology, June 2014.

Acknowledgements 🫶

This work got partial support from the European Community under its Seventh Framework Programme, through the Reducing Internet Transport Latency (RITE) project (ICT-317700) 🇪🇺💜

Huge thank you to S. Akhtar, A.B. Bagayoko, F. Baker, R. Bless, D. Collier-Brown, G. Fairhurst, J. Gettys, P. Goltsman, T. Hoiland-Jorgensen, K. Kilkki, C. Kulatunga, W. Lautenschlager, A.C. Morton, R. Pan, G. Skinner, D. Taht, and M. Welzl for the detailed and wise feedback on this document. You all are literally the reason this doc slaps 👑🙈

Authors' Addresses 🦋

   Nicolas Kuhn (editor)
   CNES, Telecom Bretagne
   18 avenue Edouard Belin
   Toulouse  31400
   France

   Phone: +33 5 61 27 32 13
   Email: nicolas.kuhn@cnes.fr


   Preethi Natarajan (editor)
   Cisco Systems
   510 McCarthy Blvd
   Milpitas, California
   United States of America

   Email: prenatar@cisco.com


   Naeem Khademi (editor)
   University of Oslo
   Department of Informatics, PO Box 1080 Blindern
   N-0316 Oslo
   Norway

   Phone: +47 2285 24 93
   Email: naeemk@ifi.uio.no


   David Ros
   Simula Research Laboratory AS
   P.O. Box 134
   Lysaker, 1325
   Norway

   Phone: +33 299 25 21 21
   Email: dros@simula.no

📦 where this page comes from

ietf: rfc7928 2016-07
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms