RFC 8312

CUBIC for Fast Long-Distance Networks

📅 published February 2018, from ietf

CUBIC for Fast Long-Distance Networks 🎀

Okay bestie, this is RFC 8312 🦋, and the vibe is pure internet infrastructure glow-up. It's an Informational document from the IETF (Internet Engineering Task Force), dated February 2018, and its ISSN is 2070-1721. The authors are I. Rhee (NCSU), L. Xu (UNL), S. Ha (Colorado), A. Zimmermann, L. Eggert, and R. Scheffenegger (NetApp). The title block doesn't list anything this document obsoletes or updates. 💅

Abstract ✨

Okay so CUBIC is an extension to the current TCP standards, and it's lowkey simple: the only thing it changes is the congestion control algorithm on the sender side 🧚. The big idea is that it swaps the linear window increase function of the current TCP standards for a cubic function, so things get better at scalability and stability when you're on fast, long-distance networks 🚀. CUBIC and its predecessor algorithm were adopted as defaults by Linux and have been used for many years 👑. This document gives a specification of CUBIC so that third-party implementations can exist, and it invites the community to share feedback from experimenting with how CUBIC performs 🫶.

Status of This Memo 📜

This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🌸.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🎉. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full story 🤓.

Info about the current status of this document, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8312 🔗.

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

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

Table of Contents 🌸

1. Introduction ....................................................3
2. Conventions .....................................................3
3. Design Principles of CUBIC ......................................4
4. CUBIC Congestion Control ........................................6
   4.1. Window Increase Function ...................................6
   4.2. TCP-Friendly Region ........................................7
   4.3. Concave Region .............................................8
   4.4. Convex Region ..............................................8
   4.5. Multiplicative Decrease ....................................8
   4.6. Fast Convergence ...........................................9
   4.7. Timeout ...................................................10
   4.8. Slow Start ................................................10
5. Discussion .....................................................10
   5.1. Fairness to Standard TCP ..................................11
   5.2. Using Spare Capacity ......................................13
   5.3. Difficult Environments ....................................13
   5.4. Investigating a Range of Environments .....................13
   5.5. Protection against Congestion Collapse ....................14
   5.6. Fairness within the Alternative Congestion Control
        Algorithm .................................................14
   5.7. Performance with Misbehaving Nodes and Outside Attackers ..14
   5.8. Behavior for Application-Limited Flows ....................14
   5.9. Responses to Sudden or Transient Events ...................14
   5.10. Incremental Deployment ...................................14
6. Security Considerations ........................................15
7. IANA Considerations ............................................15
8. References .....................................................15
   8.1. Normative References ......................................15
   8.2. Informative References ....................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................18

1. Introduction ✨

Okay, so TCP's low utilization problem in fast long-distance networks is well documented in [K03] and [RFC3649] 😭. The root cause is that after a congestion event, the congestion window grows slowly in a network with a large bandwidth-delay product (BDP) 🐢. [HKLRX06] points out that this shows up even when congestion windows are several hundred packets big 👀. This is equally relevant to every Reno-style TCP standard and its variants, like TCP-RENO [RFC5681], TCP-NewReno [RFC6582] [RFC6675], SCTP [RFC4960], and TFRC [RFC5348]. They all use the same linear increase function for window growth, so below we group them together as "Standard TCP" 💜.

CUBIC, first proposed in [HRX08], is a tweak to the congestion control algorithm of Standard TCP that fixes this exact problem 🔧. This document describes the most recent specification of CUBIC. Basically, CUBIC uses a cubic function where Standard TCP uses a linear window increase function, which helps it scale and stay stable on fast, long-distance networks 🚀.

