RFC 8511

TCP Alternative Backoff with ECN (ABE)

📅 published December 2018, from ietf

RFC 8511: TCP Alternative Backoff with ECN (ABE) 🦋

Okay bestie, here's the title block tea ☕ This is RFC 8511, and it's Experimental, so the vibe is "let's try it and see what happens" 🧪 It came out in December 2018 from the Internet Engineering Task Force (IETF), with ISSN 2070-1721. The authors are N. Khademi and M. Welzl (University of Oslo), G. Armitage (Netflix), and G. Fairhurst (University of Aberdeen). The title block doesn't list anything it obsoletes or updates, so no drama there 💅

Abstract 🌸

Okay so Active Queue Management (AQM) mechanisms are like the bouncers at a network bottleneck 💅 They let short bursts through but keep the line super short so packets don't wait around forever 🧚 The catch is that this can make TCP connections kinda sad, especially when there are only a few flows or the bandwidth-delay product (BDP) is big 😭

When a sender gets a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark, that's a hint that AQM is running at the bottleneck and the queue is probably short. The TCP sender can use that signal to cut the congestion window (cwnd) by a smaller amount than it would for an inferred packet loss during congestion avoidance. So this spec defines an experimental tweak to the TCP reaction from RFC 3168, which RFC 8311 allows 🎀

Status of This Memo 🎀

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧐

This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc8511 🔗

Copyright Notice 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 are provided without warranty as described in the Simplified BSD License.

Table of Contents 💜

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Choice of ABE Multiplier  . . . . . . . . . . . . . . . .   4
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Rationale for Using ECN to Vary the Degree of Backoff . .   6
     4.2.  An RTT-Based Response to Indicated Congestion . . . . . .   7
   5.  ABE Deployment Requirements . . . . . . . . . . . . . . . . .   7
   6.  ABE Experiment Goals  . . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

Explicit Congestion Notification (ECN) [RFC3168] lets an AQM mechanism say "hey, congestion is brewing" without necessarily dropping packets 🫶 That means the network can deliver some packets to an application that would otherwise have been dropped if the application or transport didn't support ECN. The packet loss reduction is the most obvious perk, but it's often pretty modest. Other perks of deploying ECN are covered in [RFC8087] 🍓

The original ECN rules were super cautious 🙈 They required the congestion control algorithms of ECN-Capable Transport (ECT) protocols to treat congestion indications signalled by ECN exactly the same as an inferred packet loss [RFC3168]. Research showed the benefit of cutting the network delays caused when loss-based TCP congestion control meets excessive buffering [BUFFERBLOAT]. That led to AQM mechanisms like Proportional Integral Controller Enhanced (PIE) [RFC8033] and Controlling Queue Delay (CoDel) [RFC8289], which stop bloated queues from forming in the unmanaged, oversized buffers common across the Internet [BUFFERBLOAT] 💅

The AQM mechanisms above aim to keep a sustained queue short while tolerating transient (short-term) packet bursts. However, the loss-based congestion control mechanisms in use today aren't always able to make good use of a bottleneck link when the queues are short 😭 For example, a TCP sender using Reno congestion control needs to be able to store at least an end-to-end bandwidth-delay product (BDP) worth of data at the bottleneck buffer if it wants to keep full path utilisation when loss-induced reductions of the congestion window (cwnd) happen [RFC5681]. That much buffering effectively doubles the amount of data that can be in flight and the maximum round-trip time (RTT) the TCP sender experiences. Iconic behaviour, but not in a good way 💀

Modern AQM mechanisms can use ECN to flag the early signs of impending queue buildup long before a tail-drop queue would be forced to start dropping packets. So it's totally appropriate for the transport congestion control algorithm to respond more calmly when it gets that early warning, after the remote endpoint receives an ECN CE-marked packet 🧘 Since modern AQM practice has changed, the strict rule that ECN CE signals be treated identically to inferred packet loss has been relaxed [RFC8311]. This document therefore defines a brand-new sender-side-only congestion control response called "ABE" (Alternative Backoff with ECN) 🦋 ABE improves TCP's average throughput when routers use AQM-controlled buffers that only allow for short queues. Main character energy, fr fr 👑

