CUBIC: A New TCP-Friendly High-Speed TCP Variant ∗

Sangtae Ha, Injong Rhee Lisong Xu

Dept of Computer Science Dept of Comp. Sci. and Eng.
North Carolina State University University of Nebraska
Raleigh, NC 27695 Lincoln, Nebraska 68588
{sha2,rhee}@ncsu.edu [email protected]

ABSTRACT “high-speed” TCP variants are proposed (e.g., FAST [24],

CUBIC is a congestion control protocol for TCP (transmis- HSTCP [15], STCP [25], HTCP [28], SQRT [19], West-
sion control protocol) and the current default TCP algo- wood [14], and BIC-TCP [30]). Recognizing this problem
rithm in Linux. The protocol modifies the linear window with TCP, the Linux community responded quickly to im-
growth function of existing TCP standards to be a cubic plement a majority of these protocols in Linux and ship
function in order to improve the scalability of TCP over them as part of its operating system. After a series of third-
fast and long distance networks. It also achieves more eq- party testing and performance validation [11, 21], in 2004,
uitable bandwidth allocations among flows with different from version 2.6.8, it selected BIC-TCP as the default TCP
RTTs (round trip times) by making the window growth to algorithm and the other TCP variants as optional.
be independent of RTT – thus those flows grow their conges-
tion window at the same rate. During steady state, CUBIC What makes BIC-TCP stand out from other TCP algor-
increases the window size aggressively when the window is tihms is its stability. It uses a binary search algorithm where
far from the saturation point, and the slowly when it is close the window grows to the mid-point between the last win-
to the saturation point. This feature allows CUBIC to be dow size (i.e., max) where TCP has a packet loss and the
very scalable when the bandwidth and delay product of the last window size (i.e., min) it does not have a loss for one
network is large, and at the same time, be highly stable and RTT period. This “search” into the mid-point intuitively
also fair to standard TCP flows. The implementation of makes sense because the capacity of the current path must
CUBIC in Linux has gone through several upgrades. This be somewhere between the two min and max window sizes
paper documents its design, implementation, performance if the network conditions do not quickly change since the
and evolution as the default TCP algorithm of Linux. last congestion signal (which is the last packet loss). After
the window grows to the mid-point, if the network does not
have packet losses, then it means that the network can han-
1. INTRODUCTION dle more traffic and thus BIC-TCP sets the mid-point to
As the Internet evolves to include many very high speed be the new min and performs another “binary-search” with
and long distance network paths, the performance of TCP the min and max windows. This has an effect of growing
was challenged. These networks are characterized by large the window really fast when the current window size is far
bandwidth and delay product (BDP) which represents the from the available capacity of the path, and furthermore, if
total number of packets needed in flight while keeping the it is close to the available capacity (where we had the pre-
bandwidth fully utilized, in other words, the size of the con- vious loss), it slowly reduces its window increment. It has
gestion window. In standard TCP like TCP-Reno, TCP- the smallest window increment at the saturation point and
NewReno and TCP-SACK, TCP grows its window one per its overshoots amount beyond the saturation point where
round trip time (RTT). This makes the data transport speed losses occur very small. The whole window growth func-
of TCP∗ used in all major operating systems including Win- tion is simply a logarithmic concave function. This concave
dows and Linux rather sluggish, to say the least, extremely function keeps the congestion window much longer at the
under-utilizing the networks especially if the length of flows saturation point or equilibrium than convex or linear func-
is much shorter than the time TCP grows its windows to tions where they have the largest window increment at the
the full size of the BDP of a path. For instance, if the band- saturation point and thus have the largest overshoot at the
width of a network path is 10 Gbps and the RTT is 100 ms, time packet losses occur. These features make BIC-TCP
with packets of 1250 bytes, the BDP of the path is around very stable and at the same time highly scalable.
100,000 packets. For TCP to grow its window from the mid-
point of the BDP, say 50,000, it takes about 50,000 RTTs BIC-TCP trades the speed to react to changes in avail-
which amounts to 5000 seconds (1.4 hours). If a flow finishes able bandwidth (i.e., convergence speed) for stability. If the
before that time, it severely under-utilizes the path. available capacity has increased since the last packet losses,
the window can grow beyond the max without having a loss.
To counter this under-utilization problem of TCP, many At that time, BIC-TCP increases the window exponentially.
∗
A short version [27] of this paper was presented at the Inter- Note that an exponential function (a convex function) grows
national Workshop on Protocols for Fast and Long Distance very slowly at the beginning (slower than a linear function).
Networks in 2005. This feature adds to the stability of the protocol because
∗
For brevity, we also denote Standard TCP as TCP.
even if the protocol makes mistakes in finding the max win- The remainder of this paper is organized as follows. Section
dow, it finds the next max window near the previous max 2 gives related work, Section 3 presents the details of CU-
point first, thus staying at the previous saturation point BIC algorithms in Linux, Section 4 includes the evolution
longer. But the exponential function quickly catches up and of CUBIC and its implementation in Linux, and Section 5
its increment becomes very large if the losses do not occur includes discussion related to fairness property of CUBIC.
(in which case, the saturation point has become much larger Section 6 presents the results of experimental evaluation and
than the previous one). Because it stays longer near the pre- Section 7 gives conclusion.
vious saturation point than other variants, it can be slug-
gish to find the new saturation point if the saturation point 2. RELATED WORK
has increased far beyond the last one. BIC-TCP, however,
Kelly proposed Scalable TCP (STCP) [25]. The design ob-
safely reacts fast to reduced capacity because packet losses
jective of STCP is to make the recovery time from loss events
occur before the previous max and it reduces the window
be constant regardless of the window size. This is why it
by a multiplicative factor. This tradeoff is a design choice
is called “Scalable”. Note that the recovery time of TCP-
of BIC-TCP. It is known [31] that available bandwidth in
NewReno largely depends on the current window size.
the Internet change over a long time scale of several hours.
Given that packet losses would occur very asynchronously
HighSpeed TCP (HSTCP) [15] uses a generalized AIMD
and also proportionally to the bandwidth consumption of a
where the linear increase factor and multiplicative decrease
flow under a highly statistically multiplexed environment,
factor are adjusted by a convex fucntion of the current con-
fast convergence is a natural consequence of the network en-
gestion window size. When the congestion window is less
vironment – something the protocol does not have to force.
than some cutoff value, HSTCP uses the same factors as
Thus, although BIC-TCP may converge slowly under low
TCP. Most of high-speed TCP variants support this form
statistical multiplexing where only a few flows are compet-
of TCP compatibility, which is based on the window size.
ing, its convergence speed is not an issue under typical In-
When the window grows beyond the cutoff point, the con-
ternet environments.
vex function increases the increase factor and reduces the
decrease factor proportionally to the window size.
CUBIC [27] is the next version of BIC-TCP. It greatly sim-
plifies the window adjustment algorithm of BIC-TCP by re-
HTCP [28], like CUBIC, uses the elapsed time (∆) since
placing the concave and convex window growth portions of
the last congestion event for calculating the current conges-
BIC-TCP by a cubic function (which contains both concave
tion window size. The window growth function of HTCP
and convex portions). In fact, any odd order polynomial
is a quadratic function of ∆. HTCP is unique in that it
function has this shape. The choice for a cubic function is
adjusts the decrease factor by a function of RTTs which is
incidental and out of convenience. The key feature of CU-
engineered to estimate the queue size in the network path
BIC is that its window growth depends only on the real time
of the current flow. Thus, the decrease factor is adjusted to
between two consecutive congestion events. One congestion
be proportional to the queue size.
event is the time when TCP undergoes fast recovery. We call
this real time a congestion epoch. Thus, the window growth
TCP-Vegas [10] measures the difference (δ) between expected
becomes independent of RTTs. This feature allows CUBIC
throughput and actual throughput based on round-trip de-
flows competing in the same bottleneck to have approxi-
lays. When δ is less than a low threshold α, TCP-Vegas
mately the same window size independent of their RTTs,
believes the path is not congested and thus increases the
achieving good RTT-fairness. Furthermore, when RTTs are
sending rate. When δ is larger than a upper threshold β,
short, since the window growth rate is fixed, its growth rate
which is a strong indication of congestion, TCP-Vegas re-
could be slower than TCP standards. Since TCP standards
duces the sending rate. Otherwise, TCP-Vegas maintains
(e.g., TCP-SACK) work well under short RTTs, this feature
the current sending rate. The expected throughput is cal-
enhances the TCP-friendliness of the protocol.
culated by dividing the current congestion window by the
minimum RTT which typically contains the delay when the
The implementation of CUBIC in Linux has gone through
path is not congested. For each round trip time, TCP-Vegas
several upgrades. The most notable upgrade is the efficient
computes the actual throughput by dividing the number of
implementation of cubic root calculation. Since it requires
packets sent by the sampled RTT.
a floating point operation, implementing it in the kernel re-
quires some integer approximation. Initially it used the bi-
FAST [24] determines the current congestion window size
section method and later changed to the Newton-Raphson
based on both round-trip delays and packet losses over a
method which reduces the computational cost almost by 10
path. FAST updates the sending rate at every other RTT
times. Another change to CUBIC after inception is the re-
with rate-pacing. The algorithm estimates the queuing de-
moval of window clamping. Window clamping was intro-
lay of the path using RTTs and if the delay is well below
duced in BIC-TCP where window increments are clamped
a threshold, it increases the window aggressively and if it
to a maximum increment and was inherited to CUBIC for
gets closer to the threshold, the algorithm slowly reduces
the first version. This forces the window growth to be linear
the increasing rate. The opposite happens when the delay
when the target mid-point is much larger than the current
increases beyond the threshold: slowly decreases the window
window size. The authors conclude that this feature is not
first and then aggressively decreases the window. For packet
needed after extensive testing due to the increased stability
losses, FAST halves the congestion window and enters loss
of CUBIC. CUBIC replaced BIC-TCP as the default TCP
recovery just like TCP.
algorithm in 2006 after version 2.6.18. The changes and
upgrades of CUBIC in Linux are documented in Table 1.
TCP-Westwood [14] estimates an end-to-end available band-
width by accounting the rate of returning ACKs. For packet
losses, unlike TCP which “blindly” reduces the congestion
window to the half, TCP-Westwood sets the slow start thresh-
old to this estimate. This mechanism is effective especially
over wireless links where frequent channel losses are mis-
interpreted as congestion losses and thus TCP reduces the
congestion window unnecessarily.