Binary Increase Congestion Control (BIC-TCP) [XHR04] was the predecessor of CUBIC. Linux picked it as its default TCP congestion control algorithm in 2005, and the wider Internet used it for several years 🍓. CUBIC has a similar window increase function to BIC-TCP, but it's designed to be less aggressive and fairer to Standard TCP in bandwidth usage. It still keeps the good stuff from BIC-TCP, like stability, window scalability, and RTT fairness 💅. CUBIC has already replaced BIC-TCP as Linux's default TCP congestion control algorithm and has been deployed globally through Linux 🌍. After extensive testing across a bunch of Internet scenarios, the authors believe CUBIC is safe for testing and deployment in the global Internet 🫶.

In the sections that follow, we first explain CUBIC's design principles, then give the exact specification, and finally talk through its safety features using the guidelines in [RFC5033] 🧠.

2. Conventions 💅

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. Design Principles of CUBIC ✨

okay so before we get into the math, CUBIC has four design principles 🎀 here they are in one bite-sized list:

  • Principle 1: For better network utilization and stability, CUBIC uses both the concave and convex profiles of a cubic function to increase the congestion window size, instead of using just a convex function.
  • Principle 2: To be TCP-friendly, CUBIC is designed to behave like Standard TCP in networks with short RTTs and small bandwidth where Standard TCP performs well.
  • Principle 3: For RTT-fairness, CUBIC is designed to achieve linear bandwidth sharing among flows with different RTTs.
  • Principle 4: CUBIC appropriately sets its multiplicative window decrease factor in order to balance between the scalability and convergence speed.

Now let's go through each one, because the details are where it gets iconic 💅

Principle 1: For better network utilization and stability, CUBIC [HRX08] uses a cubic window increase function based on the time that has elapsed since the last congestion event 🦋 Most other congestion control algorithms that are alternatives to Standard TCP grow the window with convex functions only, but CUBIC uses both the concave and convex profiles of a cubic function for window growth, which is the whole main character moment. After a window reduction caused by a congestion event that gets detected through duplicate ACKs or Explicit Congestion Notification-Echo (ECN-Echo) ACKs [RFC3168], CUBIC records the congestion window size where the congestion event happened as W_max and then does a multiplicative decrease of the congestion window. Once it enters congestion avoidance, it starts growing the window along the concave profile of the cubic function. The cubic function is set up to have its plateau at W_max, so the concave increase keeps going until the window reaches W_max. After that, the function flips into a convex profile and the convex increase begins 🌈 This concave-then-convex style of adjusting the window makes the algorithm more stable while still keeping network utilization high [CEHRX07]. The reason is that the window stays pretty much flat, forming a plateau around W_max, which is where network utilization is considered highest. In steady state, most of CUBIC's window size samples sit close to W_max, which keeps utilization high and things stable 🫶 Meanwhile, the algorithms that only use convex functions to grow the window have their biggest increments right around W_max. That means they create a lot of packet bursts around the saturation point of the network, which can cause frequent global loss synchronizations 😭

Principle 2: CUBIC promotes per-flow fairness to Standard TCP 🍓 Standard TCP does well when the RTT is short and the bandwidth is small (or the BDP is small). The only real scalability problem is in networks with long RTTs and large bandwidth (or large BDP). An alternative congestion control algorithm that wants to be friendly to Standard TCP on a per-flow basis has to grow its congestion window less aggressively in small BDP networks than in large BDP networks. CUBIC's aggressiveness mostly depends on the maximum window size before a window reduction, and that maximum is smaller in small BDP networks than in large BDP networks. So CUBIC grows its congestion window less aggressively in small BDP networks than in large BDP networks. There's also a backup plan: when the cubic function would make CUBIC grow its window slower than Standard TCP, CUBIC just follows the window size of Standard TCP. This makes sure CUBIC gets at least the same throughput as Standard TCP in small BDP networks 🧚 We call this region, where CUBIC acts like Standard TCP, the "TCP-friendly region" 🌸