2. Definitions 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖

3. Specification 💖

This spec changes the congestion control algorithm of an ECN-Capable TCP transport protocol by changing how the TCP sender responds to feedback from the TCP receiver that indicates a CE-marked packet arrived. That means receipt of a packet with the ECN-Echo flag (defined in [RFC3168]) set, following the process defined in [RFC8311] 🔥

The TCP-sender response is currently specified in Section 6.1.2 of the ECN specification [RFC3168], and it's been slightly updated by Section 4.1 of [RFC8311] to read as:

The indication of congestion should be treated just as a congestion loss in non-ECN-Capable TCP. That is, the TCP source halves the congestion window "cwnd" and reduces the slow start threshold "ssthresh", unless otherwise specified by an Experimental RFC in the IETF document stream.

As permitted by RFC 8311, this document specifies a sender-side change to TCP where receipt of a packet with the ECN-Echo flag SHOULD trigger the TCP source to set the slow start threshold (ssthresh) to 0.8 times the FlightSize, with a lower bound of 2 * SMSS applied to the result (where SMSS stands for Sender Maximum Segment Size)). This is the ABE glow-up ✨ As in [RFC5681], the TCP sender also reduces the cwnd value to no more than the new ssthresh value. Section 6.1.2 of RFC 3168 gives guidance on setting a cwnd less than 2 * SMSS 🧁

3.1. Choice of ABE Multiplier ✨

Okay so ABE's whole thing is splitting up how a TCP sender reacts to packet loss it had to infer versus the ECN-signalled congestion notice during congestion avoidance 💅. To pull that off, ABE uses a different scaling factor for Equation 4 in Section 3.1 of [RFC5681]. The description uses beta_{loss} and beta_{ecn} to mean the multiplicative decrease factors for inferred packet loss and for when a receiver says "ECN-signalled congestion" 🌸. For non-ECN-enabled TCP connections, only beta_{loss} applies.

In other words, in response to inferred packet loss:

ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS)

And in response to an indication of ECN-signalled congestion:

ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS)

and

cwnd = ssthresh

(If ssthresh == 2 * SMSS, Section 6.1.2 of RFC 3168 provides guidance on setting a cwnd lower than 2 * SMSS.) 🧚

Where FlightSize is the amount of outstanding data in the network, upper-bounded by the smaller of the sender's cwnd and the receiver's advertised window (rwnd) [RFC5681]. The higher the values of beta_{loss} and beta_{ecn}, the less aggressive the response of any individual backoff event 💜.

Picking beta_{loss} and beta_{ecn} is a total balancing act between path utilisation and draining the bottleneck queue ⚖️✨. Super aggressive backoff (smaller beta_*) risks underutilising the path, while gentler backoff (larger beta_*) can mean the bottleneck queue drains more slowly 🙈.

The Internet has already been running with at least two different beta_{loss} values for years 😭: the standard value is 0.5 [RFC5681], and the Linux implementation of CUBIC [RFC8312] has used a multiplier of 0.7 since kernel version 2.6.25, released in 2008. ABE does not change the value of beta_{loss} used by current TCP implementations 🍓.

The recommendation in this document specifies a value of beta_{ecn}=0.8. This recommended beta_{ecn} value is only applicable for the standard TCP congestion control [RFC5681]. Choosing beta_{ecn} lets you tune how a TCP connection responds to shallow AQM-marking thresholds 🎀. beta_{loss} describes how a congestion control algorithm responds to packet loss, i.e., buffer exhaustion (of unknown depth). Different beta_{loss} values have been suggested for TCP congestion control algorithms, so beta_{ecn} is likely to be an algorithm-specific parameter rather than a constant multiple of the algorithm's existing beta_{loss} 👑.

