CUBIC for Fast and Long-Distance NetworksUniversity of Nebraska-LincolnDepartment of Computer Science and EngineeringLincolnNE68588-0115USAxu@unl.eduhttps://cse.unl.edu/~xu/University of Colorado at BoulderDepartment of Computer ScienceBoulderCO80309-0430USAsangtae.ha@colorado.eduhttps://netstech.org/sangtaeha/Bowery Farming151 W 26TH Street, 12TH FloorNew YorkNY10001USAinjongrhee@gmail.comApple Inc.One Apple Park WayCupertinoCalifornia95014USAvidhi_goel@apple.comNetAppStenbergintie 12 BKauniainen02700FIlars@eggert.orghttps://eggert.org/
Transport
TCPMCUBIC is a standard TCP congestion control algorithm that uses a cubic
function instead of the linear window increase function on the sender
side to improve scalability and stability over fast and long-distance
networks. CUBIC has been adopted as the default TCP congestion control
algorithm by the Linux, Windows, and Apple stacks.This document updates the specification of CUBIC to include
algorithmic improvements based on these implementations and recent
academic work. Based on the extensive deployment experience with
CUBIC, it also moves the specification to the Standards Track,
obsoleting .Note to ReadersDiscussion of this draft takes place on the TCPM working group
mailing list, which is archived at
.Working Group information can be found at
; source code and issues list
for this draft can be found at .Note to the RFC Editorxml2rfc currently renders <em></em> in the XML by surrounding the
corresponding text with underscores. This is highly distracting;
please manually remove the underscores when doing the final edits to
the text version of this document.(There is an issue open against xml2rfc to stop doing this in the
future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/596)IntroductionCUBIC has been adopted as the default TCP congestion control algorithm
in the Linux, Windows, and Apple stacks, and has been used and
deployed globally. Extensive, decade-long deployment experience in
vastly different Internet scenarios has convincingly demonstrated that
CUBIC is safe for deployment on the global Internet and delivers
substantial benefits over traditional AIMD congestion control. It is
therefore to be regarded as the current standard for TCP congestion
control.The design of CUBIC was motivated by the well-documented problem
traditional TCP has with low utilization over fast and long-distance
networks . This problem arises from a slow increase
of the congestion window following a congestion event in a network
with a large bandwidth-delay product (BDP). indicates that
this problem is frequently observed even in the range of congestion
window sizes over several hundreds of packets. This problem is equally
applicable to all Reno-style TCP standards and their variants,
including TCP-Reno , TCP-NewReno ,
SCTP , and TFRC , which use the same linear
increase function for window growth. We refer to all Reno-style TCP
standards and their variants collectively as "AIMD TCP" below because
they use the Additive Increase and Multiplicative Decrease algorithm
(AIMD).CUBIC, originally proposed in , is a modification to the
congestion control algorithm of traditional AIMD TCP to remedy this
problem. This document describes the most recent specification of
CUBIC. Specifically, CUBIC uses a cubic function instead of the linear
window increase function of AIMD TCP to improve scalability and
stability under fast and long-distance networks.Binary Increase Congestion Control (BIC-TCP) , a predecessor
of CUBIC, was selected as the default TCP congestion control algorithm
by Linux in the year 2005 and had been used for several years by the
Internet community at large.CUBIC uses a similar window increase function as BIC-TCP and is
designed to be less aggressive and fairer to AIMD TCP in bandwidth
usage than BIC-TCP while maintaining the strengths of BIC-TCP such as
stability, window scalability, and round-trip time (RTT) fairness.In the following sections, we first briefly explain the design
principles of CUBIC, then provide the exact specification of CUBIC,
and finally discuss the safety features of CUBIC following the
guidelines specified in .ConventionsThe 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 when, and only when, they
appear in all capitals, as shown here.Design Principles of CUBICCUBIC is designed according to the following design principles:
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 AIMD-friendly, CUBIC is designed to behave like AIMD TCP in
networks with short RTTs and small bandwidth where AIMD 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.
Principle 1 for the CUBIC Increase FunctionFor better network utilization and stability, CUBIC uses a
cubic window increase function in terms of the elapsed time from the
last congestion event. While most alternative congestion control
algorithms to AIMD TCP increase the congestion window using convex
functions, CUBIC uses both the concave and convex profiles of a cubic
function for window growth.After a window reduction in response to a congestion event is detected
by duplicate ACKs or Explicit Congestion Notification-Echo (ECN-Echo,
ECE) ACKs , CUBIC remembers the congestion window size
where it received the congestion event and performs a multiplicative
decrease of the congestion window. When CUBIC enters into congestion
avoidance, it starts to increase the congestion window using the
concave profile of the cubic function. The cubic function is set to
have its plateau at the remembered congestion window size, so that the
concave window increase continues until then. After that, the cubic
function turns into a convex profile and the convex window increase
begins.This style of window adjustment (concave and then convex) improves the
algorithm stability while maintaining high network utilization
. This is because the window size remains almost constant,
forming a plateau around the remembered congestion window size of the
last congestion event, where network utilization is deemed highest.
Under steady state, most window size samples of CUBIC are close to
that remembered congestion window size, thus promoting high network
utilization and stability.Note that congestion control algorithms that only use convex functions
to increase the congestion window size have their maximum increments
around the remembered congestion window size of the last congestion
event, and thus introduce many packet bursts around the
saturation point of the network, likely causing frequent global loss
synchronizations.Principle 2 for AIMD FriendlinessCUBIC promotes per-flow fairness to AIMD TCP. Note that AIMD TCP
performs well over paths with short RTTs and small bandwidths (or
small BDPs). There is only a scalability problem in networks with long
RTTs and large bandwidths (or large BDPs).A congestion control algorithm designed to be friendly to AIMD TCP on
a per-flow basis must increase its congestion window less aggressively
in small BDP networks than in large BDP networks.The aggressiveness of CUBIC mainly depends on the maximum window size
before a window reduction, which is smaller in small-BDP networks than
in large-BDP networks. Thus, CUBIC increases its congestion window
less aggressively in small-BDP networks than in large-BDP networks.Furthermore, in cases when the cubic function of CUBIC would increase
the congestion window less aggressively than AIMD TCP, CUBIC simply
follows the window size of AIMD TCP to ensure that CUBIC achieves at
least the same throughput as AIMD TCP in small-BDP networks. We call
this region where CUBIC behaves like AIMD TCP the "AIMD-friendly
region".Principle 3 for RTT FairnessTwo CUBIC flows with different RTTs have a throughput ratio that is
linearly proportional to the inverse of their RTT ratio, where the
throughput of a flow is approximately the size of its congestion
window divided by its RTT.Specifically, CUBIC maintains a window increase rate independent of
RTTs outside the AIMD-friendly region, and thus flows with
different RTTs have similar congestion window sizes under steady state
when they operate outside the AIMD-friendly region.This notion of a linear throughput ratio is similar to that of AIMD
TCP under high statistical multiplexing where packet loss is
independent of individual flow rates. However, under low statistical
multiplexing, the throughput ratio of AIMD TCP flows with different
RTTs is quadratically proportional to the inverse of their RTT ratio
.CUBIC always ensures a linear throughput ratio independent of the
amount of statistical multiplexing. This is an improvement over AIMD
TCP. While there is no consensus on particular throughput ratios for
different RTT flows, we believe that over wired Internet paths, use of
a linear throughput ratio seems more reasonable than equal throughputs
(i.e., the same throughput for flows with different RTTs) or a
higher-order throughput ratio (e.g., a quadratical throughput ratio of
AIMD TCP under low statistical multiplexing environments).Principle 4 for the CUBIC Decrease FactorTo balance between scalability and convergence speed, CUBIC sets the
multiplicative window decrease factor to 0.7, whereas AIMD TCP uses
0.5.While this improves the scalability of CUBIC, a side effect of this
decision is slower convergence, especially under low statistical
multiplexing. This design choice is following the observation that
HighSpeed TCP (HSTCP) and other approaches (e.g.,
) made: the current Internet becomes more asynchronous with
less frequent loss synchronizations under high statistical
multiplexing.In such environments, even strict Multiplicative-Increase
Multiplicative-Decrease (MIMD) can converge. CUBIC flows with the same
RTT always converge to the same throughput independent of statistical
multiplexing, thus achieving intra-algorithm fairness. We also find
that in environments with sufficient statistical multiplexing, the
convergence speed of CUBIC is reasonable.CUBIC Congestion ControlIn this section, we discuss how the congestion window is updated
during the different stages of the CUBIC congestion controller.DefinitionsThe unit of all window sizes in this document is segments of the
maximum segment size (MSS), and the unit of all times is seconds.Constants of Interestcubic:
CUBIC multiplication decrease factor as described in .aimd:
CUBIC additive increase factor used in AIMD-friendly region
as described in .C:
constant that determines the aggressiveness of CUBIC in competing with
other congestion control algorithms in high BDP networks. Please see
for more explanation on how it is set. The unit for C
isVariables of InterestThis section defines the variables required to implement CUBIC:RTT:
Smoothed round-trip time in seconds, calculated as described in
.cwnd:
Current congestion window in segments.ssthresh:
Current slow start threshold in segments.Wmax:
Size of cwnd in segments just before cwnd was reduced in the last
congestion event when fast convergence is disabled. However, if fast
convergence is enabled, the size may be further reduced based on the
current saturation point.K:
The time period in seconds it takes to increase the congestion window
size at the beginning of the current congestion avoidance stage to
Wmax.current_time:
Current time of the system in seconds.epochstart:
The time in seconds at which the current congestion avoidance stage
started.cwndstart:
The cwnd at the beginning of the current congestion avoidance stage,
i.e., at time epochstart.Wcubic(t):
The congestion window in segments at time t in seconds
based on the cubic increase function, as described in .target:
Target value of congestion window in segments after the next RTT,
that is, Wcubic(t + RTT), as described in .West:
An estimate for the congestion window in segments in the AIMD-friendly
region, that is, an estimate for the congestion window of AIMD TCP.segments_acked:
Number of segments acked when an ACK is received.Window Increase FunctionCUBIC maintains the acknowledgment (ACK) clocking of AIMD TCP by
increasing the congestion window only at the reception of an ACK. It
does not make any changes to the TCP Fast Recovery and Fast Retransmit
algorithms .During congestion avoidance after a congestion event where a packet
loss is detected by duplicate ACKs or by receiving packets carrying
ECE flags , CUBIC changes the window increase function of
AIMD TCP.CUBIC uses the following window increase function:where t is the elapsed time in seconds from the beginning of the
current congestion avoidance stage, that is,and where epochstart is the time at which the current
congestion avoidance stage starts. K is the time period that the
above function takes to increase the congestion window size at the
beginning of the current congestion avoidance stage to
Wmax if there are no further congestion events and is
calculated using the following equation:where cwndstart is the congestion window at the beginning
of the current congestion avoidance stage. For example, right after a
congestion event, cwndstart is equal to the new cwnd
calculated as described in .Upon receiving an ACK during congestion avoidance, CUBIC computes the
target congestion window size after the next RTT using as
follows, where RTT is the smoothed round-trip time. The lower and
upper bounds below ensure that CUBIC's congestion window increase rate
is non-decreasing and is less than the increase rate of slow start. 1.5 * cwnd
|1.5 * cwnd cubic
|
|
|W (t + RTT)
| cubic otherwise
\
]]>Depending on the value of the current congestion window size cwnd,
CUBIC runs in three different regions:
The AIMD-friendly region, which ensures that CUBIC achieves at
least the same throughput as AIMD TCP.
The concave region, if CUBIC is not in the AIMD-friendly region
and cwnd is less than Wmax.
The convex region, if CUBIC is not in the AIMD-friendly region and
cwnd is greater than Wmax.
Below, we describe the exact actions taken by CUBIC in each region.AIMD-Friendly RegionAIMD TCP performs well in certain types of networks, for example,
under short RTTs and small bandwidths (or small BDPs). In these
networks, CUBIC remains in the AIMD-friendly region to achieve at
least the same throughput as AIMD TCP.The AIMD-friendly region is designed according to the analysis in
, which studies the performance of an AIMD algorithm with an
additive factor of aimd (segments per RTT) and
a multiplicative factor of aimd, denoted by
AIMD(aimd, aimd).
Specifically, the average congestion window size of
AIMD(aimd, aimd) can be
calculated using . The analysis shows that
AIMD(aimd, aimd) withachieves the same average window size as AIMD TCP that uses
AIMD(1, 0.5).Based on the above analysis, CUBIC uses to estimate the window
size West of AIMD(aimd,
aimd) withwhich achieves the same average window size as AIMD TCP. When
receiving an ACK in congestion avoidance (where cwnd could be
greater than or less than Wmax), CUBIC checks whether
Wcubic(t) is less than West. If so, CUBIC is
in the AIMD-friendly region and cwnd SHOULD be set to
West at each reception of an ACK.West is set equal to cwndstart at the start
of the congestion avoidance stage. After that, on every ACK,
West is updated using .Note that once West reaches Wmax, that is,
West >= Wmax, aimd
SHOULD be set to 1 to achieve the same congestion window increment as
AIMD TCP, which uses AIMD(1, 0.5).Concave RegionWhen receiving an ACK in congestion avoidance, if CUBIC is not in the
AIMD-friendly region and cwnd is less than Wmax, then
CUBIC is in the concave region. In this region, cwnd MUST be
incremented byfor each received ACK, where target is calculated as described in
.Convex RegionWhen receiving an ACK in congestion avoidance, if CUBIC is not in the
AIMD-friendly region and cwnd is larger than or equal to
Wmax, then CUBIC is in the convex region.The convex region indicates that the network conditions might have
changed since the last congestion event, possibly implying more
available bandwidth after some flow departures. Since the Internet is
highly asynchronous, some amount of perturbation is always possible
without causing a major change in available bandwidth.In this region, CUBIC is very careful. The convex profile ensures that
the window increases very slowly at the beginning and gradually
increases its increase rate. We also call this region the "maximum
probing phase", since CUBIC is searching for a new Wmax.
In this region, cwnd MUST be incremented byfor each received ACK, where target is calculated as described in
.Multiplicative DecreaseWhen a packet loss is detected by duplicate ACKs or by receiving
packets carrying ECE flags, CUBIC updates Wmax and
reduces cwnd and ssthresh immediately as described below. An
implementation MAY set a smaller ssthresh than suggested below to
accommodate rate-limited applications as described in .
For both packet loss and congestion detection through ECN, the sender
MAY employ a Fast Recovery algorithm to gradually adjust the
congestion window to its new reduced ssthresh value. The parameter
cubic SHOULD be set to 0.7.A side effect of setting cubic to a value bigger
than 0.5 is slower convergence. We believe that while a more adaptive
setting of cubic could result in faster
convergence, it will make the analysis of CUBIC much harder.Fast ConvergenceTo improve convergence speed, CUBIC uses a heuristic. When a new flow
joins the network, existing flows need to give up some of their
bandwidth to allow the new flow some room for growth, if the existing
flows have been using all the network bandwidth. To speed up this
bandwidth release by existing flows, the following "Fast Convergence"
mechanism SHOULD be implemented.With Fast Convergence, when a congestion event occurs, we update
Wmax as follows, before the window reduction as described
in .At a congestion event, if the current cwnd is less than
Wmax, this indicates that the saturation point
experienced by this flow is getting reduced because of a change in
available bandwidth. Then we allow this flow to release more bandwidth
by reducing Wmax further. This action effectively
lengthens the time for this flow to increase its congestion window,
because the reduced Wmax forces the flow to plateau
earlier. This allows more time for the new flow to catch up to its
congestion window size.Fast Convergence is designed for network environments with multiple
CUBIC flows. In network environments with only a single CUBIC flow and
without any other traffic, Fast Convergence SHOULD be disabled.TimeoutIn case of a timeout, CUBIC follows AIMD TCP to reduce cwnd, but sets ssthresh using cubic
(same as in ) in a way that is different from AIMD TCP
.During the first congestion avoidance stage after a timeout, CUBIC
increases its congestion window size using , where t is the
elapsed time since the beginning of the current congestion avoidance,
K is set to 0, and Wmax is set to the congestion window
size at the beginning of the current congestion avoidance stage. In
addition, for the AIMD-friendly region, West SHOULD be
set to the congestion window size at the beginning of the current
congestion avoidance.Spurious Congestion EventsIn cases where CUBIC reduces its congestion window in response to
having detected packet loss via duplicate ACKs or timeouts, there is a
possibility that the missing ACK would arrive after the congestion
window reduction and a corresponding packet retransmission. For
example, packet reordering could trigger this behavior. A high degree
of packet reordering could cause multiple congestion window reduction
events, where spurious losses are incorrectly interpreted as
congestion signals, thus degrading CUBIC's performance significantly.When there is a congestion event, a CUBIC implementation SHOULD save
the current value of the following variables before the congestion
window reduction.CUBIC MAY implement an algorithm to detect spurious retransmissions,
such as DSACK , Forward RTO-Recovery or Eifel
. Once a spurious congestion event is detected, CUBIC
SHOULD restore the original values of above mentioned variables as
follows if the current cwnd is lower than prior_cwnd. Restoring
the original values ensures that CUBIC's performance is similar to
what it would be without spurious losses.if cwnd < prior_cwnd
K = prior_K |
|
epoch = prior_epoch |
start start|
|
W = prior_W |
est est /
]]>In rare cases, when the detection happens long after a spurious loss
event and the current cwnd is already higher than prior_cwnd,
CUBIC SHOULD continue to use the current and the most recent values of
these variables.Slow StartCUBIC MUST employ a slow-start algorithm, when cwnd is no more than
ssthresh. Among the slow-start algorithms, CUBIC MAY choose the AIMD
TCP slow start in general networks, or the limited slow
start or hybrid slow start for fast and
long-distance networks.When CUBIC uses hybrid slow start , it may exit the first slow
start without incurring any packet loss and thus Wmax is
undefined. In this special case, CUBIC switches to congestion
avoidance and increases its congestion window size using ,
where t is the elapsed time since the beginning of the current
congestion avoidance, K is set to 0, and Wmax is set to
the congestion window size at the beginning of the current congestion
avoidance stage.DiscussionIn this section, we further discuss the safety features of CUBIC
following the guidelines specified in .With a deterministic loss model where the number of packets between
two successive packet losses is always 1/p, CUBIC always operates
with the concave window profile, which greatly simplifies the
performance analysis of CUBIC. The average window size of CUBIC can be
obtained by the following function:With cubic set to 0.7, the above formula reduces
to:We will determine the value of C in the following subsection using
.Fairness to AIMD TCPIn environments where AIMD TCP is able to make reasonable use of the
available bandwidth, CUBIC does not significantly change this state.AIMD TCP performs well in the following two types of networks:
networks with a small bandwidth-delay product (BDP)
networks with a short RTTs, but not necessarily a small BDP
CUBIC is designed to behave very similarly to AIMD TCP in the above
two types of networks. The following two tables show the average
window sizes of AIMD TCP, HSTCP, and CUBIC. The average window sizes
of AIMD TCP and HSTCP are from . The average window size
of CUBIC is calculated using and the CUBIC AIMD-friendly
region for three different values of C.
AIMD TCP, HSTCP, and CUBIC with RTT = 0.1 seconds
Loss Rate P
AIMD
HSTCP
CUBIC (C=0.04)
CUBIC (C=0.4)
CUBIC (C=4)
1.0e-02
12
12
12
12
12
1.0e-03
38
38
38
38
59
1.0e-04
120
263
120
187
333
1.0e-05
379
1795
593
1054
1874
1.0e-06
1200
12280
3332
5926
10538
1.0e-07
3795
83981
18740
33325
59261
1.0e-08
12000
574356
105383
187400
333250
describes the response function of AIMD TCP, HSTCP, and CUBIC
in networks with RTT = 0.1 seconds. The average window size is in
MSS-sized segments.
AIMD TCP, HSTCP, and CUBIC with RTT = 0.01 seconds
Loss Rate P
AIMD
HSTCP
CUBIC (C=0.04)
CUBIC (C=0.4)
CUBIC (C=4)
1.0e-02
12
12
12
12
12
1.0e-03
38
38
38
38
38
1.0e-04
120
263
120
120
120
1.0e-05
379
1795
379
379
379
1.0e-06
1200
12280
1200
1200
1874
1.0e-07
3795
83981
3795
5926
10538
1.0e-08
12000
574356
18740
33325
59261
describes the response function of AIMD 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 more
friendly to AIMD TCP than HSTCP, especially in networks with a short
RTT where AIMD TCP performs reasonably well. For example, in a
network with RTT = 0.01 seconds and p=10^-6, AIMD TCP has an average
window of 1200 packets. If the packet size is 1500 bytes, then AIMD
TCP can achieve an average rate of 1.44 Gbps. In this case, CUBIC with
C=0.04 or C=0.4 achieves exactly the same rate as AIMD TCP,
whereas HSTCP is about ten times more aggressive than AIMD TCP.We can see that C determines the aggressiveness of CUBIC in
competing with other congestion control algorithms for bandwidth.
CUBIC is more friendly to AIMD TCP, if the value of C is lower.
However, we do not recommend setting C to a very low value like
0.04, since CUBIC with a low C cannot efficiently use the bandwidth
in fast and long-distance networks. Based on these observations and
extensive deployment experience, we find C=0.4 gives a good balance
between AIMD- friendliness and aggressiveness of window increase.
Therefore, C SHOULD be set to 0.4. With C set to 0.4, is
reduced to: is then used in the next subsection to show the scalability of
CUBIC.Using Spare CapacityCUBIC uses a more aggressive window increase function than AIMD TCP
for fast and long-distance networks.The following table shows that to achieve the 10 Gbps rate, AIMD TCP
requires a packet loss rate of 2.0e-10, while CUBIC requires a packet
loss rate of 2.9e-8.
Required packet loss rate for AIMD TCP, HSTCP, and CUBIC to achieve a certain throughput
Throughput (Mbps)
Average W
AIMD 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
describes the required packet loss rate for AIMD TCP, HSTCP,
and CUBIC to achieve a certain throughput. We use 1500-byte packets
and an RTT of 0.1 seconds.Our test results in indicate that CUBIC uses the spare
bandwidth left unused by existing AIMD TCP flows in the same
bottleneck link without taking away much bandwidth from the existing
flows.Difficult EnvironmentsCUBIC is designed to remedy the poor performance of AIMD TCP in fast
and long-distance networks.Investigating a Range of EnvironmentsThere is decade-long deployment experience with CUBIC on the Internet.
CUBIC has also been extensively studied by using both NS-2 simulation
and testbed experiments, covering a wide range of network
environments. More information can be found in .Same as AIMD TCP, CUBIC is a loss-based congestion control algorithm.
Because CUBIC is designed to be more aggressive (due to a faster
window increase function and bigger multiplicative decrease factor)
than AIMD TCP in fast and long-distance networks, it can fill large
drop-tail buffers more quickly than AIMD TCP and increases the risk of
a standing queue . In this case, proper queue sizing and
management could be used to reduce the packet queuing
delay.Protection against Congestion CollapseWith regard to the potential of causing congestion collapse, CUBIC
behaves like AIMD TCP, since CUBIC modifies only the window adjustment
algorithm of AIMD TCP. Thus, it does not modify the ACK clocking and
timeout behaviors of AIMD TCP.Fairness within the Alternative Congestion Control AlgorithmCUBIC ensures convergence of competing CUBIC flows with the same RTT
in the same bottleneck links to an equal throughput. When competing
flows have different RTT values, their throughput ratio is linearly
proportional to the inverse of their RTT ratios. This is true
independently of the level of statistical multiplexing on the link.Performance with Misbehaving Nodes and Outside AttackersThis is not considered in the current CUBIC design.Behavior for Application-Limited FlowsCUBIC does not increase its congestion window size if a flow is
currently limited by the application instead of the congestion window.
In case of long periods during which cwnd has not been updated due
to such an application limit, such as idle periods, t in
MUST NOT include these periods; otherwise, Wcubic(t)
might be very high after restarting from these periods.Responses to Sudden or Transient EventsIf there is a sudden congestion, a routing change, or a mobility
event, CUBIC behaves the same as AIMD TCP.Incremental DeploymentCUBIC requires only changes to TCP senders, and it does not require
any changes at TCP receivers. That is, a CUBIC sender works correctly
with the AIMD TCP receivers. In addition, CUBIC does not require any
changes to routers and does not require any assistance from routers.Security ConsiderationsCUBIC makes no changes to the underlying security of TCP. More
information about TCP security concerns can be found in .IANA ConsiderationsThis document does not require any IANA actions.ReferencesNormative ReferencesTCP Congestion ControlThis document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]The NewReno Modification to TCP's Fast Recovery AlgorithmRFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. [STANDARDS-TRACK]A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCPThis document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. [STANDARDS-TRACK]TCP Friendly Rate Control (TFRC): Protocol SpecificationThis document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance.This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK]Specifying New Congestion Control AlgorithmsThe IETF's standard congestion control schemes have been widely shown to be inadequate for various environments (e.g., high-speed networks). Recent research has yielded many alternate congestion control schemes that significantly differ from the IETF's congestion control principles. Using these new congestion control schemes in the global Internet has possible ramifications to both the traffic using the new congestion control and to traffic using the currently standardized congestion control. Therefore, the IETF must proceed with caution when dealing with alternate congestion control proposals. The goal of this document is to provide guidance for considering alternate congestion control algorithms within the IETF. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Addition of Explicit Congestion Notification (ECN) to IPThis memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]Computing TCP's Retransmission TimerThis document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. [STANDARDS-TRACK]IETF Recommendations Regarding Active Queue ManagementThis memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification.Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309.Informative ReferencesA Comparison of Equation-Based and AIMD Congestion ControlExtended Analysis of Binary Adjustment AlgorithmsA Step toward Realistic Performance Evaluation of High-Speed TCP VariantsHybrid Slow Start for High-Bandwidth and Long-Distance NetworksBinary Increase Congestion Control (BIC) for Fast Long-Distance NetworksModel-Agnostic and Efficient Exploration of Numerical State Space of Real-World TCP Congestion Control ImplementationsStochastic Ordering for Internet Congestion Control and its ApplicationsCUBIC: a new TCP-friendly high-speed TCP variantScalable TCP: improving performance in highspeed wide area networksCUBIC for Fast Long-Distance NetworksCUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC.HighSpeed TCP for Large Congestion WindowsThe proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals. This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the current Standard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address his limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.Stream Control Transmission ProtocolThis document obsoletes RFC 2960 and RFC 3309. It describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users:-- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size,-- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. [STANDARDS-TRACK]Updating TCP to Support Rate-Limited TrafficThis document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced.This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious RetransmissionsTCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. This memo defines an Experimental Protocol for the Internet community.Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCPThe purpose of this document is to move the F-RTO (Forward RTO-Recovery) functionality for TCP in RFC 4138 from Experimental to Standards Track status. The F-RTO support for Stream Control Transmission Protocol (SCTP) in RFC 4138 remains with Experimental status. See Appendix B for the differences between this document and RFC 4138.Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. [STANDARDS-TRACK]The Eifel Detection Algorithm for TCPThe Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. This memo defines an Experimental Protocol for the Internet community.Limited Slow-Start for TCP with Large Congestion WindowsThis document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender's MAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describes Limited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance for TCP connections with large congestion windows. This memo defines an Experimental Protocol for the Internet community.TCP Alternative Backoff with ECN (ABE)Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311.AcknowledgmentsRichard Scheffenegger and Alexander Zimmermann originally co-authored
.Evolution of CUBICSince draft-ietf-tcpm-rfc8312bis-01
address Michael Scharf's editorial suggestions.
(#59)
add "Note to the RFC Editor" about removing underscores
Since draft-ietf-tcpm-rfc8312bis-00
use updated xml2rfc with better text rendering of subscripts
Since draft-eggert-tcpm-rfc8312bis-03
fix spelling nits
rename to draft-ietf
define Wmax more clearly
Since draft-eggert-tcpm-rfc8312bis-02
add definition for segments_acked and alphaaimd.
(#47)
fix a mistake in Wmax calculation in the fast convergence section.
(#51)
clarity on setting ssthresh and cwndstart during
multiplicative decrease.
(#53)
Since draft-eggert-tcpm-rfc8312bis-01
rename TCP-Friendly to AIMD-Friendly and rename Standard TCP to AIMD
TCP to avoid confusion as CUBIC has been widely used on the Internet.
(#38)
change introductory text to reflect the significant broader
deployment of CUBIC on the Internet.
(#39)
rephrase introduction to avoid referring to variables that have not
been defined yet.
Since draft-eggert-tcpm-rfc8312bis-00
acknowledge former co-authors
(#15)
prevent cwnd from becoming less than two
(#7)
add list of variables and constants
(#5,
#6)
update K's definition and add bounds for CUBIC targetcwnd (#1,
#14)
update West to use AIMD approach
(#20)
set alphaaimd to 1 once
West reaches Wmax
(#2)
add Vidhi as co-author
(#17)
note for Fast Recovery during cwnd decrease due to congestion
event (#11)
add section for spurious congestion events
(#23)
initialize West after timeout and remove variable
Wlast_max
(#28)
Since RFC8312
converted to Markdown and xml2rfc v3
updated references (as part of the conversion)
updated author information
various formatting changes
move to Standards Track
Since the Original PaperCUBIC has gone through a few changes since the initial release
of its algorithm and implementation. Below we highlight the
differences between its original paper and .
The original paper includes the pseudocode of CUBIC
implementation using Linux's pluggable congestion control framework,
which excludes system-specific optimizations. The simplified
pseudocode might be a good source to start with and understand CUBIC.
also includes experimental results showing its performance
and fairness.
The definition of betacubic constant
was changed in . For example,
betacubic in the original paper was the
window decrease constant while changed it to CUBIC
multiplication decrease factor. With this change, the current
congestion window size after a congestion event in was
betacubic * Wmax while it was
(1-betacubic) * Wmax in the
original paper.
Its pseudocode used Wlast_max while used
Wmax.
Its AIMD-friendly window was Wtcp while used
West.