Principle 3: Two CUBIC flows with different RTTs have a throughput ratio that is linearly proportional to the inverse of their RTT ratio 💜 Here, the throughput of a flow is roughly its congestion window size divided by its RTT. Specifically, CUBIC keeps a window increase rate that doesn't depend on RTT outside of the TCP-friendly region. So flows with different RTTs end up with similar congestion window sizes at steady state when they're operating outside the TCP-friendly region. This linear throughput ratio looks a lot like what Standard TCP does in high statistical multiplexing environments, where packet losses are independent of individual flow rates. But under low statistical multiplexing environments, the throughput ratio of Standard TCP flows with different RTTs is quadratically proportional to the inverse of their RTT ratio [XHR04]. CUBIC always keeps the linear throughput ratio no matter what the level of statistical multiplexing is, which is an improvement over Standard TCP 👑 Nobody has reached a consensus on the exact throughput ratios for flows with different RTTs. Still, we believe that on the wired Internet, a linear throughput ratio makes more sense than equal throughputs (meaning the same throughput for flows with different RTTs) or a higher-order throughput ratio (like the quadratic throughput ratio Standard TCP gets under low statistical multiplexing environments) 🤍

Principle 4: To balance scalability and convergence speed, CUBIC sets the multiplicative window decrease factor to 0.7, while Standard TCP uses 0.5 🎀 This boosts CUBIC's scalability, but there's a side effect: convergence is slower, especially under low statistical multiplexing environments. This choice follows an observation made by the author of HighSpeed TCP (HSTCP) [RFC3649] along with other researchers (for example, [GV02]). The observation is that the current Internet is becoming more asynchronous, with fewer loss synchronizations under high statistical multiplexing. In that environment, even strict Multiplicative-Increase Multiplicative-Decrease (MIMD) can converge 🌈 CUBIC flows with the same RTT always converge to the same throughput regardless of statistical multiplexing, which gives intra-algorithm fairness ✨ We also found that when there's enough statistical multiplexing, CUBIC flows converge at a reasonable speed 🦋

4. CUBIC Congestion Control ✨

The unit for all window sizes in this document is segments of the maximum segment size (MSS), and the unit for all times is seconds ⏱️ cwnd is the congestion window size of a flow, and ssthresh is the slow-start threshold.

4.1. Window Increase Function

CUBIC keeps the acknowledgment (ACK) clocking of Standard TCP by only increasing the congestion window when an ACK comes in 🫶 It doesn't change the fast recovery and retransmit behavior of TCP, such as TCP-NewReno [RFC6582] [RFC6675]. During congestion avoidance, after a congestion event where a packet loss is detected through duplicate ACKs or where network congestion is detected through ACKs with ECN-Echo flags [RFC3168], CUBIC swaps out Standard TCP's window increase function for its own. Let W_max be the window size right before the window got reduced in the last congestion event 💅

CUBIC uses the following window increase function:

W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1)

In that formula, C is a constant that sets how aggressive the window increase is in high BDP networks, and t is the elapsed time since the start of the current congestion avoidance. K is the time the function takes to grow the current window back up to W_max, assuming no further congestion events happen. It's calculated like this:

K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2)

Here, beta_cubic is the CUBIC multiplicative decrease factor. When a congestion event happens, CUBIC cuts its cwnd down to W_cubic(0)=W_max*beta_cubic. We talk about how beta_cubic gets set in Section 4.5, and how C gets set in Section 5 📖

When an ACK comes in during congestion avoidance, CUBIC uses Eq. 1 to work out the window increase rate for the next RTT period. It then sets W_cubic(t+RTT) as the candidate target value for the congestion window. The RTT here is the weighted average RTT that Standard TCP calculates 🧁

Depending on the current congestion window size cwnd, CUBIC runs in one of three modes:

  1. The TCP-friendly region, which makes sure CUBIC gets at least the same throughput as Standard TCP.
  2. The concave region, which applies if CUBIC is not in the TCP-friendly region and cwnd is less than W_max.
  3. The convex region, which applies if CUBIC is not in the TCP-friendly region and cwnd is greater than W_max.