A range of tests (Section IV of [ABE2017]) with NewReno and CUBIC over CoDel and PIE in lightly multiplexed scenarios explored this parameter choice 🦋. The results show that CUBIC connections benefit from beta_{ecn} of 0.85 (cf. beta_{loss} = 0.7), and NewReno connections see improvements with beta_{ecn} in the range 0.7 to 0.85 (cf. beta_{loss} = 0.5) 🔥.

4. Discussion 💬

Much of the technical background for ABE lives in [ABE2017], which uses a mix of experiments, theory, and simulations with NewReno [RFC5681] and CUBIC [RFC8312] to evaluate performance 🌈. ABE was shown to deliver significant performance gains in lightly multiplexed scenarios (few concurrent flows), without losing the delay-reduction benefits of deploying CoDel or PIE 🤩. The performance improvement happens when ABE reacts to ECN-Echo in congestion avoidance (when ssthresh > cwnd) by multiplying cwnd and ssthresh with a value in the range [0.7,0.85]. Applying ABE when cwnd is smaller than or equal to ssthresh is not currently recommended, but that scenario may be worth more attention, experimentation, and specification 🧐.

4.1. Rationale for Using ECN to Vary the Degree of Backoff 🦋

AQM mechanisms like CoDel [RFC8289] and PIE [RFC8033] set a delay target in routers and use congestion notifications to keep the queuing delays packets experience in check, rather than reacting to impending or actual bottleneck buffer exhaustion 🫶. With current default delay targets, CoDel and PIE both effectively emulate a bottleneck with a short queue (Section II of [ABE2017]) while still letting short traffic bursts into the queue 🌸. This gives acceptable performance for TCP connections over a path with a low BDP, or in highly multiplexed scenarios (many concurrent transport flows). However, in a lightly multiplexed case over a path with a large BDP, conventional TCP backoff leads to gaps in packet transmission and underutilisation of the path 😭.

Instead of discarding packets, an AQM mechanism is allowed to mark ECN-Capable packets with an ECN CE mark 💖. Getting CE-mark feedback not only tells you there's congestion on the network path, it also tells you an AQM mechanism exists at the bottleneck along the path. So the CE mark likely came from a bottleneck with a controlled short queue 🧚. Reacting differently to ECN-signalled congestion than to inferred packet loss can therefore give you a reduced backoff when queues are short ✨. Using ECN can also be advantageous for several other reasons [RFC8087].

The idea of reacting differently to inferred packet loss and to detected ECN-signalled congestion predates this specification 🕰️. For example, earlier research proposed using ECN CE-marked feedback to modify TCP congestion control behaviour via a larger multiplicative decrease factor paired with a smaller additive increase factor [ICC2002]. The goal of that earlier work was to operate across AQM bottlenecks (using Random Early Detection (RED)) that weren't necessarily configured to emulate a short queue. (Current usage of RED as an Internet AQM method is limited [RFC7567].) 🙃

4.2. An RTT-Based Response to Indicated Congestion ⏱️

This specification applies to the use of ECN feedback as defined in [RFC3168], which specifies a response to indicated congestion that happens no more frequently than once per path round-trip time 🎀. Since ABE responds to indicated congestion once per RTT, it does not respond to any further loss within the same RTT, because an ABE sender has already reduced the congestion window. If congestion persists after such a reduction, ABE keeps reducing the congestion window in each consecutive RTT 💅. This consecutive reduction can protect the network against long-standing unfairness when AQM algorithms don't keep a small average queue length 🛡️. The mechanism does not rely on Accurate ECN [ACC-ECN-FEEDBACK].

On the flip side, transport protocol mechanisms can also be designed to use more frequent and detailed ECN feedback (e.g., Accurate ECN [ACC-ECN-FEEDBACK]), which then permits a congestion control response that adjusts the sending rate more often 🚀. Data Center TCP (DCTCP) [RFC8257] is an example of this approach 🌈.