TCP-Illinois [26] uses a queueing delay to determine an in-

crease factor α and multiplicative decrease factor β instan-
taneously during the window increment phase. Precisely, (a) BIC-TCP window growth function.
TCP-Illinois sets a large α and small β when the average
delay d is small, which is the indication that congestion is
not imminent, and sets a small α and large β when d is large
because of imminent congestion.

TCP-Hybla [13] scales the window increment rule to ensure

fairness among the flows with different RTTs. TCP-Hybla
behaves as TCP-NewReno when the RTT of a flow is less
than a certain reference RTT (e.g., 20ms). Otherwise, TCP-
Hybla increases the congestion window size more aggres- (b) CUBIC window growth function.
sively to compensate throughput drop due to RTT increase.
Figure 1: Window growth functions of BIC-TCP
TCP-Veno [17] determines the congestion window size very and CUBIC.
similar to TCP-NewReno, but it uses the delay information
of TCP-Vegas to differentiate non-congestion losses. When
packet loss happens, if the queue size inferred by the delay new maximum must be found. BIC-TCP enters a new phase
increase is within a certain threshold, which is the strong called “max probing”. Max probing uses a window growth
indication of random loss, TCP-Veno reduces the congestion function exactly symmetric to those used in additive increase
window by 20%, not by 50%. and binary search (which is logarithmic; its reciprocal will
be exponential) and then additive increase. Figure 1 (a)
3. CUBIC CONGESTION CONTROL shows the growth function during max probing. During max
3.1 BIC-TCP probing, the window grows slowly initially to find the new
In this section, we give some details on BIC-TCP which is a maximum nearby, and after some time of slow growth, if it
predecessor of CUBIC. The main feature of BIC-TCP is its does not find the new maximum (i.e., packet losses), then
unique window growth function as discussed in the introduc- it guesses the new maximum is further away so it switches
tion. Figure 1 shows the growth function of BIC-TCP. When to a faster increase by switching to additive increase where
it gets a packet loss event, BIC-TCP reduces its window by the window size is incremented by a large fixed increment.
a multiplicative factor β. The window size just before the The good performance of BIC-TCP comes from the slow
reduction is set to the maximum Wmax and the window size increase around Wmax and linear increase during additive
just after the reduction is set to the minimum Wmin . Then, increase and max probing.
BIC-TCP performs a binary search using these two param-
eters - by jumping to the “midpoint” between Wmax and 3.2 CUBIC window growth function
Wmin . Since packet losses have occurred at Wmax , the win- BIC-TCP achieves good scalability in high speed networks,
dow size that the network can currently handle without loss fairness among competing flows of its own and stability with
must be somewhere between these two numbers. low window oscillations. However, BIC-TCP’s growth func-
tion can still be too aggressive for TCP, especially under
However, jumping to the midpoint could be too much in- short RTT or low speed networks. Furthermore, the several
crease within one RTT, so if the distance between the mid- different phases (binary search increase, max probing, Smax
point and the current minimum is larger than a fixed con- and Smin ) of window control add complexity in implement-
stant, called Smax , BIC-TCP increments cwnd by Smax (lin- ing the protocol and analyzing its performance. We have
ear increase). If BIC-TCP does not get packet losses at the been searching for a new window growth function that while
updated window size, that window size becomes the new retaining strengths of BIC-TCP (especially, its stability and
minimum. This process continues until the window incre- scalability), simplifies the window control and enhances its
ment is less than some small constant called Smin at which TCP friendliness.
point, the window is set to the current maximum. So the
growth function after a window reduction will be most likely We introduce a new high-speed TCP variant: CUBIC. As
to be a linear one followed by a logarithmic one (marked as the name of the protocol represents, the window growth
“additive increase” and “binary search” respectively in Fig- function of CUBIC is a cubic function whose shape is very
ure 1 (a).) similar to the growth function of BIC-TCP. CUBIC uses a
cubic function of the elapsed time from the last congestion
If the window grows past the maximum, the equilibrium event. While most alternative algorithms to Standard TCP
window size must be larger than the current maximum and a uses a convex increase function where after a loss event, the
window increment is always increasing, CUBIC uses both Algorithm 1: Linux CUBIC algorithm (v2.2)
the concave and convex profiles of a cubic function for win- Initialization:
dow increase. Figure 1 (b) shows the growth function of tcp f riendliness ←− 1, β ←− 0.2
CUBIC. f ast convergence ←− 1, C ←− 0.4
cubic reset()
The details of CUBIC are as follows. After a window re- On each ACK:
duction following a loss event, it registers Wmax to be the begin
window size where the loss event occurred and performs a if dM in then dM in ←− min(dM in, RT T )
multiplicative decrease of congestion window by a factor of else dM in ←− RT T
β where β is a window decrease constant and the regular fast if cwnd ≤ ssthresh then cwnd ←− cwnd + 1
recovery and retransmit of TCP. After it enters into conges- else
tion avoidance from fast recovery, it starts to increase the cnt ←− cubic update()
window using the concave profile of the cubic function. The if cwnd cnt > cnt then
cubic function is set to have its plateau at Wmax so the con- cwnd ←− cwnd + 1, cwnd cnt ←− 0
cave growth continues until the window size becomes Wmax .
After that, the cubic function turns into a convex profile and else cwnd cnt ←− cwnd cnt + 1
the convex window growth begins. This style of window ad- end
justment (concave and then convex) improves protocol and Packet loss:
network stability while maintaining high network utiliza- begin
tion [12]. This is because the window size remains almost epoch start ←− 0
constant, forming a plateau around Wmax where network if cwnd < Wlast max and f ast convergence then
utilization is deemed highest and under steady state, most Wlast max ←− cwnd ∗ (2−β) ........................... (3.7)
2
window size samples of CUBIC are close to Wmax , thus pro-
moting high network utilization and protocol stability. Note else Wlast max ←− cwnd
that protocols with convex growth functions tend to have ssthresh ←− cwnd ←− cwnd ∗ (1 − β) ................. (3.6)
the largest window increment around the saturation point, end
introducing a large burst of packet losses. Timeout:
begin
The window growth function of CUBIC uses the following cubic reset()
function: end
W (t) = C(t − K)3 + Wmax (1) cubic update(): .......................................................... (3.2)
begin
where C is a CUBIC parameter, t is the elapsed time from ack cnt ←− ack cnt + 1
the last window reduction, and K is the time period that the if epoch start ≤ 0 then
above function takes to increase W to Wmax when there is epoch start ←− tcp time stamp
no further loss event and is calculated by using the following if cwnd < q Wlast max then
equation:
r K ←− 3 Wlast max
C
−cwnd