We'll go through the exact actions CUBIC takes in each region right below 👇

4.2. TCP-Friendly Region

Standard TCP does well in certain kinds of networks, for example, ones with a short RTT and small bandwidth (or small BDP) 🌸 In those networks, we use the TCP-friendly region to make sure CUBIC gets at least the same throughput as Standard TCP.

The TCP-friendly region is designed based on the analysis in [FHP00] 🦋 That analysis studies the performance of an Additive Increase and Multiplicative Decrease (AIMD) algorithm with an additive factor of alpha_aimd (segments per RTT) and a multiplicative factor of beta_aimd. It's written as AIMD(alpha_aimd, beta_aimd). The average congestion window size of AIMD(alpha_aimd, beta_aimd) can be calculated with Eq. 3. The analysis shows that AIMD(alpha_aimd, beta_aimd) with alpha_aimd=3*(1-beta_aimd)/(1+beta_aimd) gets the same average window size as Standard TCP, which uses AIMD(1, 0.5) 🧚

AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /
               (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3)

Based on that analysis, CUBIC uses Eq. 4 to estimate the window size W_est of AIMD(alpha_aimd, beta_aimd), with alpha_aimd=3*(1-beta_cubic)/(1+beta_cubic) and beta_aimd=beta_cubic. That combo gets the same average window size as Standard TCP 💜 When an ACK comes in during congestion avoidance (cwnd could be greater or less than W_max), CUBIC checks whether W_cubic(t) is less than W_est(t). If it is, CUBIC is in the TCP-friendly region, and cwnd SHOULD be set to W_est(t) every time an ACK is received 🍓

W_est(t) = W_max*beta_cubic +
            [3*(1-beta_cubic)/(1+beta_cubic)] * (t/RTT) (Eq. 4)

4.3. Concave Region

When an ACK comes in during congestion avoidance, if CUBIC is not in the TCP-friendly region and cwnd is less than W_max, then CUBIC is in the concave region 🌈 In this region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where W_cubic(t+RTT) is calculated using Eq. 1 ✨

4.4. Convex Region

When an ACK comes in during congestion avoidance, if CUBIC is not in the TCP-friendly region and cwnd is larger than or equal to W_max, then CUBIC is in the convex region 👑 The convex region means the network conditions might have shifted since the last congestion event, which could mean there's more available bandwidth after some flows have left. The Internet is highly asynchronous, so some amount of perturbation is always possible without causing a major change in available bandwidth 🌸 In this region, CUBIC is being super careful and grows its window size very slowly. The convex profile keeps the window growing slowly at the start and then gradually picks up its rate of increase 🦋 We also call this region the "maximum probing phase", since CUBIC is searching for a new W_max 🔍 In this region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, where W_cubic(t+RTT) is calculated using Eq. 1 💖

4.5. Multiplicative Decrease ✨

okay so bestie, when CUBIC spots a packet loss through duplicate ACKs, or a congestion signal through ECN-Echo ACKs, it does a little strategic cutback 💅 It saves W_max, then updates cwnd and ssthresh like this. The beta_cubic parameter SHOULD be set to 0.7 🎀

W_max = cwnd;                 // save window size before reduction
ssthresh = cwnd * beta_cubic; // new slow-start threshold
ssthresh = max(ssthresh, 2);  // threshold is at least 2 MSS
cwnd = cwnd * beta_cubic;     // window reduction

ngl, setting beta_cubic above 0.5 has a side effect: convergence gets slower 🐢 The authors think a more adaptive beta_cubic could converge faster, but it would make CUBIC way harder to analyze, so that adaptive tweak is saved as a to-do for the next version of CUBIC 📝

4.6. Fast Convergence 🦋

okay this one is giving main character energy 👑 CUBIC has a heuristic to help flows converge faster. When a new flow joins, the existing flows need to give up some bandwidth so the newcomer has room to grow, especially if those existing flows are hogging the whole network. To speed up that release, the mechanism called "fast convergence" SHOULD be implemented.