5. ABE Deployment Requirements 🧰

This update is a sender-side-only change 🫶. Like other changes to congestion control algorithms, it doesn't need any change to the TCP receiver or to network devices. It doesn't require any ABE-specific changes in routers, or the use of Accurate ECN feedback [ACC-ECN-FEEDBACK] by a receiver 💖.

If only some senders deploy the method and others don't, the senders using it can gain some advantage, possibly at the expense of other flows that don't use this updated method 😬. Because this advantage applies only to ECN-marked packets and not to packet-loss indications, an ECN-Capable bottleneck will still fall back to dropping packets if a TCP sender using ABE is too aggressive. The result is no different from what happens if the TCP sender were using traditional loss-based congestion control 🙌.

When used with bottlenecks that don't support ECN marking, the specification does not modify the transport protocol 🍓.

6. ABE Experiment Goals 🧪

[RFC3168] states that the congestion control response following an indication of ECN-signalled congestion is the same as the response to a dropped packet. [RFC8311] updates this specification to allow systems to behave differently when they experience ECN-signalled congestion rather than packet loss 🦋. The present specification defines such an experiment and is an Experimental RFC. We expect to propose it as a Standards-Track document in the future 🔮.

The purpose of this Internet experiment is to collect experience with deploying ABE and to confirm acceptable safety in deployed networks that use this update to TCP congestion control 🔬. To evaluate ABE, the experiment requires support in AQM routers for ECN-marking packets that carry the ECN-Capable Transport codepoint ECT(0) [RFC3168] 🧁.

The result of this Internet experiment ought to include an investigation of the implications of experiencing an ECN-CE mark followed by loss within the same RTT 👀. At the end of the experiment, this will be reported to the TCPM Working Group or the IESG 📝.

ABE is implemented as a patch for Linux and FreeBSD 💻. This is meant for research and experimentation and is available for download at <https://heim.ifi.uio.no/michawe/research/abe/>. This code was used to produce the test results reported in [ABE2017]. The FreeBSD code was committed to the mainline kernel on March 19, 2018 [ABE-REVISION] 🎉.

7. IANA Considerations 📋

This document has no IANA actions 🌸.

8. Security Considerations 🚨

The described method is a sender-side-only transport change, and it does not change the protocol messages exchanged. Therefore, the security considerations for ECN [RFC3168] still apply 🔐.

⚠️ Heads up, bestie: this is a change to TCP congestion control with ECN, and it will typically change the capacity achieved when flows share a network bottleneck. This could mean some flows get more than their fair share of capacity. Similar unfairness in how capacity is shared is also shown by other congestion control mechanisms that have been in use on the Internet for many years (e.g., CUBIC [RFC8312]). Unfairness may also come from other factors, including the round-trip time a flow experiences. ABE applies only when ECN-marked packets are received, not when packets are lost. Therefore, use of ABE cannot lead to congestion collapse 💜.

9. References 📚

9.1. Normative References

okay bestie, these are the must-reads that the spec leans on, so no skipping 🫶📚

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
           of Explicit Congestion Notification (ECN) to IP",
           RFC 3168, DOI 10.17487/RFC3168, September 2001,
           <https://www.rfc-editor.org/info/rfc3168>.

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

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

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8257]  Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
           and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
           Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
           October 2017, <https://www.rfc-editor.org/info/rfc8257>.

[RFC8311]  Black, D., "Relaxing Restrictions on Explicit Congestion
           Notification (ECN) Experimentation", RFC 8311,
           DOI 10.17487/RFC8311, January 2018,
           <https://www.rfc-editor.org/info/rfc8311>.

9.2. Informative References

these ones are the background reading 📖💅 not strictly required, but honestly so good for going deeper