3 Wmax β origin point ←− Wlast max

K= (2)
C else
K ←− 0
Upon receiving an ACK during congestion avoidance, CU- origin point ←− cwnd
BIC computes the window growth rate during the next RTT ack cnt ←− 1
period using Eq. (1). It sets W (t + RT T ) as the candidate Wtcp ←− cwnd
target value of congestion window. Suppose that the cur- t ←− tcp time stamp + dM in − epoch start
rent window size is cwnd. Depending on the value of cwnd, target ←− origin point + C(t − K)3
CUBIC runs in three different modes. First, if cwnd is less if target > cwnd then cnt ←− target−cwnd cwnd
.. (3.4,3.5)
than the window size that (standard) TCP would reach at else cnt ←− 100 ∗ cwnd
time t after the last loss event, then CUBIC is in the TCP if tcp f riendliness then cubic tcp f riendliness()
mode (we describe below how to determine this window size
of standard TCP in term of time t). Otherwise, if cwnd end
is less than Wmax , then CUBIC is in the concave region, cubic tcp f riendliness(): .......................................... (3.3)
and if cwnd is larger than Wmax , CUBIC is in the convex begin
3β
region. Algorithm 1 shows the pseudo-code of the window Wtcp ←− Wtcp + 2−β ∗ ackcwnd
cnt

adjustment algorithm of CUBIC implemented in Linux. ack cnt ←− 0