With fast convergence, at a congestion event, before the window gets reduced, a flow remembers the last W_max value from before it updates W_max for the current event. We'll call that last value W_last_max.

if (W_max < W_last_max){ // should we make room for others
    W_last_max = W_max;             // remember the last W_max
    W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max
} else {
    W_last_max = W_max              // remember the last W_max
}

So if the current W_max is less than W_last_max, the flow's saturation point is shrinking because the available bandwidth changed 📉 That's the signal to let go a bit more, so the flow reduces W_max even further. This pushes the plateau earlier and gives it a longer runway to grow its window, which means the new flow has more time to catch up 🫶

Fast convergence is built for networks with multiple CUBIC flows. If there's only one CUBIC flow and no other traffic, the fast convergence SHOULD be disabled 🙅‍♀️

4.7. Timeout 💀

when a timeout happens, CUBIC follows Standard TCP to reduce cwnd [RFC5681], but it sets ssthresh using beta_cubic (same as in Section 4.5), which is not what Standard TCP does [RFC5681] 🙈

During the first congestion avoidance after a timeout, CUBIC grows its congestion window using Eq. 1. Here t is the time elapsed since the start of the current congestion avoidance, K is set to 0, and W_max is set to the congestion window at the start of that congestion avoidance.

4.8. Slow Start 🚀

CUBIC MUST employ a slow-start algorithm whenever cwnd is no more than ssthresh 🫡 Among slow-start options, CUBIC MAY use the standard TCP slow start [RFC5681] in general networks, or limited slow start [RFC3742] or hybrid slow start [HR08] for fast and long-distance networks ✈️

If CUBIC runs hybrid slow start [HR08], it might exit the first slow start without any packet loss, which means W_max is undefined 🤷‍♀️ In that special case, CUBIC switches to congestion avoidance and grows its window using Eq. 1. Here t is the time elapsed since the start of the current congestion avoidance, K is set to 0, and W_max is set to the congestion window at the start of that congestion avoidance.

5. Discussion 🧠

in this section we talk about the safety features of CUBIC, following the guidelines in [RFC5033] 🔒

With a deterministic loss model, where exactly 1/p packets go between each pair of successive losses, CUBIC always runs the concave window profile. That makes the performance analysis SO much easier 🥰 The average window size of CUBIC comes out to:

    AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 *
                    (RTT^0.75) / (p^0.75) (Eq. 5)

With beta_cubic set to 0.7, that formula simplifies to:

    AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6)

Next up, we'll work out the value of C using Eq. 6 ✨

5.1. Fairness to Standard TCP 🤝

When Standard TCP can already make reasonable use of the available bandwidth, CUBIC doesn't significantly change that situation 💖

Standard TCP does well in two kinds of networks:

  1. networks with a small bandwidth-delay product (BDP)
  2. networks with short RTTs, but not necessarily a small BDP

CUBIC is designed to act very similarly to Standard TCP in those two kinds of networks 🎀 The tables below show the average window sizes for Standard TCP, HSTCP, and CUBIC. The Standard TCP and HSTCP numbers come from [RFC3649]. The CUBIC number is calculated with Eq. 6 and the CUBIC TCP-friendly region, for three different values of C.

+--------+----------+-----------+------------+-----------+----------+
|   Loss |  Average |   Average |      CUBIC |     CUBIC |    CUBIC |
| Rate P |    TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |    (C=4) |
+--------+----------+-----------+------------+-----------+----------+
|  10^-2 |       12 |        12 |         12 |        12 |       12 |
|  10^-3 |       38 |        38 |         38 |        38 |       59 |
|  10^-4 |      120 |       263 |        120 |       187 |      333 |
|  10^-5 |      379 |      1795 |        593 |      1054 |     1874 |
|  10^-6 |     1200 |     12279 |       3332 |      5926 |    10538 |
|  10^-7 |     3795 |     83981 |      18740 |     33325 |    59261 |
|  10^-8 |    12000 |    574356 |     105383 |    187400 |   333250 |
+--------+----------+-----------+------------+-----------+----------+

