RFC 7567

IETF Recommendations Regarding Active Queue Management

📅 published July 2015, from ietf

1. Introduction ✨

Okay bestie, let's start with the basics 🎀. This is RFC 7567, titled IETF Recommendations Regarding Active Queue Management, and it's a Best Current Practice (that's BCP 197 🌸). The editors are F. Baker, from Cisco Systems, and G. Fairhurst, from the University of Aberdeen. It was published in July 2015 with ISSN 2070-1721. It obsoletes RFC 2309, so this is the new and improved version of the old AQM recs 💅.

Abstract 📝

This memo gives the Internet community recommendations for improving and preserving Internet performance 💖. It strongly recommends that active queue management (AQM) gets tested, standardized, and widely deployed in network devices, so today's Internet runs better 🚀. It also pushes for a serious, coordinated effort around research, measurement, and eventual deployment of AQM mechanisms, which protects the Internet from flows that don't respond enough to congestion notification 🛡️.

It's based on 15 years of experience plus new research, and it replaces the recommendations of RFC 2309 🦋.

Status of This Memo 📜

This memo documents an Internet Best Current Practice 🌈.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on BCPs, check out Section 2 of RFC 5741 📚.

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

Copyright (c) 2015 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, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date 📜. Please read these carefully, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 💜.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🍓. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 😭. So without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 🚫. The exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌸.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Congestion Collapse . . . . . . . . . . . . . . . . . . .   4
  1.2.  Active Queue Management to Manage Latency . . . . . . . .   5
  1.3.  Document Overview . . . . . . . . . . . . . . . . . . . .   6
  1.4.  Changes to the Recommendations of RFC 2309  . . . . . . .   7
  1.5.  Requirements Language . . . . . . . . . . . . . . . . . .   7
2.  The Need for Active Queue Management  . . . . . . . . . . . .   7
  2.1.  AQM and Multiple Queues . . . . . . . . . . . . . . . . .  11
  2.2.  AQM and Explicit Congestion Marking (ECN) . . . . . . . .  12
  2.3.  AQM and Buffer Size . . . . . . . . . . . . . . . . . . .  12
3.  Managing Aggressive Flows . . . . . . . . . . . . . . . . . .  13
4.  Conclusions and Recommendations . . . . . . . . . . . . . . .  16
  4.1.  Operational Deployments SHOULD Use AQM Procedures . . . .  17
  4.2.  Signaling to the Transport Endpoints  . . . . . . . . . .  17
    4.2.1.  AQM and ECN . . . . . . . . . . . . . . . . . . . . .  18
  4.3.  AQM Algorithm Deployment SHOULD NOT Require Operational
        Tuning  . . . . . . . . . . . . . . . . . . . . . . . . .  20
  4.4.  AQM Algorithms SHOULD Respond to Measured Congestion, Not
        Application Profiles  . . . . . . . . . . . . . . . . . .  21
  4.5.  AQM Algorithms SHOULD NOT Be Dependent on Specific
        Transport Protocol Behaviors  . . . . . . . . . . . . . .  22
  4.6.  Interactions with Congestion Control Algorithms . . . . .  22
  4.7.  The Need for Further Research . . . . . . . . . . . . . .  23
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  25
6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  25
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  26
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  31
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

1.1. Congestion Collapse 🌊

Okay so the Internet protocol architecture is built on a connectionless, end-to-end packet service that uses the Internet Protocol, whether that's IPv4 [RFC791] or IPv6 [RFC2460] 🌐. Being connectionless gives you flexibility and robustness, and that's been proven over and over 💪. But those perks don't come free: careful design is needed to keep service good under heavy load 😤. If nobody pays attention to how packets move through the network, you can get severe service degradation, or what people called "Internet meltdown" 💀. This showed up during the early growth of the Internet in the mid 1980s [RFC896] [RFC970], and it's technically called "congestion collapse". It was a key focus of RFC 2309 💜.

Wide-scale congestion collapse isn't common on the Internet, but localized congestion collapse is honestly not rare at all 👀. So it's important to keep avoiding congestion collapse 🫶.

Since RFC 2309 was written in 1998, the Internet has been used for way more kinds of traffic 📱. Right now, low latency matters a LOT for interactive and transaction-based apps 🎮. The same technology RFC 2309 pushed for to fight congestion collapse also works really well at limiting delays, which cuts the interaction delay (latency) that apps feel [Bri15] ⚡. High or unpredictable latency can mess with the control loops that end-to-end protocols depend on, including congestion control algorithms using TCP 😵‍💫. Now there's also a big focus on cutting network latency with that same technology 🌸.

The mechanisms in this document may be implemented in network devices on the path between endpoints, like routers, switches, and other network middleboxes 🧚. The methods may also be implemented in the networking stacks inside endpoint devices that connect to the network 💅.

The original fix for Internet meltdown came from Van Jacobsen ✨. Starting in 1986, Jacobsen developed the congestion avoidance mechanisms [Jacobson88] that are now required for implementations of the Transport Control Protocol (TCP) [RFC793] [RFC1122] 👑. ([RFC7414] is a roadmap that helps you find TCP-related documents 🗺️.) These mechanisms run in Internet hosts and make TCP connections "back off" during congestion 🙌. We say TCP flows are "responsive" to congestion signals, meaning packets that get dropped or marked with explicit congestion notification [RFC3168] 🦋. Honestly, these TCP congestion avoidance algorithms are the main reason today's Internet doesn't suffer congestion collapse. Similar algorithms are specified for other non-TCP transports too 🌈.

But wait, that's not the end of the story 👀. A lot of research on Internet dynamics has happened since 1988, and the Internet has grown a ton 📈. It's become clear that the congestion avoidance mechanisms [RFC5681] are necessary and powerful, but they aren't enough to give good service in every situation 😬. Basically, there's a limit to how much control you can get from the edges of the network 🫠. So some mechanisms are needed inside network devices to complement the endpoint congestion avoidance mechanisms 🎀. These mechanisms may be implemented in network devices 💖.

1.2. Active Queue Management to Manage Latency ⏱️

Internet latency has become a major focus, because it makes Internet applications and protocols way more responsive 🚀. One big source of delay is queues building up in network devices 😩. Queueing happens whenever data arrives at a device's ingress faster than it can leave at the current egress rate 🌊. Queueing is totally normal in a packet-switched network, and it's often needed to absorb bursts in transmission and do statistical multiplexing of traffic 🧃. But too much queueing causes unwanted delay, and that drags down the performance of some Internet applications 💀.

RFC 2309 introduced the concept of "Active Queue Management" (AQM) 🎉. AQM is a class of technologies that signals common congestion-controlled transports like TCP, so it can manage how big the queues get in network buffers 💅. RFC 2309 also described a specific AQM algorithm, Random Early Detection (RED), and recommended that it be widely implemented and used by default in routers 👑.

RED is an effective algorithm when it has the right set of parameters 🌸. The problem is that predicting that set of parameters dynamically turned out to be hard 😵. Because of that, RED hasn't been turned on by default, so its use on the Internet is pretty limited 🥲. Other AQM algorithms have been developed since RFC 2309 came out, and some of them are self-tuning within a range of applicability 🧠. So while this memo still recommends deploying AQM, it no longer recommends RED or any other specific algorithm be used by default 💜. Instead, it gives recommendations on IETF processes for picking appropriate algorithms, and especially that a recommended algorithm can automate any required tuning for common deployment scenarios 🎀.

Deploying AQM in the network can significantly reduce latency across an Internet path, and since RFC 2309 was written, that's become a key reason to use AQM on the Internet 🦋. In the AQM world, it's useful to tell apart two related classes of algorithms: "queue management" and "scheduling" 🧚. Roughly speaking, queue management algorithms manage packet queue length by marking or dropping packets when needed or appropriate ✨. Scheduling algorithms decide which packet to send next, and they're mainly used to manage how bandwidth gets shared among flows 🌈. These two are closely related, but they tackle different performance issues and work on different timescales ⏳. You can use both together 🫶.

1.3. Document Overview ✨

okay bestie, so the stuff in this memo is about "best-effort" traffic 🎀. that's traffic from apps that are totally fine with the occasional loss, duplication, or reordering of packets in flight 🦋. it also covers other traffic too, like real-time stuff that can adjust its sending rate to cut down on loss and/or delay 💅. it works best when that adjusting happens on timescales of a single Round-Trip Time (RTT) or a small number of RTTs, for elastic traffic [RFC1633] 🌸.

there are two performance issues the memo really wants to spotlight 👑:

The first issue is the need for a more advanced kind of queue management that we call "Active Queue Management", AQM 💖. Section 2 breaks down the benefits active queue management can bring ✨. there are a bunch of AQM procedures out there in the literature, and they all have different characteristics 🌈. this document does not recommend any of them in particular 🙈, but it does make recommendations that ideally would shape which procedure gets picked in a given implementation 💜.

The second issue, which we dig into in Section 4 of this memo, is the potential for future congestion collapse of the Internet 💀. that happens because of flows that are unresponsive, or not sufficiently responsive, to congestion indications 😭. the tea is that scheduling can help soften some of the side effects of sharing a network queue with an unresponsive flow 🍓, but there is currently no consensus solution for controlling the congestion caused by such aggressive flows 💅. methods like congestion exposure (ConEx) [RFC6789] offer a framework [CONEX] that can update network devices to alleviate these effects 🧚. significant research and engineering will be required before any solution is available 🔥. it is imperative that work to mitigate the impact of unresponsive flows is energetically pursued 💖, to ensure acceptable performance and the future stability of the Internet ✨🫶.

Section 4 wraps up the memo with a set of recommendations for the Internet community on using AQM, plus recommendations for defining AQM algorithms 🦋.

1.4. Changes to the Recommendations of RFC 2309 🌷

this memo replaces the recommendations in [RFC2309] 💅, which came out of past discussions about end-to-end performance, Internet congestion, and RED in the End-to-End Research Group of the Internet Research Task Force (IRTF) 🎀. it's built on experience with RED and other algorithms, plus the AQM discussion within the IETF [AQM-WG] ✨.

so here's the glow-up 🌈: whereas RFC 2309 described AQM in terms of the length of a queue, this memo uses AQM to refer to any method that lets network devices control the queue length and/or the mean time a packet spends in a queue 💜.

this memo also explicitly obsoletes the recommendation that Random Early Detection (RED) be used as the default AQM mechanism for the Internet 😭. it gets replaced by a detailed set of recommendations for selecting an appropriate AQM algorithm 👑. just like RFC 2309, this memo shows that continued research is needed 🔥, and it clarifies the research needed using examples that were appropriate when this memo was published 🫶.

1.5. 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 [RFC2119] 💖✨.

2. The Need for Active Queue Management ✨

okay so Active Queue Management (AQM) 💖 is a method that lets network devices control the queue length, or the mean time a packet spends sitting in a queue 🧚. AQM works across lots of deployment environments, but the recommendations in this doc are for the general Internet 🌐. The principles and guidance are expected to apply to a wide range of environments too, but they may need tuning for specific types of links or networks (e.g., to handle the traffic patterns in data centers, the challenges of wireless infrastructure, or the higher delay on satellite Internet links) 🛰️. The rest of this section explains why we need AQM and what deploying it gets you ✨.

The traditional way to manage queue length in a network device is to set a maximum length (in packets) for each queue, accept packets until that max is reached, then reject (drop) incoming packets until the queue shrinks because a packet from it got transmitted. This is called "tail drop" 🙈, since the packet that arrived most recently (the one on the tail of the queue) is the one that gets dropped when the queue is full. Tail drop has served the Internet well for years, but it has four important drawbacks 💀:

  1. Full Queues

Tail drop lets queues stay full (or almost full) for long periods, since it only signals congestion (via a packet drop) once the queue has already become full. Keeping the steady-state queue size down is important, and it's probably the most important goal for queue management 🎯.

The naive assumption is that there's a simple trade-off between delay and throughput, so keeping queues in a "non-full" state basically means low end-to-end delay matters more than high throughput. But that ignores the critical role packet bursts play in Internet performance 👀. For example, even though TCP constrains the congestion window of a flow, packets often arrive at network devices in bursts [Leland94]. If the queue is full or almost full, an arriving burst causes multiple packets from the same flow to get dropped. Bursts of loss can result in global synchronization of flows throttling back, followed by a sustained period of lowered link utilization, which reduces overall throughput [Flo94] [Zha90] 📉.

The goal of buffering in the network is to absorb data bursts and transmit them during the (hopefully) ensuing bursts of silence 🌊. That's essential for letting bursts of data get through. Queues that are normally small are preferred in network devices, with enough queue capacity to absorb the bursts. The counterintuitive result is that keeping queues normally small can give you higher throughput and lower end-to-end delay 🤯. So in summary, queue limits should not reflect the steady-state queues we want to maintain in the network; instead, they should reflect the size of bursts that a network device needs to absorb 💅.

  1. Lock-Out

In some situations tail drop lets a single connection or a few flows monopolize the queue space, starving other connections and stopping them from getting room in the queue [Flo92] 😤.

  1. Mitigating the Impact of Packet Bursts

A large burst of packets can delay other packets, which disrupts the control loop (e.g., the pacing of flows by the TCP ACK clock) and reduces the performance of flows that share a common bottleneck 🫠.

  1. Control Loop Synchronization

Congestion control, like other end-to-end mechanisms, introduces a control loop between hosts. Sessions that share a common network bottleneck can therefore become synchronized, introducing periodic disruption (e.g., jitter/loss). "Lock-out" is often also the result of synchronization or other timing effects

Besides tail drop, two alternative queue management disciplines that can be applied when a queue becomes full are "random drop on full" or "head drop on full" 🎲. When a new packet arrives at a full queue using the "random drop on full" discipline, the network device drops a randomly selected packet from the queue (this can be an expensive operation, since it naively requires an O(N) walk through the packet queue) 😬. When a new packet arrives at a full queue using the "head drop on full" discipline, the network device drops the packet at the front of the queue [Lakshman96]. Both of these solve the lock-out problem, but neither solves the full-queues problem described above 🙅‍♀️.

In general, we know how to solve the full-queues problem for "responsive" flows, i.e., those flows that throttle back in response to congestion notification 🦋. In the current Internet, dropped packets provide a critical mechanism for indicating congestion notification to hosts. The solution to the full-queues problem is for network devices to drop or ECN-mark packets before a queue becomes full, so that hosts can respond to congestion before buffers overflow. We call this proactive approach AQM 🎀. By dropping or ECN-marking packets before buffers overflow, AQM lets network devices control when and how many packets to drop.

In summary, an active queue management mechanism can provide the following advantages for responsive flows 👑:

  1. Reduce number of packets dropped in network devices

Packet bursts are an unavoidable aspect of packet networks [Willinger95] 🌪️. If all the queue space in a network device is already committed to "steady-state" traffic, or if the buffer space is inadequate, the device has no ability to buffer bursts. By keeping the average queue size small, AQM gives more capacity to absorb naturally occurring bursts without dropping packets ✨.

Furthermore, without AQM, more packets get dropped when a queue does overflow. That's undesirable for several reasons. First, with a shared queue and the "tail drop" discipline, this can cause unnecessary global synchronization of flows, which lowers average link utilization and, hence, lowers network throughput 📉. Second, unnecessary packet drops are a waste of network capacity on the path before the drop point 🗑️.

While AQM can manage queue lengths and reduce end-to-end latency even in the absence of end-to-end congestion control, it will only be able to reduce packet drops in an environment that continues to be dominated by end-to-end congestion control 🧠.

  1. Provide a lower-delay interactive service

By keeping a small average queue size, AQM reduces the delays experienced by flows. This is especially important for interactive applications such as short web transfers, POP/IMAP, DNS, terminal traffic (Telnet, SSH, Mosh, RDP, etc.), gaming, or interactive audio-video sessions 🎮, whose subjective (and objective) performance is better when the end-to-end delay is low 🍓.

  1. Avoid lock-out behavior

AQM can prevent lock-out behavior by ensuring that there will almost always be a buffer available for an incoming packet. For the same reason, AQM can prevent a bias against low-capacity, but highly bursty, flows 🫶.

Lock-out is undesirable because it constitutes a gross unfairness among groups of flows 😭. However, we stop short of calling this benefit "increased fairness", because general fairness among flows requires per-flow state, which queue management doesn't provide. For example, in a network device using AQM with only FIFO scheduling, two TCP flows may receive very different shares of the network capacity simply because they have different RTTs [Floyd91], and a flow that does not use congestion control may receive more capacity than a flow that does. AQM can therefore be combined with a scheduling mechanism that divides network traffic between multiple queues (Section 2.1) 🧩.

  1. Reduce the probability of control loop synchronization

The probability of network control loop synchronization can be reduced if network devices introduce randomness in the AQM functions that trigger congestion avoidance at the sending host 🎲✨.

2.1. AQM and Multiple Queues

A network device may use per-flow or per-class queueing with a scheduling algorithm to either prioritize certain applications or classes of traffic, limit the rate of transmission, or provide isolation between different traffic flows within a common class 🚦. For example, a router may maintain per-flow state to achieve general fairness with a per-flow scheduling algorithm such as various forms of Fair Queueing (FQ) [Dem90] [Sut99], including Weighted Fair Queueing (WFQ), Stochastic Fairness Queueing (SFQ) [McK90], Deficit Round Robin (DRR) [Shr96] [Nic12], and/or a Class-Based Queue scheduling algorithm such as CBQ [Floyd95]. Hierarchical queues may also be used, e.g., as a part of a Hierarchical Token Bucket (HTB) or Hierarchical Fair Service Curve (HFSC) [Sto97]. These methods are also used to realize a range of Quality of Service (QoS) behaviors designed to meet the needs of traffic classes (e.g., using the integrated or differentiated service models) 💅.

AQM is needed even for network devices that use per-flow or per-class queueing, because scheduling algorithms by themselves don't control the overall queue size or the sizes of individual queues 🙃. AQM mechanisms might need to control the overall queue sizes to ensure that arriving bursts can be accommodated without dropping packets. AQM should also be used to control the queue size for each individual flow or class, so that they don't experience unnecessarily high delay. Using a combination of AQM and scheduling between multiple queues has been shown to offer good results in experimental use and some types of operational use 🔥.

In short, scheduling algorithms and queue management are complementary, not replacements for each other 🫶🌸.

2.2. AQM and Explicit Congestion Marking (ECN)

An AQM method may use Explicit Congestion Notification (ECN) [RFC3168] instead of dropping to mark packets under mild or moderate congestion 🏳️‍🌈. ECN-marking can let a network device signal congestion at a point before a transport experiences congestion loss or additional queueing delay [ECN-Benefit]. Section 4.2.1 describes some of the benefits of using ECN with AQM 🦋✨.

2.3. AQM and Buffer Size

okay bestie, this one is super important 🫶 You have to tell apart the buffer size of a queue in a switch, router, or other network device from the thresholds and other parameters that decide how and when an AQM algorithm operates ✨ The optimum buffer size depends on operational requirements, and it should generally be big enough to hold the largest normal traffic burst you expect 🎀 That size depends on how much traffic arrives at the queue, how bursty it is, and how fast traffic leaves the queue 🧚

One goal of AQM is to minimize lock-out, which is when one flow stops other flows from effectively getting capacity 💅 Picture drop-tail queueing where a brand new TCP flow sends packets into a queue that's almost full 😭 A TCP flow's congestion control algorithm [RFC5681] keeps increasing the flow rate to max out its effective window 📈 That builds a queue in the network, which adds latency to this flow and every other flow sharing that queue 🙈 Once a drop-tail queue fills up, there's also loss 💀 The new flow, sending its initial burst, has a higher chance of filling the leftover space and dropping packets, so it can get locked out of effectively sharing the queue for many RTTs 😩 AQM is the glow-up here: it can minimize the mean queue depth, which lowers the chance that competing sessions seriously block each other from performing well 🦋

AQM also frees a designer from having to limit the buffer space assigned to a queue just to get acceptable performance 👑 That means you can allocate enough buffering to meet the needs of your particular traffic pattern ✨ Different types of traffic and deployment scenarios lead to different requirements 🌈 So the choice of AQM algorithm and its parameters depends on how congestion gets experienced and what reaction is needed to achieve acceptable performance 💖 That reaction is the main topic of the following sections 🎀

3. Managing Aggressive Flows 💜

One of the keys to the Internet's success has been the congestion avoidance mechanisms of TCP 👑 Because TCP "backs off" during congestion, a huge number of TCP connections can share one congested link, and the link bandwidth ends up shared reasonably equitably among similarly situated flows 🫶 That equitable sharing only works if all flows run compatible congestion avoidance algorithms, meaning methods that conform to the current TCP specification [RFC5681] 💅

In this document, a flow is called "TCP-friendly" when it has a congestion response that approximates the average response expected of a TCP flow 🦋 One example of a TCP-friendly scheme is the TCP-Friendly Rate Control algorithm [RFC5348] ✨ In this document the term is used more generally, to describe this and other algorithms that meet these goals 🌸

There's a whole variety of network flows out there 🧚 Some handy classes are: (1) TCP-friendly flows, (2) unresponsive flows, meaning flows that do not slow down when congestion occurs, and (3) flows that are responsive but less responsive to congestion than TCP 😤 The last two classes are the more aggressive flows, and they can pose a significant threat to Internet performance 🚨

  1. TCP-friendly flows

A TCP-friendly flow responds to congestion notification within a small number of path RTTs, and in steady-state it uses no more capacity than a conformant TCP running under comparable conditions (drop rate, RTT, packet size, etc.) 🌷 The rest of the document covers this 🎀

  1. Non-responsive flows

A non-responsive flow does not adjust its rate in response to congestion notification within a small number of path RTTs, and it can also use more capacity than a conformant TCP running under comparable conditions 😬 There's a growing set of applications whose congestion avoidance algorithms are inadequate or nonexistent, meaning a flow that doesn't throttle its sending rate when it hits congestion 💀

The User Datagram Protocol (UDP) [RFC768] gives applications and upper-layer protocols (both just called "applications" for the rest of this document) a minimal, best-effort transport 🌈 It doesn't provide mechanisms by itself to prevent congestion collapse or to establish any degree of fairness [RFC5405] 🙃

UDP is used by things like some streaming apps for packet voice and video, and some multicast bulk data transport 🎧 Other traffic can also become unresponsive to congestion notification when it's aggregated 🫠 If no action is taken, unresponsive flows like these could lead to a new congestion collapse [RFC2914] 😱 Some applications can even increase their traffic volume in response to congestion (for example, by adding Forward Error Correction when loss is experienced), and they might end up contributing to congestion collapse 💔

In general, applications need to incorporate effective congestion avoidance mechanisms [RFC5405] 💅 More research is still needed to find ways to accomplish congestion avoidance for presently unresponsive applications 🔬 Network devices need to be able to protect themselves against unresponsive flows, and mechanisms to do this must be developed and deployed 🛡️ Deploying those mechanisms would give every application an incentive to become responsive, either by using a congestion-controlled transport (e.g., TCP, SCTP [RFC4960], and DCCP [RFC4340]) or by building its own congestion control into the application [RFC5405] [RFC6679] 🥹✨

  1. Transport flows that are less responsive than TCP

A second threat comes from transport protocol implementations that respond to congestion but, either on purpose or through faulty implementation, reduce the effective window less than a TCP flow would in response to congestion 🫣 This covers a spectrum of behaviors between items (1) and (2) 🌗 If applications aren't responsive enough to congestion signals, they may grab an unfair share of the available network capacity 🤑

For example, the Internet's popularity has caused a proliferation of TCP implementations 📈 Some of these may fail to implement the TCP congestion avoidance mechanisms correctly because of poor implementation 🤦 Others may deliberately use congestion avoidance algorithms that are more aggressive with capacity than other TCP implementations, which would let a vendor claim to have a "faster TCP" 🏎️ The logical result of that would be a spiral of increasingly aggressive TCP implementations, leading right back to effectively no congestion avoidance and an Internet that's chronically congested 🥀

Another example could be an RTP/UDP video flow that uses an adaptive codec but responds incompletely to indications of congestion, or responds over an excessively long time period 📹

Flows like these are unlikely to respond to congestion signals within a time frame comparable to a small number of end-to-end transmission delays 🕰️ Over a longer timescale, perhaps seconds, they could moderate their speed, or increase it if they determine capacity is available 🌤️

Tunneled traffic aggregates carrying multiple (short) TCP flows can be more aggressive than standard bulk TCP 🚇 Applications like web browsers mainly supporting HTTP 1.1 and peer-to-peer file-sharing have exploited this by opening multiple connections to the same endpoint 🙊

Lastly, some applications (e.g., web browsers mainly supporting HTTP 1.1) open a large number of successive short TCP flows for a single session 🌪️ That can lead to each individual flow spending most of its time in the exponential TCP slow start phase, rather than in TCP congestion avoidance 🐢 The resulting traffic aggregate can therefore be much less responsive than a single standard TCP flow 😈

The projected increase in the fraction of total Internet traffic from more aggressive flows in classes 2 and 3 could threaten the performance of the future Internet 📉 So there's an urgent need for measurements of current conditions and for more research into ways of managing these flows 🚨 It raises many tricky issues, like finding methods with an acceptable overhead cost that can identify and isolate unresponsive flows, or flows that are less responsive than TCP 🧩 Finally, there's still very little measurement or simulation evidence about how fast these threats are likely to become real, or about the expected benefit of algorithms for managing such flows 🤷‍♀️💭

Another thing to think about is the right granularity of a "flow" when you're considering a queue management method 🍓 There are a few "natural" answers: 1) a transport (e.g., TCP or UDP) flow, meaning source address/port, destination address/port, protocol; 2) Differentiated Services Code Point, DSCP; 3) a source/destination host pair (IP address); 4) a given source host or a given destination host, or various combinations of the above; 5) a subscriber or site receiving the Internet service (enterprise or residential) 🧃

The source/destination host pair gives an appropriate granularity in many circumstances 🎯 But different vendors and providers use different granularities for defining a flow (kind of a way to "distinguish" themselves from each other 💅), and different granularities may be chosen for different places in the network 🗺️ It may even be that granularity matters less than the fact that a network device needs to be able to deal with more unresponsive flows at some granularity 🫶 The granularity of flows for congestion management is, at least in part, a question of policy that needs to be addressed in the wider IETF community 🌈🏛️

4. Conclusions and Recommendations ✨

okay so this is the big finale 💅 The IRTF wrote [RFC2309], and then the IETF kept talking about it, and together they came up with a set of specific recommendations for actually implementing and running AQM 🎀 Here's the recap, bestie:

  1. Network devices SHOULD implement some AQM mechanism to manage queue lengths, reduce end-to-end latency, and avoid lock-out phenomena within the Internet. 🌸
  2. Deployed AQM algorithms SHOULD support Explicit Congestion Notification (ECN) as well as loss to signal congestion to endpoints. 🦋
  3. AQM algorithms SHOULD NOT require tuning of initial or configuration parameters in common use cases. 🙈
  4. AQM algorithms SHOULD respond to measured congestion, not application profiles. 👑
  5. AQM algorithms SHOULD NOT interpret specific transport protocol behaviors. 🧚
  6. Congestion control algorithms for transport protocols SHOULD maximize their use of available capacity (when there is data to send) without incurring undue loss or undue round-trip delay. 🔥
  7. Research, engineering, and measurement efforts are needed regarding the design of mechanisms to deal with flows that are unresponsive to congestion notification or are responsive, but are more aggressive than present TCP. 💜

These recommendations are expressed using the word "SHOULD". This is in recognition that there may be use cases that have not been envisaged in this document in which the recommendation does not apply. Therefore, care should be taken in concluding that one's use case falls in that category; during the life of the Internet, such use cases have been rarely, if ever, observed and reported. To the contrary, available research [Choi04] says that even high-speed links in network cores that are normally very stable in depth and behavior experience occasional issues that need moderation. 🙃 The recommendations are detailed in the following sections.

4.1. Operational Deployments SHOULD Use AQM Procedures

AQM procedures are designed to minimize the delay and buffer exhaustion induced in the network by queues that have filled as a result of host behavior. Marking and loss behaviors provide a signal that buffers within network devices are becoming unnecessarily full and that the sender would do well to moderate its behavior. 💖

The use of scheduling mechanisms, such as priority queueing, classful queueing, and fair queueing, is often effective in networks to help a network serve the needs of a range of applications. Network operators can use these methods to manage traffic passing a choke point. This is discussed in [RFC2474] and [RFC2475]. When scheduling is used, AQM should be applied across the classes or flows as well as within each class or flow:

  • AQM mechanisms need to control the overall queue sizes to ensure that arriving bursts can be accommodated without dropping packets. 📦
  • AQM mechanisms need to allow combination with other mechanisms, such as scheduling, to allow implementation of policies for providing fairness between different flows. ⚖️
  • AQM should be used to control the queue size for each individual flow or class, so that they do not experience unnecessarily high delay. ✨

4.2. Signaling to the Transport Endpoints

There are a number of ways a network device may signal to the endpoint that the network is becoming congested and trigger a reduction in rate. The signaling methods include:

  • Delaying transport segments (packets) in flight, such as in a queue. 🐢
  • Dropping transport segments (packets) in transit. 💧
  • Marking transport segments (packets), such as using Explicit Congestion Control [RFC3168] [RFC4301] [RFC4774] [RFC6040] [RFC6679]. 🏷️

Increased network latency is used as an implicit signal of congestion. For example, in TCP, additional delay can affect ACK clocking and has the result of reducing the rate of transmission of new data. In the Real-time Transport Protocol (RTP), network latency impacts the RTCP-reported RTT, and increased latency can trigger a sender to adjust its rate. Methods such as Low Extra Delay Background Transport (LEDBAT) [RFC6817] assume increased latency as a primary signal of congestion. Appropriate use of delay-based methods and the implications of AQM presently remain an area for further research. 🔬

It is essential that all Internet hosts respond to loss [RFC5681] [RFC5405] [RFC4960] [RFC4340]. Packet dropping by network devices that are under load has two effects: It protects the network, which is the primary reason that network devices drop packets. The detection of loss also provides a signal to a reliable transport (e.g., TCP, SCTP) that there is incipient congestion, using a pragmatic but ambiguous heuristic. Whereas, when the network discards a message in flight, the loss may imply the presence of faulty equipment or media in a path, or it may imply the presence of congestion. To be conservative, a transport must assume it may be the latter. Applications using unreliable transports (e.g., using UDP) need to similarly react to loss [RFC5405]. 😬

Network devices SHOULD use an AQM algorithm to measure local congestion and to determine the packets to mark or drop so that the congestion is managed. 🎯

In general, dropping multiple packets from the same sessions in the same RTT is ineffective and can reduce throughput. Also, dropping or marking packets from multiple sessions simultaneously can have the effect of synchronizing them, resulting in increasing peaks and troughs in the subsequent traffic load. Hence, AQM algorithms SHOULD randomize dropping in time, to reduce the probability that congestion indications are only experienced by a small proportion of the active flows. 🎲

Loss due to dropping also has an effect on the efficiency of a flow and can significantly impact some classes of application. In reliable transports, the dropped data must be subsequently retransmitted. While other applications/transports may adapt to the absence of lost data, this still implies inefficient use of available capacity, and the dropped traffic can affect other flows. Hence, congestion signaling by loss is not entirely positive; it is a necessary evil. 🥲

4.2.1. AQM and ECN

Explicit Congestion Notification (ECN) [RFC4301] [RFC4774] [RFC6040] [RFC6679] is a network-layer function that allows a transport to receive network congestion information from a network device without incurring the unintended consequences of loss. ECN includes both transport mechanisms and functions implemented in network devices; the latter rely upon using AQM to decide when and whether to ECN-mark. 🦋

Congestion for ECN-capable transports is signaled by a network device setting the "Congestion Experienced (CE)" codepoint in the IP header. This codepoint is noted by the remote receiving endpoint and signaled back to the sender using a transport protocol mechanism, allowing the sender to trigger timely congestion control. The decision to set the CE codepoint requires an AQM algorithm configured with a threshold. Non-ECN capable flows (the default) are dropped under congestion. 🚦

Network devices SHOULD use an AQM algorithm that marks ECN-capable traffic when making decisions about the response to congestion. Network devices need to implement this method by marking ECN-capable traffic or by dropping non-ECN-capable traffic. 💅

Safe deployment of ECN requires that network devices drop excessive traffic, even when marked as originating from an ECN-capable transport. This is a necessary safety precaution because:

  1. A non-conformant, broken, or malicious receiver could conceal an ECN mark and not report this to the sender;
  2. A non-conformant, broken, or malicious sender could ignore a reported ECN mark, as it could ignore a loss without using ECN;
  3. A malfunctioning or non-conforming network device may "hide" an ECN mark (or fail to correctly set the ECN codepoint at an egress of a network tunnel). 🕵️

In normal operation, such cases should be very uncommon; however, overload protection is desirable to protect traffic from misconfigured or malicious use of ECN (e.g., a denial-of-service attack that generates ECN-capable traffic that is unresponsive to CE-marking). 🛡️

When ECN is added to a scheme, the ECN support MAY define a separate set of parameters from those used for controlling packet drop. The AQM algorithm SHOULD still auto-tune these ECN-specific parameters. These parameters SHOULD also be manually configurable. ⚙️

Network devices SHOULD use an algorithm to drop excessive traffic (e.g., at some level above the threshold for CE-marking), even when the packets are marked as originating from an ECN-capable transport. 🌈

4.3. AQM Algorithm Deployment SHOULD NOT Require Operational Tuning 🎀

Okay so a bunch of AQM algorithms have been proposed, and honestly? Lots of them need someone to tune parameters for the starting network conditions first 😩. That makes them kinda painful to use in real operational networks.

AQM algorithms need to think about both "initial conditions" and "operational conditions" 🧠. The first bucket is stuff that exists before the algorithm has gathered any experience, like the configured speed of the interface, support for full-duplex communication, the interface MTU, and other link properties. The second bucket is info you learn by watching things like the size of the queue, the queueing delay being experienced, and the rate of packet discard 👀.

So this document says AQM algorithms proposed for Internet deployment should have these properties:

  • AQM algorithm deployment SHOULD NOT require tuning. An algorithm MUST provide a default behavior that auto-tunes to a reasonable performance for typical network operational conditions. This is expected to ease deployment and operation. Initial conditions, such as the interface rate and MTU size or other values derived from these, MAY be required by an AQM algorithm. 💖
  • AQM algorithm deployment MAY support further manual tuning that could improve performance in a specific deployed network. Algorithms that lack such variables are acceptable, but, if such variables exist, they SHOULD be externalized (made visible to the operator). The specification should identify any cases in which auto-tuning is unlikely to achieve acceptable performance and give guidance on the parametric adjustments necessary. For example, the expected response of an algorithm may need to be configured to accommodate the largest expected Path RTT, since this value cannot be known at initialization. This guidance is expected to enable the algorithm to be deployed in networks that have specific characteristics (paths with variable or larger delay, networks where capacity is impacted by interactions with lower-layer mechanisms, etc). 🧚
  • AQM algorithm deployment MAY provide logging and alarm signals to assist in identifying if an algorithm using manual or auto-tuning is functioning as expected. (For example, this could be based on an internal consistency check between input, output, and mark/drop rates over time.) This is expected to encourage deployment by default and allow operators to identify potential interactions with other network functions. 📊

Hence, self-tuning algorithms are to be preferred. Algorithms recommended for general Internet deployment by the IETF need to be designed so that they do not require operational (especially manual) configuration or tuning. 🫶

4.4. AQM Algorithms SHOULD Respond to Measured Congestion, Not Application Profiles 🍓

Not all applications transmit packets of the same size 📦. Although applications may be characterized by particular profiles of packet size, this should not be used as the basis for AQM (see Section 4.5). Other methods exist, e.g., Differentiated Services queueing, Pre-Congestion Notification (PCN) [RFC5559], that can be used to differentiate and police classes of application. Network devices may combine AQM with these traffic classification mechanisms and perform AQM only on specific queues within a network device ✨.

An AQM algorithm should not deliberately try to prejudice the size of packet that performs best (i.e., preferentially drop/mark based only on packet size). Procedures for selecting packets to drop/mark SHOULD observe the actual or projected time that a packet is in a queue (bytes at a rate being an analog to time). When an AQM algorithm decides whether to drop (or mark) a packet, it is RECOMMENDED that the size of the particular packet not be taken into account [RFC7141] 🙅‍♀️.

Applications (or transports) generally know the packet size they are using, so they can make their own judgments about whether to use small or large packets based on the data they want to send and the expected impact on the delay, throughput, or other performance parameter 🧠. When a transport or application responds to a dropped or marked packet, the size of the rate reduction should be proportionate to the size of the packet that was sent [RFC7141] 💅.

An AQM-enabled system MAY instantiate different instances of an AQM algorithm to be applied within the same traffic class. Traffic classes may be differentiated based on an Access Control List (ACL), the packet DSCP [RFC5559], enabling use of the ECN field (i.e., any of ECT(0), ECT(1) or CE) [RFC3168] [RFC4774], a multi-field (MF) classifier that combines the values of a set of protocol fields (e.g., IP address, transport, ports), or an equivalent codepoint at a lower layer. This recommendation goes beyond what is defined in RFC 3168 by allowing that an implementation MAY use more than one instance of an AQM algorithm to handle both ECN-capable and non-ECN-capable packets. 🌈

4.5. AQM Algorithms SHOULD NOT Be Dependent on Specific Transport Protocol Behaviors 🦋

When deploying AQM, network devices need to support a range of Internet traffic and SHOULD NOT make implicit assumptions about the characteristics desired by the set of transports/applications the network supports. That is, AQM methods should be opaque to the choice of transport and application 🙈.

AQM algorithms are often evaluated by considering TCP [RFC793] with a limited number of applications. Although TCP is the predominant transport in the Internet today, this no longer represents a sufficient selection of traffic for verification. There is significant use of UDP [RFC768] in voice and video services, and some applications find utility in SCTP [RFC4960] and DCCP [RFC4340]. Hence, AQM algorithms should demonstrate operation with transports other than TCP and need to consider a variety of applications. When selecting AQM algorithms, the use of tunnel encapsulations that may carry traffic aggregates needs to be considered 🎁.

AQM algorithms SHOULD NOT target or derive implicit assumptions about the characteristics desired by specific transports/applications. Transports and applications need to respond to the congestion signals provided by AQM (i.e., dropping or ECN-marking) in a timely manner (within a few RTTs at the latest) ⏱️.

4.6. Interactions with Congestion Control Algorithms 🌸

Applications and transports need to react to received implicit or explicit signals that indicate the presence of congestion. This section identifies issues that can impact the design of transport protocols when using paths that use AQM 🔥.

Transport protocols and applications need timely signals of congestion. The time taken to detect and respond to congestion increases when network devices queue packets in buffers. It can be difficult to detect tail losses at a higher layer, and this may sometimes require transport timers or probe packets to detect and respond to such loss. Loss patterns may also impact timely detection, e.g., the time may be reduced when network devices do not drop long runs of packets from the same flow 😭.

A common objective of an elastic transport congestion control protocol is to allow an application to deliver the maximum rate of data without inducing excessive delays when packets are queued in buffers within the network. To achieve this, a transport should try to operate at rate below the inflection point of the load/delay curve (the bend of what is sometimes called a "hockey stick" curve) [Jain94]. When the congestion window allows the load to approach this bend, the end-to-end delay starts to rise -- a result of congestion, as packets probabilistically arrive at non-overlapping times. On the one hand, a transport that operates above this point can experience congestion loss and could also trigger operator activities, such as those discussed in [RFC6057]. On the other hand, a flow may achieve both near-maximum throughput and low latency when it operates close to this knee point, with minimal contribution to router congestion. Choice of an appropriate rate/congestion window can therefore significantly impact the loss and delay experienced by a flow and will impact other flows that share a common network queue 🎯.

Some applications may send data at a lower rate or keep fewer segments outstanding at any given time. Examples include multimedia codecs that stream at some natural rate (or set of rates) or an application that is naturally interactive (e.g., some web applications, interactive server-based gaming, transaction-based protocols). Such applications may have different objectives. They may not wish to maximize throughput, but may desire a lower loss rate or bounded delay 🎮.

The correct operation of an AQM-enabled network device MUST NOT rely upon specific transport responses to congestion signals 🛑.

4.7. The Need for Further Research 👑

The second recommendation of [RFC2309] called for further research into the interaction between network queues and host applications, and the means of signaling between them. This research has occurred, and we as a community have learned a lot. However, we are not done 📚.

We have learned that the problems of congestion, latency, and buffer-sizing have not gone away and are becoming more important to many users. A number of self-tuning AQM algorithms have been found that offer significant advantages for deployed networks. There is also renewed interest in deploying AQM and the potential of ECN 💜.

Traffic patterns can depend on the network deployment scenario, so Internet research needs to consider the implications of a diverse range of application interactions. This includes ensuring that combinations of mechanisms, as well as combinations of traffic patterns, do not interact and result in either significantly reduced flow throughput or significantly increased latency 🌈.

At the time of writing (in 2015), an obvious example of further research is the need to consider the many-to-one communication patterns found in data centers, known as incast [Ren12], (e.g., produced by Map/Reduce applications). Such analysis needs to study not only each application traffic type but also combinations of types of traffic 🏭.

Research also needs to consider the need to extend our taxonomy of transport sessions to include not only "mice" and "elephants", but "lemmings". Here, "lemmings" are flash crowds of "mice" that the network inadvertently tries to signal to as if they were "elephant" flows, resulting in head-of-line blocking in a data center deployment scenario 🐭🐘.

Examples of other required research include:

  • new AQM and scheduling algorithms
  • appropriate use of delay-based methods and the implications of AQM
  • suitable algorithms for marking ECN-capable packets that do not require operational configuration or tuning for common use
  • experience in the deployment of ECN alongside AQM
  • tools for enabling AQM (and ECN) deployment and measuring the performance
  • methods for mitigating the impact of non-conformant and malicious flows
  • implications on applications of using new network and transport methods

Hence, this document reiterates the call of RFC 2309: we need continuing research as applications develop 🔬✨

5. Security Considerations ✨

okay bestie, security is SO important 🔐 but ngl it's mostly a different topic from the performance stuff we've been talking about 💅

This recommendation says algorithms need to be independent of specific transport or application behaviors 🦋 So a network device doesn't need to see or access upper-layer protocol info to run an AQM algorithm. Being able to work in an application-agnostic way is a super privacy-enhancing feature 🫶

Lowkey concerning: a lot of deployed network devices use queueing methods where unresponsive traffic can hog the network capacity and lock out other flows 😭 That could be used as a denial-of-service attack 💀 Devices that use AQM or some kind of scheduling could reduce this threat 🛡️

BUT here's the tea 🍵 a denial-of-service attack that makes unresponsive traffic flows can look exactly like other legit traffic (like tunnels carrying bunches of short flows, or high-rate isochronous applications) 🙈 So new methods might still be vulnerable, and this document recommends that ongoing research looks into ways to mitigate these attacks 🔥 Periodt.

6. Privacy Considerations 🌸

This document, by itself, presents no new privacy issues 💜 Main character energy for the whole doc ✨

7. References 📚

7.1. Normative References 💖

7.2. Informative References 📚

okay bestie, these are the "go read this if you want the receipts" references 🤓💅 they're not required to implement anything, but they're where all the good stuff lives 🌸

  • [AQM-WG] IETF, "Active Queue Management and Packet Scheduling (aqm) WG", <http://datatracker.ietf.org/wg/aqm/charter/>.
  • [Bri15] Briscoe, B., Brunstrom, A., Petlund, A., Hayes, D., Ros, D., Tsang, I., Gjessing, S., Fairhurst, G., Griwodz, C., and M. Welzl, "Reducing Internet Latency: A Survey of Techniques and their Merit", IEEE Communications Surveys & Tutorials, 2015.
  • [Choi04] Choi, B., Moon, S., Zhang, Z., Papagiannaki, K., and C. Diot, "Analysis of Point-To-Point Packet Delay In an Operational Network", March 2004.
  • [CONEX] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) Concepts, Abstract Mechanism and Requirements", Work in Progress, draft-ietf-conex-abstract-mech-13, October 2014.
  • [Dem90] Demers, A., Keshav, S., and S. Shenker, "Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience", SIGCOMM Symposium proceedings on Communications architectures and protocols, 1990.
  • [ECN-Benefit] Fairhurst, G. and M. Welzl, "The Benefits of using Explicit Congestion Notification (ECN)", Work in Progress, draft-ietf-aqm-ecn-benefits-05, June 2015.
  • [Flo92] Floyd, S. and V. Jacobsen, "On Traffic Phase Effects in Packet-Switched Gateways", 1992, <http://www.icir.org/floyd/papers/phase.pdf>.
  • [Flo94] Floyd, S. and V. Jacobsen, "The Synchronization of Periodic Routing Messages", 1994, <http://ee.lbl.gov/papers/sync_94.pdf>.
  • [Floyd91] Floyd, S., "Connections with Multiple Congested Gateways in Packet-Switched Networks Part 1: One-way Traffic.", Computer Communications Review , October 1991.
  • [Floyd95] Floyd, S. and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, August 1995.
  • [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM Symposium proceedings on Communications architectures and protocols, August 1988.
  • [Jain94] Jain, R., Ramakrishnan, KK., and C. Dah-Ming, "Congestion avoidance scheme for computer networks", US Patent Office 5377327, December 1994.
  • [Lakshman96] Lakshman, TV., Neidhardt, A., and T. Ott, "The Drop From Front Strategy in TCP Over ATM and Its Interworking with Other Control Features", IEEE Infocomm, 1996.
  • [Leland94] Leland, W., Taqqu, M., Willinger, W., and D. Wilson, "On the Self-Similar Nature of Ethernet Traffic (Extended Version)", IEEE/ACM Transactions on Networking, February 1994.
  • [McK90] McKenney, PE. and G. Varghese, "Stochastic Fairness Queuing", 1990, <http://www2.rdrop.com/~paulmck/scalability/paper/sfq.2002.06.04.pdf>.
  • [Nic12] Nichols, K. and V. Jacobson, "Controlling Queue Delay", Communications of the ACM, Vol. 55, Issue 7, pp. 42-50, July 2012.
  • [Ren12] Ren, Y., Zhao, Y., and P. Liu, "A survey on TCP Incast in data center networks", International Journal of Communication Systems, Volumes 27, Issue 8, pages 116-117, 1990.
  • [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
  • [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
  • [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
  • [RFC896] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, DOI 10.17487/RFC0896, January 1984, <http://www.rfc-editor.org/info/rfc896>.
  • [RFC970] Nagle, J., "On Packet Switches With Infinite Storage", RFC 970, DOI 10.17487/RFC0970, December 1985, <http://www.rfc-editor.org/info/rfc970>.
  • [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
  • [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, DOI 10.17487/RFC1633, June 1994, <http://www.rfc-editor.org/info/rfc1633>.
  • [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>.
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
  • [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, <http://www.rfc-editor.org/info/rfc2474>.
  • [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
  • [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
  • [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.
  • [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
  • [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>.
  • [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, <http://www.rfc-editor.org/info/rfc5559>.
  • [RFC6057] Bastian, C., Klieber, T., Livingood, J., Mills, J., and R. Woundy, "Comcast's Protocol-Agnostic Congestion Management System", RFC 6057, DOI 10.17487/RFC6057, December 2010, <http://www.rfc-editor.org/info/rfc6057>.
  • [RFC6789] Briscoe, B., Ed., Woundy, R., Ed., and A. Cooper, Ed., "Congestion Exposure (ConEx) Concepts and Use Cases", RFC 6789, DOI 10.17487/RFC6789, December 2012, <http://www.rfc-editor.org/info/rfc6789>.
  • [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>.
  • [RFC7414] Duke, M., Braden, R., Eddy, W., Blanton, E., and A. Zimmermann, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 7414, DOI 10.17487/RFC7414, February 2015, <http://www.rfc-editor.org/info/rfc7414>.
  • [Shr96] Shreedhar, M. and G. Varghese, "Efficient Fair Queueing Using Deficit Round Robin", IEEE/ACM Transactions on Networking, Vol. 4, No. 3, July 1996.
  • [Sto97] Stoica, I. and H. Zhang, "A Hierarchical Fair Service Curve algorithm for Link sharing, real-time and priority services", ACM SIGCOMM, 1997.
  • [Sut99] Suter, B., "Buffer Management Schemes for Supporting TCP in Gigabit Routers with Per-flow Queueing", IEEE Journal on Selected Areas in Communications, Vol. 17, Issue 6, pp. 1159-1169, June 1999.
  • [Willinger95] Willinger, W., Taqqu, M., Sherman, R., Wilson, D., and V. Jacobson, "Self-Similarity Through High-Variability: Statistical Analysis of Ethernet LAN Traffic at the Source Level", SIGCOMM Symposium proceedings on Communications architectures and protocols, August 1995.
  • [Zha90] Zhang, L. and D. Clark, "Oscillating Behavior of Network Traffic: A Case Study Simulation", 1990, <http://groups.csail.mit.edu/ana/Publications/Zhang-DDC-Oscillating-Behavior-of-Network-Traffic-1990.pdf>.

Acknowledgements 🫶

the original draft of this best current practice doc was built on [RFC2309], an Informational RFC 🌷 it was written by the End-to-End Research Group, aka Bob Braden, Dave Clark, Jon Crowcroft, Bruce Davie, Steve Deering, Deborah Estrin, Sally Floyd, Van Jacobson, Greg Minshall, Craig Partridge, Larry Peterson, KK Ramakrishnan, Scott Shenker, John Wroclawski, and Lixia Zhang 👑 there are some big differences now, but a lot of the core arguments in this doc are still the same as in RFC 2309 💜

the TSV area meeting at IETF 86 agreed that an updated doc was needed 🎀 this doc got reviewed on the aqm@ietf.org list, and comments came in from Colin Perkins, Richard Scheffenegger, Dave Taht, John Leslie, David Collier-Brown, and a bunch of others 🌈

Gorry Fairhurst was partly supported by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700) ✨

Authors' Addresses 💌

Fred Baker (editor)
Cisco Systems
Santa Barbara, California  93117
United States

Email: fred@cisco.com


Godred Fairhurst (editor)
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen, Scotland  AB24 3UE
United Kingdom

Email: gorry@erg.abdn.ac.uk
URI:   http://www.erg.abdn.ac.uk
📦 where this page comes from