if Wtcp > cwnd then
cwnd
max cnt ←− Wtcp
3.3 TCP-friendly region −cwnd
if cnt > max cnt then cnt ←− max cnt
When receiving an ACK in congestion avoidance, we first
check whether the protocol is in the TCP region or not. This end
is done as follows. We can analyze the window size of TCP cubic reset():
in terms of the elapsed time t. Using a simple analysis in begin
[16], we can find the average window size of additive increase Wlast max ←− 0, epoch start ←− 0, origin point ←− 0
and multiplicative decrease (AIMD) with an additive factor dM in ←− 0, Wtcp ←− 0, K ←− 0, ack cnt ←− 0
end
α and a multiplicative factor β to be the following function: With fast convergence, when a loss event occurs, before a
s window reduction of the congestion window, the protocol
1 α2−β 1 remembers the last value of Wmax before it updates Wmax
(3)
RT T 2 β p for the current loss event. Let us call the last value of Wmax
to be Wlast max . At a loss event, if the current value of
By the same analysis, the average
q window size of TCP with Wmax is less than the last value of it, Wlast max , this in-
α = 1 and β = 0.5 is RT1 T 32 p1 . Thus, for Eq. 3 to be dicates that the saturation point experienced by this flow
the same as that of TCP, α must be equal to 2−β 3β
. If TCP is getting reduced because of the change in available band-
increases its window by α per RTT, we can get the window width. Then we allow this flow to release more bandwidth
size of TCP in terms of the elapsed time t as follows: by reducing Wmax further. This action effectively lengthens
the time for this flow to increase its window because the re-
β t duced Wmax forces the flow to have the plateau earlier. This
Wtcp(t) = Wmax (1 − β) + 3 (4)
2 − β RT T allows more time for the new flow to catch up its window
size. The pseudo code for this operation is shown at (3.7)
If cwnd is less than Wtcp(t) , then the protocol is in the TCP in Algorithm 1.
mode and cwnd is set to Wtcp(t) at each reception of ACK.
The cubic tcp friendliness() in Algorithm 1 describes 4. CUBIC IN LINUX KERNEL
this behavior. Since the first release of CUBIC to the Linux community
in 2006, CUBIC has gone through several upgrades. This
3.4 Concave region section documents those changes.
When receiving an ACK in congestion avoidance, if the pro-
tocol is not in the TCP mode and cwnd is less than Wmax ,
then the protocol is in the concave region. In this region,
4.1 Evolution of CUBIC in Linux
Table 1 summarizes important updates [1] on the implemen-
cwnd is incremented by W (t+RT T )−cwnd
cwnd
, which is shown at tation of CUBIC in Linux since its first introduction in Linux
(3.4) in Algorithm 1. 2.6.13. The most updates on CUBIC are focussed on per-
formance and implementation efficiency improvements. One
3.5 Convex region of notable optimizations is the improvement on cubic root
When the window size of CUBIC is larger than Wmax , it calculation. The implementation of CUBIC requires solving
passes the plateau of the cubic function after which CU- Eq. 2, a cubic root calculation. The initial implementation
BIC follows the convex profile of the cubic function. Since of CUBIC [18] in Linux uses the bisection method. But
cwnd is larger than the previous saturation point Wmax , the Linux developer community worked together to replace
this indicates that the network conditions might have been it with the Newton-Rhaphson method which improves the
perturbed since the last loss event, possibly implying more running time by more than 10 times on average (1032 clocks
available bandwidth after some flow departures. Since the vs. 79 clocks) and reduces the variance in running times.
Internet is highly asynchronous, fluctuations in available CUBIC also went through several algorithmic changes to
bandwidth always exist. The convex profile ensures that the have its current form to enhance its scalability, fairness and
window increases very slowly at the beginning and gradu- convergence speed.
ally increases its growth rate. We also call this phase as the
maximum probing phase since CUBIC is searching for a new
Wmax . As we do not modify the window increase function
4.2 Pluggable Congestion Module
only for the convex region, the window growth function for More inclusions of TCP variants to the Linux kernel has
both regions remains unchanged. To be exact, if the pro- substantially increased the complexity of the TCP code in
tocol is the convex region outside the TCP mode, cwnd is the kernel. Even though a new TCP algorithm comes with a
patch for the kernel, this process requires frequent kernel re-
incremented by W (t+RT T )−cwnd
, which is shown at (3.5) in
cwnd compilations and exacerbates the stability of the TCP code.
Algorithm 1.
To eliminate the need of kernel recompilation and help ex-
perimenting with a new TCP algorithm with Linux, Stephen
3.6 Multiplicative decrease Hemminger introduces a new architecture [23, 6], called
When a packet loss occurs, CUBIC reduces its window size pluggable congestion module, in Linux 2.6.13. It is dynami-
by a factor of β. We set β to 0.2. A side effect of setting β to cally loadable and allows switching between different conges-
a smaller value than 0.5 is slower convergence. We believe tion control algorithm modules on the fly without recompi-
that while a more adaptive setting of β could result in faster lation. Figure 2 shows the interface to this module, named
convergence, it will make the analysis of the protocol much tcp congestion ops. Each method in tcp congestion ops is
harder and also affects the stability of the protocol. This a hook in the TCP code that provides access to the TCP
adaptive adjustment of β is a future research issue. code. A new congestion control algorithm requires to define
cong avoid and ssthresh, but the other methods are optional.
3.7 Fast Convergence
To improve the convergence speed of CUBIC, we add a The init and release functions are called for the initializa-
heuristic in the protocol. When a new flow joins the net- tion and termination of a given TCP algorithm. ssthresh is
work, existing flows in the network need to give up their the slow start threshold which is called when the given TCP
bandwidth shares to allow the new flow some room for growth. detects a loss. The lower bound on congestion window is
To increase this release of bandwidth by existing flows, we the slow start threshold, but when congestion control needs
add the following mechanism called fast convergence. to override this lower bound, min cwnd can be used for that
 struct tcp_congestion_ops { 4. bictcp set state: resets all the variables when a timeout
.. happens.
void (*init)(struct sock *sk);
void (*release)(struct sock *sk); 5. bictcp undo cwnd: returns the maximum between the
u32 (*ssthresh)(struct sock *sk); current cwnd value and the last max (which is the con-
u32 (*min_cwnd)(const struct sock *sk); gestion window before the drop).
void (*cong_avoid)(struct sock *sk, u32 ack,
u32 in_flight); 6. bictcp acked: maintains the minimum delay observed
void (*set_state)(struct sock *sk, u8 new_state);
so far. The minimum delay is reset when a timeout
void (*cwnd_event)(struct sock *sk,
enum tcp_ca_event ev); happens.
u32 (*undo_cwnd)(struct sock *sk);
void (*pkts_acked)(struct sock *sk, u32 num_acked, 5. DISCUSSION
s32 rtt_us);
With a deterministic loss model where the number of packets
void (*get_info)(struct sock *sk, u32 ext,
struct sk_buff *skb); between two successive loss events is always p1 , CUBIC al-
char name[TCP_CA_NAME_MAX]; ways 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:
Figure 2: tcp congestion ops structure s
C(4 − β) RT T 3
E{Wcubic } = 4 ( ) (5)
4β p
purpose. cong avoid is called whenever an ACK arrives and
the congestion window (cwnd) is adjusted. For instance, in
To ensure fairness to Standard TCP based on our argument
standard TCP New-Reno, when an ACK arrives, cong avoid in the introduction, we set C to 0.4. We find that this
increments cwnd by one if the current cwnd is less than value of C allows the size of the TCP friendly region to be
ssthresh (during slow start). Otherwise, cong avoid incre- large enough to encompass most of the environments where
1
ments cwnd by cwnd (during congestion avoidance). set state Standard TCP performs well while preserving the scalability
is called when the congestion control state of TCP is changed
of the window growth function. With β set to 0.2, the above
among Normal, Loss Recovery, Loss Recovery after Time-
formula is reduced to the following function:
out, Reordering, and Congestion Window Reduction. cwnd event r
is called when the events defined in tcp ca event occur. When RT T 3
an algorithm requires to handle one of the events, it can E{Wcubic } = 1.17 4 ( ) (6)
p
create a hook to cwnd event which is called when the cor-
responding event occurs. undo cwnd handles false detection
of loss or timeout. When TCP realizes the change to cwnd (6) is used to argue the fairness of CUBIC to Standard TCP
is wrong, it falls back to the original cwnd using undo cwnd. and its safety for deployment below.
pkts acked is a hook for counting ACKs; many protocols
(e.g., BIC-TCP, CUBIC, and H-TCP) also use this hook 5.1 Fairness to standard TCP
to get RTT information. get info is a hook for providing In environments where standard TCP is able to make rea-
congestion control information to the user space. sonable use of the available bandwidth, CUBIC does not
significantly change this state.
CUBIC has been implemented as one of pluggable conges-
tion control modules. The followings are the hooks that Standard TCP performs well in the following two types of
CUBIC use for its implementation [3]. networks:

1. networks with a small bandwidth-delay product (BDP).

1. bictcp init: initializes private variables used for CU- 2. networks with a short RTT, but not necessarily a small
BIC algorithm. If initial ssthresh is not 0, then set BDP.
ssthresh to this value. If initial ssthresh is properly set
by users when there is no history information about CUBIC is designed to behave very similarly to standard
the end-to-end path, it can improve the start-up be- TCP in the above two types of networks. Figure 3 shows the
havior of CUBIC significantly. response function (average window size) of standard TCP,
HSTCP, and CUBIC. The average window size of standard
2. bictcp recalc ssthresh: If the fast convergence mode TCP and HSTCP is from [15]. The average window size of
is turned on and the current cwnd is smaller than CUBIC is calculated by using (6) and CUBIC TCP-friendly
last max, set last max to cwnd ∗ (1 − β2 ). Otherwise, equation in (4). Figure 3 shows that CUBIC is more friendly
set last max to cwnd ∗ (1 − β). ssthresh is always set to TCP than HSTCP, especially in networks with a short
to cwnd ∗ (1 − β) because TCP needs to back off for RTT where TCP performs reasonably well. For example,
congestion. in a network with RTT = 10ms and p = 10−6 , TCP has
an average window of 1200 packets. If the packet size is
3. bictcp cong avoid: increases cwnd by computing the 1500 bytes, then TCP can achieve an average rate of 1.44
difference between the current cwnd value and its ex- Gbps. In this case, CUBIC achieves exactly the same rate
pected value of the next RTT round which is obtained as Standard TCP, whereas HSTCP is about ten times more
by cubic root calculation. aggressive than Standard TCP.
 1e+06 18000
Standard TCP Fast Convergence
HSTCP 16000
CUBIC
100000 14000
Avg. Window Size (packets)

12000

(packets)
10000 Concave Growth
10000
8000
6000 Convex Growth
1000
4000
2000 Multiplicative DecreaseCUBIC flow1
100 CUBIC flow2
0
0 100 200 300 400 500 600
Time (second)
10
1e-08 1e-07 1e-06 1e-05 0.0001 0.001 0.01 0.1 (a) CUBIC window curves.
Random Loss Rate (packets)
400
(a) Networks with 10ms RTT. 350
1e+06
Standard TCP 300
HSTCP
CUBIC 250

(Mbps)
100000
Avg. Window Size (packets)

200

150
10000
100

50 CUBIC flow1
1000 CUBIC flow2
0
0 100 200 300 400 500 600
100 Time (second)

(b) Throughput of two CUBIC flows.

10
1e-08 1e-07 1e-06 1e-05 0.0001 0.001 0.01 0.1 Figure 4: Two CUBIC flows with 246ms RTT.
Random Loss Rate (packets)

(b) Networks with 100ms RTT.

work where CUBIC is indistinguishable with TCP-SACK.
Figure 3: Response function of standard TCP,
HSTCP, and CUBIC in networks with 10ms (a) and Figure 6 shows the experiment with four TCP-SACK flows
100ms (b) RTTs respectively. and four CUBIC flows. For this experiment, we set the
bandwidth to 400Mbps, RTT to 40ms, and buffer size to
100% BDP of a flow. We observe that four flows of CUBIC
converge to a fair share nicely within a short period of time.
5.2 CUBIC in action Their cwnd curves are very smooth and do not cause much
Figure 4 shows the window curve of CUBIC over the running disturbance to competing TCP flows. In this experiment,
time. This graph is obtained by running testbed experiment the total network utilization is around 95%: the four CUBIC
on a dumbbell network configuration with significant back- flows take about 72% of the total bandwidth, the four TCP
ground traffic in both directions. The bottleneck capacity is flows take 23%.
400Mbps and the RTT is set to 240ms. Drop tail routers are
used. There are two CUBIC flows, and they have the same
RTT and bottleneck. Note that the curves have plateaus 6. EXPERIMENTAL EVALUATION
around Wmax which is the window size at the time of the 6.1 Experimental Setup
last packet loss event. We observe that two flows use all We construct a dumbbell topology shown in Figure 7 where
phases of CUBIC functions over the running time and two two dummynet routers are located at the bottleneck between
flows converges to a fair share within 200 seconds. two end points. Each end points consists of a set of Dell
Linux servers dedicated to high-speed TCP variant flows and
Figure 5 shows the friendliness of CUBIC with respect to background traffic. Background traffic is generated by us-
TCP-SACK. In this experiment, we run one CUBIC flow ing a modification of a web-traffic generator, called Surge [9]
with one TCP-SACK flow over a short-RTT network path and Iperf [2]. We modified Surge to generate a wider range
(8ms) and a long-RTT network path (82ms), respectively. of flow sizes in order to increase variability in cross traffic
Under the short-RTT (8ms) network where even TCP-SACK because medium size flows tend to fully execute the slow
can use the full bandwidth of the path, CUBIC operates in start and increase the variability in available bandwidth.
the TCP-friendly mode. Figure 5 (a) confirms that one CU- The RTT of each background traffic is randomly selected
BIC flow runs in the TCP-friendly mode and shares the from an exponential distribution found in [7]. The socket
bandwidth fair with the other TCP-SACK flow by main- buffer size of background traffic machines is fixed to de-
taining the congestion window of CUBIC similar with that fault 64KB while high-speed TCP machines are configured
of TCP-SACK. Under the long-RTT (82ms) network where to have a very large buffer so that the transmission rates
Standard TCP has the under-utilization problem, CUBIC of high-speed flows are only limited by the congestion con-
uses a cubic function to be scalable for this environment. trol algorithm. Two dummynet routers and four high-speed
Figure 5 (b) confirms that the CUBIC flow runs a cubic win- TCP machines are tuned to generate or forward traffic close
dow growth function unlike the case with the short-RTT net- to 1Gbps. The details of system tuning for both Linux and
 500
TCP-SACK
450 CUBIC
400
350
(packets)

300 TCP-Friendly Region

250
200
150
100
50
0 100 200 300 400 500 600
Time (second)

(a) RTT 8ms.

6000
TCP-SACK
CUBIC
5000
Figure 7: Testbed
4000
(packets)

3000
tocols. Figure 8 (a) and 8 (b) show the intra-protocol fair-
2000 ness and link utilization for the tested protocols. CUBIC
1000
and BIC-TCP show higher fairness index than TCP-SACK
and HSTCP, representing better fair sharing between the
0 flows. With 16ms RTT, TCP-SACK shows the best fairness
0 100 200 300 400 500 600
Time (second) index indicating that Standard TCP works fairly well un-
(b) RTT 82ms. der small RTT networks. CUBIC, BIC-TCP, and HSTCP
utilize the link regardless of RTTs while TCP-SACK suffers
Figure 5: One CUBIC flow and one TCP-SACK under-utilization with larger RTTs.
flow. Bandwidth is set to 400Mbps.
6.3 Inter-RTT Fairness
2500
TCP-SACK flow1
We measure the fairness in sharing the bottleneck band-
TCP-SACK flow2 width between two competing flows that have different RTTs.
TCP-SACK flow3
2000 TCP-SACK flow3 For this experiment, we fix RTT of one flow to 162ms and
CUBIC flow1
CUBIC flow2 vary RTT of the other flow between 16ms and 164ms. This
1500 CUBIC flow3
(packets)

CUBIC flow4 setting gives us the RTT ratio up to 10. We test CU-
1000
BIC, BIC-TCP, HSTCP, and TCP-SACK protocols. Fig-
ure 9 (a) shows that TCP-SACK achieves RTT fairness lin-
500 early proportional to the inverse of the RTT ratio, which
means that the short RTT flow has proportionally more
0 bandwidth shares than the longer RTT flow. Even though
0 100 200 300 400 500 600
Time (second)
there is no commonly accepted notion of RTT-fairness, we
think the proportional fairness of TCP-SACK is desirable
because long RTT flows tend to use more resources along
Figure 6: Four TCP-SACK flows and four CUBIC
the longer path than short RTT flows. But some of high-
flows over 40ms RTT
speed protocols are desiged to provide an equal bandwidth
sharing among the flows with different RTTs (e.g., H-TCP
FreeBSD systems are shown in [5]. Note that Netem [22] in and FAST). Based on this notion of RTT fairness, if the
Linux provides the same functionality with the dummynet RTT fairness of a protocol has a similar slope with TCP-
software in FreeBSD. For this experiment, the maximum SACK, we can say the protocol is “acceptable”. Figure 9
bandwidth of the bottleneck router is set to 400Mbps. The (a) confirms that CUBIC has a similar slope with TCP-
bottleneck buffer size is set to 100% BDP if it is not explic- SACK but with a higher fairness ratio indicating better
itly specified. The amount of background traffic comparable share of resources (bandwidth) while HSTCP fails in achiev-
to around 15% of the bottleneck bandwidth is pushed into ing a similar slope. Even though BIC-TCP shows the simi-
forward and backward directions of the dumbbell. We use lar slope with TCP-SACK, it shows the lowest fairness ra-
the drop-tail router at the bottleneck. tios among tested protocols. This is what CUBIC improves
over BIC-TCP for RTT-fairness. We also observe that even
6.2 Intra-Protocol Fairness though two HSTCP flows fully utilize the link regardless of
We measure the intra-protocol fairness between two flows their RTT ratio (See Figure 9 (b)), the slow convergence of
of a protocol with the same RTT. We use a throughput HSTCP flows hinders even two flows of the same RTT from
ratio between these two flows for representing the intra- reaching to a fair share within a reasonable amount of time.
protocol fairness. This metric represents a degree of band-
width shares between two flows of the same protocol. For 6.4 Impact on standard TCP traffic
this experiment, we vary RTTs between 16ms and 324ms As many new high-speed TCP protocols modify the win-
and test CUBIC, BIC-TCP, HSTCP, and TCP-SACK pro- dow growth function of TCP in a more scalable fashion,
 1 1

0.9
0.8
Throughput Ratio

Throughput Ratio
0.8
0.6
0.7
0.4
0.6
TCP-SACK 0.2 TCP-SACK
0.5 HSTCP HSTCP
BIC-TCP BIC-TCP
CUBIC CUBIC
0.4 0
0 50 100 150 200 250 300 350 0 20 40 60 80 100 120 140 160 180
RTT (ms) RTT (ms)

(a) Intra-Protocol Fairness. (a) Inter-RTT Fairness.

100 100

90 90

80 80
Link Utilization

Link Utilization
70 70

60 60
TCP-SACK TCP-SACK
50 HSTCP 50 HSTCP
BIC-TCP BIC-TCP
CUBIC CUBIC
40 40
0 50 100 150 200 250 300 350 0 20 40 60 80 100 120 140 160 180
RTT (ms) RTT (ms)

(b) Link Utilization. (b) Link Utilization.

Figure 8: Intra-protocol fairness (a) and link uti- Figure 9: Inter-RTT fairness. The bottleneck band-
lization (b). The bottleneck bandwidth is set to width is set to 400Mbps and 2Mbyte buffer is used.
400Mbps and 2Mbyte bottleneck buffer is used. One flow has a fixed RTT of 162ms and the other
RTT is varied between 16ms and 324ms and two flow varies its RTT from 16ms to 162ms.
flows have the same RTT.

the tested high-speed protocols grab more bandwidth share

these new protocols tend to affect the performance of Stan- from TCP-SACK as RTT increases. Also we confirm that
dard TCP flows which share the same bottleneck link along CUBIC gives more room to TCP-SACK than BIC-TCP and
the path. As being fair to Standard TCP is critical to the HSTCP for whole range of tested RTTs while achieving full
safety of the protocol, we need to make sure that the window utilization of the path. This is one of the design objective of
growth function of a new protocol does not unfairly affect CUBIC that it operates like BIC-TCP and be nice to other
the Standard TCP flows. flows in the network. As RTT increases, CUBIC, BIC-TCP
and HSTCP steal more bandwidth from TCP-SACK. Some
In this experiment, we measure how much these high-speed amount of bandwidth they steal is from the amount of band-
protocols steal the bandwidth from competing TCP-SACK width that TCP-SACK doesn’t utilize.
flows. By following the scenarios shown in the recent eval-
uation proposal [8], we first measure the throughput shares Figure 10 (b) and 10 (c) show the performance results re-
of four TCP-SACK flows when they are competing with garding the TCP friendliness over short-RTT networks (10ms
the other four TCP-SACK flows. After that, we replace RTT) and long-RTT networks (100ms RTT), respectively.
four flows with a new protocol. We measure the share of According to [15], under high loss rate regions (small-RTT
TCP-SACK flows and the other four TCP variant flows at networks) where TCP is well-behaving, the protocol must
each run and report only the accumulated average of their behave like TCP, and under low loss rate regions (large-
bandwidth shares. We test CUBIC, BIC-TCP, HSTCP, and RTT networks) where TCP has a low utilization problem,
TCP-SACK. it can use more bandwidth than TCP. As shown in Fig-
ure 10 (b), with 10ms RTT, we can see that TCP-SACK
Figure 10 (a) shows the relationship between RTT and the still uses the full bandwidth. In this region, all high-speed
throughput share between a new protocol flows and TCP- protocols need to be friendly to TCP-SACK by following the
SACK flows. We fix the bottleneck bandwidth to 400Mbps arguments above. Interestingly, CUBIC behaves more TCP-
and vary RTT between 10ms and 160ms. Clearly, TCP- friendly even comparing to TCP-SACK for certain band-
SACK flows do not fully utilize the bottleneck bandwidth widths. Rather than stealing the bandwidth from TCP-
as RTT increases due to its slow window growth function. SACK flows, CUBIC flows employs a window growth func-
With 400Mbps and 160ms RTT, 8 TCP-SACK flows achieve tion that is comparable to TCP-SACK, so that competing
around 80% of the link bandwidth, but the underutilization TCP-SACK flows have the same chance with CUBIC flows
will be very serious for larger BDP path and with small num- for grabbing the bandwidth shares. However, BIC-TCP and
ber of flows. CUBIC, BIC-TCP, and HSTCP fully utilize the HSTCP show a tendency to operate in a scalable mode
link, thanks to their scalable window growth functions. All (being more aggressive) as the link speed increases. Even
though the graph doesn’t show the results corresponding to 450 SACK
SACK

the link speed beyond 400Mbps, it is obvious that a scalable 400

HSTCP
BIC-TCP
CUBIC
mode of BIC-TCP and HSTCP will deprive most of band-
350
width share of TCP-SACK. As most high-speed TCP pro-
tocols including BIC-TCP and HSTCP achieve TCP friend- 300

Throughput (Mbps)
liness by having some form of “TCP modes” during which 250

they behave in the same way as TCP. BIC-TCP and HSTCP 200

enter their TCP mode when the window size is less than 150

14 and 38 packets, respectively. Therefore, even with 1ms 100

RTT, if BDP is larger than 38 packets, HSTCP will operate
50
in a scalable mode. This is the limitation when the protocol
uses a fixed cutoff for detecting a TCP-friendly region. CU- 0
10 20 40 80 160
RTT (ms)
BIC defines a TCP-friendly region in real-time; therefore,
CUBIC doesn’t have this scalability problem. (a) Bandwidth 400Mbps with varying RTT
120
SACK
SACK
HSTCP
Figure 10 (c) shows the results with 100ms RTT. All four 100
BIC-TCP
CUBIC

protocols show reasonable friendliness to TCP. As the band-

width gets larger than 10Mbps, the throughput ratio drops 80

quite rapidly. As CUBIC, like BIC-TCP and HSTCP, re-

Link Utilization (%)

gards this operating region is out of TCP-friendly region 60

and behaves to be scalable to this environment. CUBIC

and BIC-TCP show a similar aggressiveness which is slightly 40

more aggressive† than HSTCP especially for the bandwidth

less than 100Mbps. Through an extensive testing [4], we 20

confirm that this doesn’t highly impact on the performance

0
of TCP-SACK. 10 50 100 200 400
Link Speed (Mbps)

(b) RTT 10ms with varying bandwidth

7. CONCLUSION 120
SACK

We propose a new TCP variant, called CUBIC, for fast SACK

HSTCP
BIC-TCP
and long distance networks. CUBIC is an enhanced ver- 100 CUBIC

sion of BIC-TCP. It simplifies the BIC-TCP window control

and improves its TCP-friendliness and RTT-fairness. CU- 80
Link Utilization (%)

BIC uses a cubic increase function in terms of the elapsed

60
time since the last loss event. In order to provide fairness
to Standard TCP, CUBIC also behaves like Standard TCP 40
when the cubic window growth function is slower than Stan-
dard TCP. Furthermore, the real-time nature of the pro- 20

tocol keeps the window growth rate independent of RTT,

which keeps the protocol TCP friendly under both short 0
10 50 100 200 400
and long RTT paths. We show the details of Linux CUBIC Link Speed (Mbps)

algorithm and implementation. Through extensive testing, (c) RTT 100ms with varying bandwidth
we confirm that CUBIC tackles the shortcomings of BIC-
TCP and achieves fairly good Intra-protocol fairness, RTT- Figure 10: Impact on standard TCP traffic.
fairness and TCP-friendliness.

[5] Testing setup for Linux and FreeBSD.

8. REFERENCES http://netsrv.csc.ncsu.edu/wiki/index.php/
[1] Git logs for CUBIC updates. Testing Setup of kernel 2.6.23.9 .
http://git.kernel.org/?p=linux/kernel/git/davem/net-
2.6.git;a=history;f=net/ipv4/tcp cubic.c; [6] Pluggable congestion avoidance modules.
h=eb5b9854c8c7330791ada69b8c9e8695f7a73f3d;hb=HEAD. http://lwn.net/Articles/128681/ (2005).

[2] Iperf. http://sourceforge.net/projects/iperf . [7] Aikat, J., Kaur, J., Smith, F., and Jeffay, K.
Variability in TCP round-trip times. In Proceedings of the
[3] Linux CUBIC source navigation. ACM SIGCOMM Internet Measurement Conference
http://lxr.linux.no/linux/net/ipv4/tcp cubic.c. (Miami, FL, October 2003).
[4] TCP Testing Wiki. [8] Andrew, L., Marcondes, C., Floyd, S., Dunn, L.,
http://netsrv.csc.ncsu.edu/wiki/index.php/TCP Testing. Guillier, R., Gang, W., Eggert, L., Ha, S., and Rhee,
†
I. Towards a common TCP evaluation suite. In Proceedings
We used the latest update of CUBIC (v2.2) which improved of the fourth PFLDNet Workshop (UK, March 2008).
the scalability and convergence speed of the protocol, which
doesn’t clamp the increment in both convex and cocave re- [9] Barford, P., and Crovella, M. Generating
gions. A slight increase of aggressivenss is the trade-off be- representative web workloads for network and server
tween scalability and TCP-friendlines. Our extensive testing performance evaluation. In Measurement and Modeling of
confirms that CUBIC has better scalability and convergence Computer Systems (1998), pp. 151–160.
speed with this small change (trade-off) while obtaining rea- [10] Brakmo, L., and Peterson, L. TCP vegas: End to end
sonable TCP-friendliness. congestion avoidance on a global internet. IEEE Journal of
 Selected Areas in Communications (October 1995).
[11] Bullot, H., Cottrell, R. L., and Hughes-Jones, R.
Evaluation of advanced TCP stacks on fast long-distance
production networks. In Proceedings of the third PFLDNet
Workshop (Illinois, February 2004). Version Kernel Updates
[12] Cai, H., Eun, D., Ha, S., Rhee, I., and Xu, L. Stochastic 2.0-pre 2.6.13 The authors releases the first CUBIC
ordering for internet congestion control and its
implementation in Linux to the Linux
applications. In Proceedings of IEEE INFOCOM
(Anchorage, Alaska, May 2007). community [18].
[13] Caini, C., and Firrincieli, R. TCP hybla: a TCP 2.0 2.6.15 CUBIC is officially included in the
enhancement for heterogeneous networks. International Linux kernel.
Journal of Satellite Communication and Networking 22, 5
(September 2004), 547–566. 2.6.18 CUBIC replaces BIC-TCP as the de-
[14] Casetti, C., Gerla, M., Mascolo, S., Sanadidi, M. Y., fault TCP protocol in Linux kernel.
and Wang, R. TCP Westwood: Bandwidth estimation for 2.6.19 The original implementation of CUBIC
enhanced transport over wireless links. In Proceedings of
has a scaling bug. It has taken about
ACM Mobicom (Rome, Italy, July 2001).
a month to fix this bug since CUBIC
[15] Floyd, S. HighSpeed TCP for Large Congestion Windows.
RFC 3649 (Experimental), Dec. 2003.
replaced BIC-TCP.
[16] Floyd, S., Handley, M., and Padhye, J. A Comparison 2.6.21 Its original implementation by the au-
of Equation-Based and AIMD Congestion Control, May thors are optimized by the Linux de-
2000. veloper for better performance [20, 29].
[17] Fu, C. P., and Liew, S. C. TCP Veno: TCP Enhancement In particular, the cubic root calculation
for Transmission Over Wireless Access Networks. IEEE in CUBIC, originally implemented in
Journal of Selected Areas in Communications (Feb 2003). the bisection method, is now replaced
[18] Ha, S. Cubic v2.0-pre patch. by a Newton-Raphson method with ta-
http://netsrv.csc.ncsu.edu/twiki/pub/Main/BIC/cubic-
ble loopups for small values. This re-
kernel-2.6.13.patch.
sults in more than 10 times perfor-
[19] Hatano, T., Fukuhara, M., Shigeno, H., and Okada, K.
TCP-friendly SQRT TCP for High Speed Networks. In
mance improvement in the cubic root
Proceedings of APSITT (November 2003), pp. 455–460. calculation. On average, the bisection
[20] Hemminger, S. Cubic root benchmark code. method costs 1032 clocks while the im-
http://lkml.org/lkml/2007/3/13/331 . proved version costs only 79 clocks.
[21] Hemminger, S. Linux TCP Performance Improvements. 2.1 2.6.22 The original implementation of CU-
Linux World 2004 (2004). BIC clamped the maximum window in-
[22] Hemminger, S. Network Emulation with NetEm. Linux crement to 32 packets per RTT. This
Conf Au (2005). feature is inherited from BIC-TCP
[23] Hemminger, S. TCP infrastructure split out. (Smax ). An extensive lab testing con-
http://lwn.net/Articles/128626/ (2005). firmed that CUBIC can safely remove
[24] Jin, C., Wei, D. X., and Low, S. H. FAST TCP: this window clamping in the concave
motivation, architecture, algorithms, performance. In
Proceedings of IEEE INFOCOM (Hong Kong, March
region. This enhances the scalability of
2004). CUBIC over very large BDP network
[25] Kelly, T. Scalable TCP: Improving performance in paths. This is incorporated in CUBIC
highspeed wide area networks. ACM SIGCOMM Computer 2.1 (Linux 2.6.22).
Communication Review 33, 2 (April 2003), 83–91. 2.6.22-rc4 CUBIC improves slow start for fast
[26] Liu, S., Basar, T., and Srikant, R. TCP-Illinois: A loss start-up by removing initial ssthresh.
and delay-based congestion control algorithm for
high-speed networks. In Proceedings of VALUETOOLS 2.6.23 The use of received timestamp op-
(Pisa, Italy, October 2006). tion value from RTT calculation is
[27] Rhee, I., and Xu, L. CUBIC: A new TCP-friendly removed for preventing possible ma-
high-speed TCP variant. In Proceedings of the third licious receiver attacks that reports
PFLDNet Workshop (France, February 2005). wrong timestamps to reduce RTTs for
[28] Shorten, R. N., and Leith, D. J. H-TCP: TCP for more throughput.
high-speed and long-distance networks. In Proceedings of
the Second PFLDNet Workshop (Argonne, Illinois, 2.2 2.6.25-rc3 The window clamping during the con-
February 2004). vex growth phase is also removed. This
[29] Tarreau, W. Cubic optimization. feature allows CUBIC to improve its
http://git.kernel.org/?p=linux/kernel/git/davem/net- convergence speed while maintaining
2.6.git;a=commit;h=7e58886b45bc4a309aeaa8178ef89ff767daaf7f . its fairness and TCP friendliness.
[30] Xu, L., Harfoush, K., and Rhee, I. Binary increase
congestion control for fast long-distance networks. In
Proceedings of IEEE INFOCOM (Hong Kong, March Table 1: CUBIC version history
2004).
[31] Zhang, Y., Duffield, N., Paxson, V., and Shenker, S.
On the constancy of Internet path properties. In
Proceedings of ACM SIGCOMM Internet Measurement
Workshop (November 2001).