Table 1

Table 1 shows the response functions of Standard TCP, HSTCP, and CUBIC in networks with RTT = 0.1 seconds. The average window size is in MSS-sized segments 📏

+--------+-----------+-----------+------------+-----------+---------+
|   Loss |   Average |   Average |      CUBIC |     CUBIC |   CUBIC |
| Rate P |     TCP W |   HSTCP W |   (C=0.04) |   (C=0.4) |   (C=4) |
+--------+-----------+-----------+------------+-----------+---------+
|  10^-2 |        12 |        12 |         12 |        12 |      12 |
|  10^-3 |        38 |        38 |         38 |        38 |      38 |
|  10^-4 |       120 |       263 |        120 |       120 |     120 |
|  10^-5 |       379 |      1795 |        379 |       379 |     379 |
|  10^-6 |      1200 |     12279 |       1200 |      1200 |    1874 |
|  10^-7 |      3795 |     83981 |       3795 |      5926 |   10538 |
|  10^-8 |     12000 |    574356 |      18740 |     33325 |   59261 |
+--------+-----------+-----------+------------+-----------+---------+

Table 2

Table 2 shows the response functions of Standard TCP, HSTCP, and CUBIC in networks with RTT = 0.01 seconds. The average window size is in MSS-sized segments 🌸

Both tables show that CUBIC with any of these three C values is friendlier to TCP than HSTCP is, especially in short-RTT networks where TCP already performs pretty well 🫶 For example, in a network with RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 packets. If the packet size is 1500 bytes, TCP reaches an average rate of 1.44 Gbps. In that case, CUBIC with C=0.04 or C=0.4 hits exactly the same rate as Standard TCP, while HSTCP is about ten times more aggressive than Standard TCP 😭

C controls how aggressive CUBIC is when it competes with other congestion control algorithms for bandwidth 🔥 The lower C is, the friendlier CUBIC is to Standard TCP. But we do not recommend setting C to a very low value like 0.04, because CUBIC with a low C can't use bandwidth efficiently in networks with long RTTs and high bandwidth 🙅‍♀️ Based on these observations and the experiments, C=0.4 hits a good balance between TCP-friendliness and aggressiveness of window increase, so C SHOULD be set to 0.4 💜 With C set to 0.4, Eq. 6 reduces to:

    AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7)

Eq. 7 gets used in the next subsection to show how scalable CUBIC is 📈

5.2. Using Spare Capacity 🌈

CUBIC uses a more aggressive window increase function than Standard TCP does in long-RTT, high-bandwidth networks 🚄

The table below shows that to reach 10 Gbps, Standard TCP needs a packet loss rate of 2.0e-10, while CUBIC needs a packet loss rate of 2.9e-8 🤯

    +------------------+-----------+---------+---------+---------+
    | Throughput(Mbps) | Average W | TCP P   | HSTCP P | CUBIC P |
    +------------------+-----------+---------+---------+---------+
    |                1 |       8.3 | 2.0e-2  | 2.0e-2  | 2.0e-2  |
    |               10 |      83.3 | 2.0e-4  | 3.9e-4  | 2.9e-4  |
    |              100 |     833.3 | 2.0e-6  | 2.5e-5  | 1.4e-5  |
    |             1000 |    8333.3 | 2.0e-8  | 1.5e-6  | 6.3e-7  |
    |            10000 |   83333.3 | 2.0e-10 | 1.0e-7  | 2.9e-8  |
    +------------------+-----------+---------+---------+---------+

Table 3

Table 3 shows the packet loss rate Standard TCP, HSTCP, and CUBIC each need to hit a given throughput. The packets are 1500 bytes and the RTT is 0.1 seconds 📦