[ABE-REVISION]
           Stewart, L., "ABE patch review in FreeBSD",
           Revision 331214, March 2018, <https://svnweb.freebsd.org/
           base?view=revision&revision=331214>.

[ABE2017]  Khademi, N., Armitage, G., Welzl, M., Zander, S.,
           Fairhurst, G., and D. Ros, "Alternative backoff: Achieving
           low latency and high throughput with ECN and AQM", IFIP
           Networking Conference and Workshops Stockholm, Sweden,
           DOI 10.23919/IFIPNetworking.2017.8264863, June 2017.

[ACC-ECN-FEEDBACK]
           Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
           Accurate ECN Feedback in TCP", Work in Progress,
           draft-ietf-tcpm-accurate-ecn-07, July 2018.

[BUFFERBLOAT]
           Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in
           the Internet", ACM Queue, Volume 9, Issue 11,
           DOI 10.1145/2063166.2071893, November 2011,
           <https://queue.acm.org/detail.cfm?id=2071893>.

[ICC2002]  Kwon, M. and S. Fahmy, "TCP increase/decrease behavior
           with explicit congestion notification (ECN)", 2002 IEEE
           International Conference on Communications Conference
           Proceedings, ICC 2002, Cat. No.02CH37333,
           DOI 10.1109/ICC.2002.997262, May 2002,
           <http://dx.doi.org/10.1109/ICC.2002.997262>.

[RFC8033]  Pan, R., Natarajan, P., Baker, F., and G. White,
           "Proportional Integral Controller Enhanced (PIE): A
           Lightweight Control Scheme to Address the Bufferbloat
           Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
           <https://www.rfc-editor.org/info/rfc8033>.

[RFC8087]  Fairhurst, G. and M. Welzl, "The Benefits of Using
           Explicit Congestion Notification (ECN)", RFC 8087,
           DOI 10.17487/RFC8087, March 2017,
           <https://www.rfc-editor.org/info/rfc8087>.

[RFC8289]  Nichols, K., Jacobson, V., McGregor, A., Ed., and J.
           Iyengar, Ed., "Controlled Delay Active Queue Management",
           RFC 8289, DOI 10.17487/RFC8289, January 2018,
           <https://www.rfc-editor.org/info/rfc8289>.

[RFC8312]  Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
           R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
           RFC 8312, DOI 10.17487/RFC8312, February 2018,
           <https://www.rfc-editor.org/info/rfc8312>.

Acknowledgements ✨

okay the thank-you section is my fave, the people behind this deserve all the flowers 🌸🫶

Naeem Khademi, Michael Welzl, and Godred Fairhurst were partly funded by the European Community under its Seventh Framework Programme, through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views in the document are only the authors' own. 💜

Grenville Armitage did most of his work on this document while he was employed by Swinburne University of Technology in Melbourne, Australia. 🦋

The authors also want to thank Stuart Cheshire for loads of suggestions while they were revising the document. Huge thanks as well to Chamil Kulatunga, David Ros, Stein Gjessing, and Sebastian Zander, who helped with [ABE2017]. 🎀

Thanks too, in alphabetical order, to David Black, Roland Bless, Bob Briscoe, Markku Kojo, John Leslie, Lawrence Stewart, and the TCPM Working Group for giving really valuable feedback on the document. 🙌

Last but not least, the authors thank everyone who gave feedback on the congestion control behaviour specified here, which came in from the IRTF Internet Congestion Control Research Group (ICCRG). You all are iconic 👑🌈

Authors' Addresses 🧚

Naeem Khademi
University of Oslo
PO Box 1080 Blindern
Oslo  N-0316
Norway

Email: naeemk@ifi.uio.no


Michael Welzl
University of Oslo
PO Box 1080 Blindern
Oslo  N-0316
Norway

Email: michawe@ifi.uio.no


Grenville Armitage
Netflix Inc.

Email: garmitage@netflix.com


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

Email: gorry@erg.abdn.ac.uk

📦 where this page comes from

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