Test results in [HKLRX06] show that CUBIC picks up the spare bandwidth that Standard TCP flows leave unused on the same bottleneck link, without taking much bandwidth away from those existing flows 🦋

5.3. Difficult Environments 🛠️

CUBIC is built to fix TCP's poor performance in fast and long-distance networks 🚀

5.4. Investigating a Range of Environments 🔍

CUBIC has been studied extensively using both NS-2 simulation and testbed experiments across a wide range of network environments. You can find more in [HKLRX06] 📚

Just like Standard TCP, CUBIC is a loss-based congestion control algorithm 🫠 CUBIC is designed to be more aggressive than Standard TCP in fast and long-distance networks, thanks to a faster window increase function and a bigger multiplicative decrease factor. So it can fill large drop-tail buffers faster than Standard TCP, which raises the risk of a standing queue [KWAF17] 😬 In that case, proper queue sizing and management [RFC7567] could be used to reduce the packet queuing delay 🧃

5.5. Protection against Congestion Collapse 🛡️

When it comes to causing congestion collapse, CUBIC behaves like Standard TCP, since CUBIC only modifies the window adjustment algorithm of TCP 💅 That means it doesn't change the ACK clocking or the Timeout behaviors of Standard TCP 🫶

okay bestie, we're picking up right where we left off 💅

5.6. Fairness within the Alternative Congestion Control Algorithm 🎀

okay so CUBIC makes sure that competing CUBIC flows with the same RTT on the same bottleneck links end up with an equal throughput 🫶 no cap. when the flows have different RTTs, their throughput ratio is linearly proportional to the inverse of their RTT ratios, so the shorter RTT flow gets the bigger slice 🍓 and this holds independent of the level of statistical multiplexing in the link ✨ literally doesn't care how many flows are sharing it, it's giving consistent 💖

5.7. Performance with Misbehaving Nodes and Outside Attackers 💀

ngl this one is not considered in the current CUBIC 🙈 so that's just where things stand rn

5.8. Behavior for Application-Limited Flows 🌸

okay so CUBIC does not raise its congestion window size if the flow is currently limited by the application instead of the congestion window 🙅‍♀️ and if there are long periods where cwnd hasn't been updated because of the application rate limit (like idle periods), then t in Eq. 1 MUST NOT include those periods 🔥 otherwise W_cubic(t) might be super high after restarting from them, which is so not the vibe 💀

5.9. Responses to Sudden or Transient Events ⭐

if there's a sudden congestion, a routing change, or a mobility event, CUBIC behaves the same as Standard TCP 🧚 no drama, just vibes 🦋

5.10. Incremental Deployment 🌈

CUBIC only requires changes on TCP senders, and it doesn't change TCP receivers at all 🫶 so a CUBIC sender works correctly with Standard TCP receivers, which is iconic ✨ and CUBIC doesn't need any changes to routers either, nor does it need any help from them 👑

6. Security Considerations 🔐

okay this part is lowkey serious 😭 this proposal makes no changes to the underlying security of TCP 💅 if you want the full tea on TCP security concerns, go check [RFC5681] 📚

7. IANA Considerations 🌷

this document does not require any IANA actions 🎀 nothing to register, nothing to request, we're chilling ✨

8. References 📖

8.1. Normative References 💜

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <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>.

[RFC3649]  Floyd, S., "HighSpeed TCP for Large Congestion Windows",
           RFC 3649, DOI 10.17487/RFC3649, December 2003,
           <https://www.rfc-editor.org/info/rfc3649>.

[RFC3742]  Floyd, S., "Limited Slow-Start for TCP with Large
           Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March
           2004, <https://www.rfc-editor.org/info/rfc3742>.

[RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
           RFC 4960, DOI 10.17487/RFC4960, September 2007,
           <https://www.rfc-editor.org/info/rfc4960>.

[RFC5033]  Floyd, S. and M. Allman, "Specifying New Congestion
           Control Algorithms", BCP 133, RFC 5033,
           DOI 10.17487/RFC5033, August 2007,
           <https://www.rfc-editor.org/info/rfc5033>.

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

[RFC6582]  Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
           NewReno Modification to TCP's Fast Recovery Algorithm",
           RFC 6582, DOI 10.17487/RFC6582, April 2012,
           <https://www.rfc-editor.org/info/rfc6582>.

[RFC6675]  Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
           and Y. Nishida, "A Conservative Loss Recovery Algorithm
           Based on Selective Acknowledgment (SACK) for TCP",
           RFC 6675, DOI 10.17487/RFC6675, August 2012,
           <https://www.rfc-editor.org/info/rfc6675>.

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

8.2. Informative References 🦋

[CEHRX07]  Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic
           Ordering for Internet Congestion Control and its
           Applications", In Proceedings of IEEE INFOCOM,
           DOI 10.1109/INFCOM.2007.111, May 2007.

[FHP00]    Floyd, S., Handley, M., and J. Padhye, "A Comparison of
           Equation-Based and AIMD Congestion Control", May 2000.

[GV02]     Gorinsky, S. and H. Vin, "Extended Analysis of Binary
           Adjustment Algorithms", Technical Report TR2002-29,
           Department of Computer Sciences, The University of
           Texas at Austin, August 2002.

[HKLRX06]  Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step
           toward Realistic Performance Evaluation of High-Speed TCP
           Variants", International Workshop on Protocols for Fast
           Long-Distance Networks.

[HR08]     Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth
           and Long-Distance Networks", International Workshop on
           Protocols for Fast Long-Distance Networks.

[HRX08]    Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly
           High-Speed TCP Variant", ACM SIGOPS Operating System
           Review, DOI 10.1145/1400097.1400105, July 2008.

[K03]      Kelly, T., "Scalable TCP: Improving Performance in
           HighSpeed Wide Area Networks", ACM SIGCOMM
           Computer Communication Review, DOI 10.1145/956981.956989,
           April 2003.

[KWAF17]   Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
           "TCP Alternative Backoff with ECN (ABE)", Work in
           Progress, draft-ietf-tcpm-alternativebackoff-ecn-05,
           December 2017.

[XHR04]    Xu, L., Harfoush, K., and I. Rhee, "Binary Increase
           Congestion Control for Fast, Long Distance Networks", In
           Proceedings of IEEE INFOCOM,
           DOI 10.1109/INFCOM.2004.1354672, March 2004.

Acknowledgements 🫶

Alexander Zimmermann and Lars Eggert have received funding from the European Union's Horizon 2020 research and innovation program 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document reflects only the authors' views and the European Commission is not responsible for any use that may be made of the information it contains.

The work of Lisong Xu was partially supported by the National Science Foundation (NSF) under Grant No. 1526253. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the NSF.

Authors' Addresses 💌

Injong Rhee
North Carolina State University
Department of Computer Science
Raleigh, NC  27695-7534
United States of America
Email: rhee@ncsu.edu


Lisong Xu
University of Nebraska-Lincoln
Department of Computer Science and Engineering
Lincoln, NE  68588-0115
United States of America

Email: xu@unl.edu

Sangtae Ha
University of Colorado at Boulder
Department of Computer Science
Boulder, CO  80309-0430
United States of America
Email: sangtae.ha@colorado.edu

Alexander Zimmermann
Phone: +49 175 5766838
Email: alexander.zimmermann@rwth-aachen.de

Lars Eggert
NetApp
Sonnenallee 1
Kirchheim  85551
Germany
Phone: +49 151 12055791
Email: lars@netapp.com

Richard Scheffenegger
NetApp
Am Europlatz 2
Vienna  1120
Austria
Email: rs.ietf@gmx.at
📦 where this page comes from