idnits 2.17.1
draft-ietf-tcpm-rfc8312bis-04.txt:
-(498): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(500): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== There are 25 instances of lines with non-ascii characters in the
document.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
-- The draft header indicates that this document obsoletes RFC8312, but the
abstract doesn't seem to directly say this. It does mention RFC8312
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 543 has weird spacing: '... est est...'
== Line 691 has weird spacing: '... max max...'
-- The document date (27 August 2021) is 972 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Obsolete informational reference (is this intentional?): RFC 4960
(Obsoleted by RFC 9260)
-- Obsolete informational reference (is this intentional?): RFC 8312
(Obsoleted by RFC 9438)
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 TCPM L. Xu
3 Internet-Draft UNL
4 Obsoletes: 8312 (if approved) S. Ha
5 Intended status: Standards Track Colorado
6 Expires: 28 February 2022 I. Rhee
7 Bowery
8 V. Goel
9 Apple Inc.
10 L. Eggert, Ed.
11 NetApp
12 27 August 2021
14 CUBIC for Fast and Long-Distance Networks
15 draft-ietf-tcpm-rfc8312bis-04
17 Abstract
19 CUBIC is a standard TCP congestion control algorithm that uses a
20 cubic function instead of the linear window increase function on the
21 sender side to improve scalability and stability over fast and long-
22 distance networks. CUBIC has been adopted as the default TCP
23 congestion control algorithm by the Linux, Windows, and Apple stacks.
25 This document updates the specification of CUBIC to include
26 algorithmic improvements based on these implementations and recent
27 academic work. Based on the extensive deployment experience with
28 CUBIC, it also moves the specification to the Standards Track,
29 obsoleting RFC 8312.
31 Note to Readers
33 Discussion of this draft takes place on the TCPM working group
34 mailing list (mailto:tcpm@ietf.org), which is archived at
35 https://mailarchive.ietf.org/arch/browse/tcpm/.
37 Working Group information can be found at
38 https://datatracker.ietf.org/wg/tcpm/; source code and issues list
39 for this draft can be found at https://github.com/NTAP/rfc8312bis.
41 Note to the RFC Editor
43 xml2rfc currently renders "" in the XML by surrounding the
44 corresponding text with underscores. This is highly distracting;
45 please manually remove the underscores when doing the final edits to
46 the text version of this document.
48 (There is an issue open against xml2rfc to stop doing this in the
49 future: https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/596)
51 Also, please manually change "Figure" to "Equation" for all artwork
52 with anchors beginning with "eq" - xml2rfc doesn't seem to be able to
53 do this.
55 Status of This Memo
57 This Internet-Draft is submitted in full conformance with the
58 provisions of BCP 78 and BCP 79.
60 Internet-Drafts are working documents of the Internet Engineering
61 Task Force (IETF). Note that other groups may also distribute
62 working documents as Internet-Drafts. The list of current Internet-
63 Drafts is at https://datatracker.ietf.org/drafts/current/.
65 Internet-Drafts are draft documents valid for a maximum of six months
66 and may be updated, replaced, or obsoleted by other documents at any
67 time. It is inappropriate to use Internet-Drafts as reference
68 material or to cite them other than as "work in progress."
70 This Internet-Draft will expire on 28 February 2022.
72 Copyright Notice
74 Copyright (c) 2021 IETF Trust and the persons identified as the
75 document authors. All rights reserved.
77 This document is subject to BCP 78 and the IETF Trust's Legal
78 Provisions Relating to IETF Documents (https://trustee.ietf.org/
79 license-info) in effect on the date of publication of this document.
80 Please review these documents carefully, as they describe your rights
81 and restrictions with respect to this document. Code Components
82 extracted from this document must include Simplified BSD License text
83 as described in Section 4.e of the Trust Legal Provisions and are
84 provided without warranty as described in the Simplified BSD License.
86 Table of Contents
88 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
89 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
90 3. Design Principles of CUBIC . . . . . . . . . . . . . . . . . 5
91 3.1. Principle 1 for the CUBIC Increase Function . . . . . . . 5
92 3.2. Principle 2 for AIMD Friendliness . . . . . . . . . . . . 6
93 3.3. Principle 3 for RTT Fairness . . . . . . . . . . . . . . 7
94 3.4. Principle 4 for the CUBIC Decrease Factor . . . . . . . . 7
95 4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 8
96 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
97 4.1.1. Constants of Interest . . . . . . . . . . . . . . . . 8
98 4.1.2. Variables of Interest . . . . . . . . . . . . . . . . 8
99 4.2. Window Increase Function . . . . . . . . . . . . . . . . 9
100 4.3. AIMD-Friendly Region . . . . . . . . . . . . . . . . . . 11
101 4.4. Concave Region . . . . . . . . . . . . . . . . . . . . . 12
102 4.5. Convex Region . . . . . . . . . . . . . . . . . . . . . . 13
103 4.6. Multiplicative Decrease . . . . . . . . . . . . . . . . . 13
104 4.7. Fast Convergence . . . . . . . . . . . . . . . . . . . . 14
105 4.8. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 14
106 4.9. Spurious Congestion Events . . . . . . . . . . . . . . . 15
107 4.10. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 16
108 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 16
109 5.1. Fairness to AIMD TCP . . . . . . . . . . . . . . . . . . 17
110 5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 19
111 5.3. Difficult Environments . . . . . . . . . . . . . . . . . 20
112 5.4. Investigating a Range of Environments . . . . . . . . . . 20
113 5.5. Protection against Congestion Collapse . . . . . . . . . 21
114 5.6. Fairness within the Alternative Congestion Control
115 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 21
116 5.7. Performance with Misbehaving Nodes and Outside
117 Attackers . . . . . . . . . . . . . . . . . . . . . . . 21
118 5.8. Behavior for Application-Limited Flows . . . . . . . . . 21
119 5.9. Responses to Sudden or Transient Events . . . . . . . . . 21
120 5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 21
121 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
122 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
123 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
124 8.1. Normative References . . . . . . . . . . . . . . . . . . 22
125 8.2. Informative References . . . . . . . . . . . . . . . . . 23
126 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 25
127 Appendix B. Evolution of CUBIC . . . . . . . . . . . . . . . . . 25
128 B.1. Since draft-ietf-tcpm-rfc8312bis-03 . . . . . . . . . . . 25
129 B.2. Since draft-ietf-tcpm-rfc8312bis-02 . . . . . . . . . . . 25
130 B.3. Since draft-ietf-tcpm-rfc8312bis-01 . . . . . . . . . . . 26
131 B.4. Since draft-ietf-tcpm-rfc8312bis-00 . . . . . . . . . . . 26
132 B.5. Since draft-eggert-tcpm-rfc8312bis-03 . . . . . . . . . . 26
133 B.6. Since draft-eggert-tcpm-rfc8312bis-02 . . . . . . . . . . 26
134 B.7. Since draft-eggert-tcpm-rfc8312bis-01 . . . . . . . . . . 26
135 B.8. Since draft-eggert-tcpm-rfc8312bis-00 . . . . . . . . . . 27
136 B.9. Since RFC8312 . . . . . . . . . . . . . . . . . . . . . . 27
137 B.10. Since the Original Paper . . . . . . . . . . . . . . . . 28
138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
140 1. Introduction
142 CUBIC has been adopted as the default TCP congestion control
143 algorithm in the Linux, Windows, and Apple stacks, and has been used
144 and deployed globally. Extensive, decade-long deployment experience
145 in vastly different Internet scenarios has convincingly demonstrated
146 that CUBIC is safe for deployment on the global Internet and delivers
147 substantial benefits over classical AIMD congestion control. It is
148 therefore to be regarded as the current standard for TCP congestion
149 control. CUBIC can also be used for other transport protocols such
150 as QUIC [RFC9000] and SCTP [RFC4960] as a default congestion
151 controller.
153 The design of CUBIC was motivated by the well-documented problem
154 classical TCP has with low utilization over fast and long-distance
155 networks [K03][RFC3649]. This problem arises from a slow increase of
156 the congestion window following a congestion event in a network with
157 a large bandwidth-delay product (BDP). [HKLRX06] indicates that this
158 problem is frequently observed even in the range of congestion window
159 sizes over several hundreds of packets. This problem is equally
160 applicable to all Reno-style TCP standards and their variants,
161 including TCP-Reno [RFC5681], TCP-NewReno [RFC6582][RFC6675], SCTP
162 [RFC4960], and TFRC [RFC5348], which use the same linear increase
163 function for window growth. We refer to all Reno-style TCP standards
164 and their variants collectively as "AIMD TCP" below because they use
165 the Additive Increase and Multiplicative Decrease algorithm (AIMD).
167 CUBIC, originally proposed in [HRX08], is a modification to the
168 congestion control algorithm of classical AIMD TCP to remedy this
169 problem. Specifically, CUBIC uses a cubic function instead of the
170 linear window increase function of AIMD TCP to improve scalability
171 and stability under fast and long-distance networks.
173 This document updates the specification of CUBIC to include
174 algorithmic improvements based on the Linux, Windows, and Apple
175 implementations and recent academic work. Based on the extensive
176 deployment experience with CUBIC, it also moves the specification to
177 the Standards Track, obsoleting [RFC8312].
179 Binary Increase Congestion Control (BIC-TCP) [XHR04], a predecessor
180 of CUBIC, was selected as the default TCP congestion control
181 algorithm by Linux in the year 2005 and had been used for several
182 years by the Internet community at large.
184 CUBIC uses a similar window increase function as BIC-TCP and is
185 designed to be less aggressive and fairer to AIMD TCP in bandwidth
186 usage than BIC-TCP while maintaining the strengths of BIC-TCP such as
187 stability, window scalability, and round-trip time (RTT) fairness.
189 In the following sections, we first briefly explain the design
190 principles of CUBIC, then provide the exact specification of CUBIC,
191 and finally discuss the safety features of CUBIC following the
192 guidelines specified in [RFC5033].
194 2. Conventions
196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
198 "OPTIONAL" in this document are to be interpreted as described in
199 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
200 capitals, as shown here.
202 3. Design Principles of CUBIC
204 CUBIC is designed according to the following design principles:
206 Principle 1: For better network utilization and stability, CUBIC
207 uses both the concave and convex profiles of a cubic function to
208 increase the congestion window size, instead of using just a
209 convex function.
211 Principle 2: To be AIMD-friendly, CUBIC is designed to behave like
212 AIMD TCP in networks with short RTTs and small bandwidth where
213 AIMD TCP performs well.
215 Principle 3: For RTT-fairness, CUBIC is designed to achieve linear
216 bandwidth sharing among flows with different RTTs.
218 Principle 4: CUBIC appropriately sets its multiplicative window
219 decrease factor in order to balance between the scalability and
220 convergence speed.
222 3.1. Principle 1 for the CUBIC Increase Function
224 For better network utilization and stability, CUBIC [HRX08] uses a
225 cubic window increase function in terms of the elapsed time from the
226 last congestion event. While most alternative congestion control
227 algorithms to AIMD TCP increase the congestion window using convex
228 functions, CUBIC uses both the concave and convex profiles of a cubic
229 function for window growth.
231 After a window reduction in response to a congestion event detected
232 by duplicate ACKs, Explicit Congestion Notification-Echo (ECN-Echo,
233 ECE) ACKs [RFC3168], TCP RACK [RFC8985] or QUIC loss detection
234 [RFC9002], CUBIC remembers the congestion window size at which it
235 received the congestion event and performs a multiplicative decrease
236 of the congestion window. When CUBIC enters into congestion
237 avoidance, it starts to increase the congestion window using the
238 concave profile of the cubic function. The cubic function is set to
239 have its plateau at the remembered congestion window size, so that
240 the concave window increase continues until then. After that, the
241 cubic function turns into a convex profile and the convex window
242 increase begins.
244 This style of window adjustment (concave and then convex) improves
245 the algorithm stability while maintaining high network utilization
246 [CEHRX07]. This is because the window size remains almost constant,
247 forming a plateau around the remembered congestion window size of the
248 last congestion event, where network utilization is deemed highest.
249 Under steady state, most window size samples of CUBIC are close to
250 that remembered congestion window size, thus promoting high network
251 utilization and stability.
253 Note that congestion control algorithms that only use convex
254 functions to increase the congestion window size have their maximum
255 increments around the remembered congestion window size of the last
256 congestion event, and thus introduce many packet bursts around the
257 saturation point of the network, likely causing frequent global loss
258 synchronizations.
260 3.2. Principle 2 for AIMD Friendliness
262 CUBIC promotes per-flow fairness to AIMD TCP. Note that AIMD TCP
263 performs well over paths with short RTTs and small bandwidths (or
264 small BDPs). There is only a scalability problem in networks with
265 long RTTs and large bandwidths (or large BDPs).
267 A congestion control algorithm designed to be friendly to AIMD TCP on
268 a per-flow basis must increase its congestion window less
269 aggressively in small BDP networks than in large BDP networks.
271 The aggressiveness of CUBIC mainly depends on the maximum window size
272 before a window reduction, which is smaller in small-BDP networks
273 than in large-BDP networks. Thus, CUBIC increases its congestion
274 window less aggressively in small-BDP networks than in large-BDP
275 networks.
277 Furthermore, in cases when the cubic function of CUBIC would increase
278 the congestion window less aggressively than AIMD TCP, CUBIC simply
279 follows the window size of AIMD TCP to ensure that CUBIC achieves at
280 least the same throughput as AIMD TCP in small-BDP networks. We call
281 this region where CUBIC behaves like AIMD TCP the "AIMD-friendly
282 region".
284 3.3. Principle 3 for RTT Fairness
286 Two CUBIC flows with different RTTs have a throughput ratio that is
287 linearly proportional to the inverse of their RTT ratio, where the
288 throughput of a flow is approximately the size of its congestion
289 window divided by its RTT.
291 Specifically, CUBIC maintains a window increase rate independent of
292 RTTs outside the AIMD-friendly region, and thus flows with different
293 RTTs have similar congestion window sizes under steady state when
294 they operate outside the AIMD-friendly region.
296 This notion of a linear throughput ratio is similar to that of AIMD
297 TCP under high statistical multiplexing where packet loss is
298 independent of individual flow rates. However, under low statistical
299 multiplexing, the throughput ratio of AIMD TCP flows with different
300 RTTs is quadratically proportional to the inverse of their RTT ratio
301 [XHR04].
303 CUBIC always ensures a linear throughput ratio independent of the
304 amount of statistical multiplexing. This is an improvement over AIMD
305 TCP. While there is no consensus on particular throughput ratios for
306 different RTT flows, we believe that over wired Internet paths, use
307 of a linear throughput ratio seems more reasonable than equal
308 throughputs (i.e., the same throughput for flows with different RTTs)
309 or a higher-order throughput ratio (e.g., a quadratical throughput
310 ratio of AIMD TCP under low statistical multiplexing environments).
312 3.4. Principle 4 for the CUBIC Decrease Factor
314 To balance between scalability and convergence speed, CUBIC sets the
315 multiplicative window decrease factor to 0.7, whereas AIMD TCP uses
316 0.5.
318 While this improves the scalability of CUBIC, a side effect of this
319 decision is slower convergence, especially under low statistical
320 multiplexing. This design choice is following the observation that
321 HighSpeed TCP (HSTCP) [RFC3649] and other approaches (e.g., [GV02])
322 made: the current Internet becomes more asynchronous with less
323 frequent loss synchronizations under high statistical multiplexing.
325 In such environments, even strict Multiplicative-Increase
326 Multiplicative-Decrease (MIMD) can converge. CUBIC flows with the
327 same RTT always converge to the same throughput independent of
328 statistical multiplexing, thus achieving intra-algorithm fairness.
329 We also find that in environments with sufficient statistical
330 multiplexing, the convergence speed of CUBIC is reasonable.
332 4. CUBIC Congestion Control
334 In this section, we discuss how the congestion window is updated
335 during the different stages of the CUBIC congestion controller.
337 4.1. Definitions
339 The unit of all window sizes in this document is segments of the
340 maximum segment size (MSS), and the unit of all times is seconds.
341 Implementations can use bytes to express window sizes, which would
342 require factoring in the maximum segment size wherever necessary and
343 replacing _segments_acked_ with the number of bytes acknowledged in
344 Figure 4.
346 4.1.1. Constants of Interest
348 β__cubic_: CUBIC multiplication decrease factor as described in
349 Section 4.6.
351 α__cubic_: CUBIC additive increase factor used in AIMD-friendly
352 region as described in Section 4.3.
354 _C_: constant that determines the aggressiveness of CUBIC in
355 competing with other congestion control algorithms in high BDP
356 networks. Please see Section 5 for more explanation on how it is
357 set. The unit for _C_ is
359 segment
360 -------
361 3
362 second
364 4.1.2. Variables of Interest
366 This section defines the variables required to implement CUBIC:
368 _RTT_: Smoothed round-trip time in seconds, calculated as described
369 in [RFC6298].
371 _cwnd_: Current congestion window in segments.
373 _ssthresh_: Current slow start threshold in segments.
375 _W_max_: Size of _cwnd_ in segments just before _cwnd_ was reduced in
376 the last congestion event when fast convergence is disabled.
377 However, if fast convergence is enabled, the size may be further
378 reduced based on the current saturation point.
380 _K_: The time period in seconds it takes to increase the congestion
381 window size at the beginning of the current congestion avoidance
382 stage to _W_max_.
384 _current_time_: Current time of the system in seconds.
386 _epoch_start_: The time in seconds at which the current congestion
387 avoidance stage started.
389 _cwnd_start_: The _cwnd_ at the beginning of the current congestion
390 avoidance stage, i.e., at time _epoch_start_.
392 W_cubic(_t_): The congestion window in segments at time _t_ in
393 seconds based on the cubic increase function, as described in
394 Section 4.2.
396 _target_: Target value of congestion window in segments after the
397 next RTT, that is, W_cubic(_t_ + _RTT_), as described in Section 4.2.
399 _W_est_: An estimate for the congestion window in segments in the
400 AIMD-friendly region, that is, an estimate for the congestion window
401 of AIMD TCP.
403 _segments_acked_: Number of MSS-sized segments acked when an ACK is
404 received. This number will be a decimal value when an ACK
405 acknowledges an amount of data that is not MSS-sized. Specifically,
406 it can be less than 1 when an ACK acknowledges a segment smaller than
407 the MSS.
409 4.2. Window Increase Function
411 CUBIC maintains the acknowledgment (ACK) clocking of AIMD TCP by
412 increasing the congestion window only at the reception of an ACK. It
413 does not make any changes to the TCP Fast Recovery and Fast
414 Retransmit algorithms [RFC6582][RFC6675].
416 During congestion avoidance, after a congestion event is detected by
417 mechanisms described in Section 3.1, CUBIC changes the window
418 increase function of AIMD TCP.
420 CUBIC uses the following window increase function:
422 3
423 W (t) = C * (t - K) + W
424 cubic max
426 Figure 1
428 where _t_ is the elapsed time in seconds from the beginning of the
429 current congestion avoidance stage, that is,
431 t = current_time - epoch
432 start
434 and where _epoch_start_ is the time at which the current congestion
435 avoidance stage starts. _K_ is the time period that the above
436 function takes to increase the congestion window size at the
437 beginning of the current congestion avoidance stage to _W_max_ if
438 there are no further congestion events and is calculated using the
439 following equation:
441 ________________
442 /W - cwnd
443 3 / max start
444 K = | / ----------------
445 |/ C
447 Figure 2
449 where _cwnd_start_ is the congestion window at the beginning of the
450 current congestion avoidance stage. For example, right after a
451 congestion event, _cwnd_start_ is equal to the new cwnd calculated as
452 described in Section 4.6.
454 Upon receiving an ACK during congestion avoidance, CUBIC computes the
455 _target_ congestion window size after the next _RTT_ using Figure 1
456 as follows, where _RTT_ is the smoothed round-trip time. The lower
457 and upper bounds below ensure that CUBIC's congestion window increase
458 rate is non-decreasing and is less than the increase rate of slow
459 start.
461 /
462 | if W (t + RTT) < cwnd
463 |cwnd cubic
464 |
465 |
466 |
467 target = < if W (t + RTT) > 1.5 * cwnd
468 |1.5 * cwnd cubic
469 |
470 |
471 |W (t + RTT)
472 | cubic otherwise
473 \
475 Depending on the value of the current congestion window size _cwnd_,
476 CUBIC runs in three different regions:
478 1. The AIMD-friendly region, which ensures that CUBIC achieves at
479 least the same throughput as AIMD TCP.
481 2. The concave region, if CUBIC is not in the AIMD-friendly region
482 and _cwnd_ is less than _W_max_.
484 3. The convex region, if CUBIC is not in the AIMD-friendly region
485 and _cwnd_ is greater than _W_max_.
487 Below, we describe the exact actions taken by CUBIC in each region.
489 4.3. AIMD-Friendly Region
491 AIMD TCP performs well in certain types of networks, for example,
492 under short RTTs and small bandwidths (or small BDPs). In these
493 networks, CUBIC remains in the AIMD-friendly region to achieve at
494 least the same throughput as AIMD TCP.
496 The AIMD-friendly region is designed according to the analysis in
497 [FHP00], which studies the performance of an AIMD algorithm with an
498 additive factor of α (segments per _RTT_) and a multiplicative factor
499 of β, denoted by AIMD(α, β). _p_ is the packet loss rate.
500 Specifically, the average congestion window size of AIMD(α, β) can be
501 calculated using Figure 3.
503 _______________
504 / α * (1 + β)
505 AVG_AIMD(α, β) = | / ---------------
506 |/ 2 * (1 - β) * p
508 Figure 3
510 By the same analysis, to achieve the same average window size as AIMD
511 TCP that uses AIMD(1, 0.5), α must be equal to,
513 1 - β
514 3 * -----
515 1 + β
517 Thus, CUBIC uses Figure 4 to estimate the window size _W_est_ in the
518 AIMD-friendly region with
519 1 - β
520 cubic
521 α = 3 * ----------
522 cubic 1 + β
523 cubic
525 which achieves the same average window size as AIMD TCP. When
526 receiving an ACK in congestion avoidance (where _cwnd_ could be
527 greater than or less than _W_max_), CUBIC checks whether W_cubic(_t_)
528 is less than _W_est_. If so, CUBIC is in the AIMD-friendly region and
529 _cwnd_ SHOULD be set to _W_est_ at each reception of an ACK.
531 _W_est_ is set equal to _cwnd_start_ at the start of the congestion
532 avoidance stage. After that, on every ACK, _W_est_ is updated using
533 Figure 4. Note that this equation is for a connection where
534 Appropriate Byte Counting (ABC) [RFC3465] is disabled. For a
535 connection with ABC enabled, this equation SHOULD be adjusted by
536 using the number of acknowledged bytes instead of acknowledged
537 segments. Also note that this equation works for connections with
538 enabled or disabled Delayed ACKs [RFC5681], as _segments_acked_ will
539 be different based on the segments actually acknowledged by an ACK.
541 segments_acked
542 W = W + α * --------------
543 est est cubic cwnd
545 Figure 4
547 Note that once _W_est_ reaches _W_max_, that is, _W_est_ >= _W_max_,
548 CUBIC needs to start probing to determine the new value of _W_max_.
549 At this point, α__cubic_ SHOULD be set to 1 to ensure that CUBIC can
550 achieve the same congestion window increment as AIMD TCP, which uses
551 AIMD(1, 0.5).
553 4.4. Concave Region
555 When receiving an ACK in congestion avoidance, if CUBIC is not in the
556 AIMD-friendly region and _cwnd_ is less than _W_max_, then CUBIC is
557 in the concave region. In this region, _cwnd_ MUST be incremented by
559 target - cwnd
560 -------------
561 cwnd
563 for each received ACK, where _target_ is calculated as described in
564 Section 4.2.
566 4.5. Convex Region
568 When receiving an ACK in congestion avoidance, if CUBIC is not in the
569 AIMD-friendly region and _cwnd_ is larger than or equal to _W_max_,
570 then CUBIC is in the convex region.
572 The convex region indicates that the network conditions might have
573 changed since the last congestion event, possibly implying more
574 available bandwidth after some flow departures. Since the Internet
575 is highly asynchronous, some amount of perturbation is always
576 possible without causing a major change in available bandwidth.
578 Unless it is overridden by the AIMD window increase, CUBIC is very
579 careful in this region. The convex profile aims to increase the
580 window very slowly at the beginning when _cwnd_ is around _W_max_ and
581 then gradually increases its rate of increase. We also call this
582 region the "maximum probing phase", since CUBIC is searching for a
583 new _W_max_. In this region, _cwnd_ MUST be incremented by
585 target - cwnd
586 -------------
587 cwnd
589 for each received ACK, where _target_ is calculated as described in
590 Section 4.2.
592 4.6. Multiplicative Decrease
594 When a congestion event is detected by mechanisms described in
595 Section 3.1, CUBIC updates _W_max_ and reduces _cwnd_ and _ssthresh_
596 immediately as described below. An implementation MAY set a smaller
597 _ssthresh_ than suggested below to accommodate rate-limited
598 applications as described in [RFC7661]. For both packet loss and
599 congestion detection through ECN, the sender MAY employ a Fast
600 Recovery algorithm to gradually adjust the congestion window to its
601 new reduced _ssthresh_ value. The parameter β__cubic_ SHOULD be set
602 to 0.7.
604 ssthresh = cwnd * β // new slow-start threshold
605 cubic
607 ssthresh = max(ssthresh, 2) // threshold is at least 2 MSS
609 // window reduction
610 cwnd = ssthresh
612 A side effect of setting β__cubic_ to a value bigger than 0.5 is
613 slower convergence. We believe that while a more adaptive setting of
614 β__cubic_ could result in faster convergence, it will make the
615 analysis of CUBIC much harder.
617 4.7. Fast Convergence
619 To improve convergence speed, CUBIC uses a heuristic. When a new
620 flow joins the network, existing flows need to give up some of their
621 bandwidth to allow the new flow some room for growth, if the existing
622 flows have been using all the network bandwidth. To speed up this
623 bandwidth release by existing flows, the following "Fast Convergence"
624 mechanism SHOULD be implemented.
626 With Fast Convergence, when a congestion event occurs, we update
627 _W_max_ as follows, before the window reduction as described in
628 Section 4.6.
630 /
631 | 1 + β
632 | cubic if cwnd < W and fast convergence is enabled,
633 |cwnd * ---------- max
634 | 2
635 W = <
636 max | further reduce W
637 | max
638 |
639 | otherwise, remember cwnd before reduction
640 \cwnd
642 At a congestion event, if the current _cwnd_ is less than _W_max_,
643 this indicates that the saturation point experienced by this flow is
644 getting reduced because of a change in available bandwidth. Then we
645 allow this flow to release more bandwidth by reducing _W_max_
646 further. This action effectively lengthens the time for this flow to
647 increase its congestion window, because the reduced _W_max_ forces
648 the flow to plateau earlier. This allows more time for the new flow
649 to catch up to its congestion window size.
651 Fast Convergence is designed for network environments with multiple
652 CUBIC flows. In network environments with only a single CUBIC flow
653 and without any other traffic, Fast Convergence SHOULD be disabled.
655 4.8. Timeout
657 In case of a timeout, CUBIC follows AIMD TCP to reduce _cwnd_
658 [RFC5681], but sets _ssthresh_ using β__cubic_ (same as in
659 Section 4.6) in a way that is different from AIMD TCP [RFC5681].
661 During the first congestion avoidance stage after a timeout, CUBIC
662 increases its congestion window size using Figure 1, where _t_ is the
663 elapsed time since the beginning of the current congestion avoidance,
664 _K_ is set to 0, and _W_max_ is set to the congestion window size at
665 the beginning of the current congestion avoidance stage. In
666 addition, for the AIMD-friendly region, _W_est_ SHOULD be set to the
667 congestion window size at the beginning of the current congestion
668 avoidance.
670 4.9. Spurious Congestion Events
672 In cases where CUBIC reduces its congestion window in response to
673 having detected packet loss via duplicate ACKs or timeouts, there is
674 a possibility that the missing ACK would arrive after the congestion
675 window reduction and a corresponding packet retransmission. For
676 example, packet reordering could trigger this behavior. A high
677 degree of packet reordering could cause multiple congestion window
678 reduction events, where spurious losses are incorrectly interpreted
679 as congestion signals, thus degrading CUBIC's performance
680 significantly.
682 When there is a congestion event, a CUBIC implementation SHOULD save
683 the current value of the following variables before the congestion
684 window reduction.
686 prior_cwnd = cwnd
688 prior_ssthresh = ssthresh
690 prior_W = W
691 max max
693 prior_K = K
695 prior_epoch = epoch
696 start start
698 prior_W_{est} = W
699 est
701 CUBIC MAY implement an algorithm to detect spurious retransmissions,
702 such as DSACK [RFC3708], Forward RTO-Recovery [RFC5682] or Eifel
703 [RFC3522]. Once a spurious congestion event is detected, CUBIC
704 SHOULD restore the original values of above-mentioned variables as
705 follows if the current _cwnd_ is lower than _prior_cwnd_. Restoring
706 the original values ensures that CUBIC's performance is similar to
707 what it would be without spurious losses.
709 \
710 cwnd = prior_cwnd |
711 |
712 ssthresh = prior_ssthresh |
713 |
714 W = prior_W |
715 max max |
716 >if cwnd < prior_cwnd
717 K = prior_K |
718 |
719 epoch = prior_epoch |
720 start start|
721 |
722 W = prior_W |
723 est est /
725 In rare cases, when the detection happens long after a spurious loss
726 event and the current _cwnd_ is already higher than _prior_cwnd_,
727 CUBIC SHOULD continue to use the current and the most recent values
728 of these variables.
730 4.10. Slow Start
732 CUBIC MUST employ a slow-start algorithm, when _cwnd_ is no more than
733 _ssthresh_. Among the slow-start algorithms, CUBIC MAY choose the
734 AIMD TCP slow start [RFC5681] in general networks, or the limited
735 slow start [RFC3742] or hybrid slow start [HR08] for fast and long-
736 distance networks.
738 When CUBIC uses hybrid slow start [HR08], it may exit the first slow
739 start without incurring any packet loss and thus _W_max_ is
740 undefined. In this special case, CUBIC switches to congestion
741 avoidance and increases its congestion window size using Figure 1,
742 where _t_ is the elapsed time since the beginning of the current
743 congestion avoidance, _K_ is set to 0, and _W_max_ is set to the
744 congestion window size at the beginning of the current congestion
745 avoidance stage.
747 5. Discussion
749 In this section, we further discuss the safety features of CUBIC
750 following the guidelines specified in [RFC5033].
752 With a deterministic loss model where the number of packets between
753 two successive packet losses is always _1/p_, CUBIC always operates
754 with the concave window profile, which greatly simplifies the
755 performance analysis of CUBIC. The average window size of CUBIC can
756 be obtained by the following function:
758 ________________ ____
759 /C * (3 + β ) 3 / 4
760 4 / cubic |/ RTT
761 AVG_W = | / ---------------- * -------
762 cubic | / 4 * (1 - β ) __
763 |/ cubic 3 / 4
764 |/ p
766 Figure 5
768 With β__cubic_ set to 0.7, the above formula reduces to:
770 ____
771 _______ 3 / 4
772 4 /C * 3.7 |/ RTT
773 AVG_W = | / ------- * -------
774 cubic |/ 1.2 __
775 3 / 4
776 |/ p
778 Figure 6
780 We will determine the value of _C_ in the following subsection using
781 Figure 6.
783 5.1. Fairness to AIMD TCP
785 In environments where AIMD TCP is able to make reasonable use of the
786 available bandwidth, CUBIC does not significantly change this state.
788 AIMD TCP performs well in the following two types of networks:
790 1. networks with a small bandwidth-delay product (BDP)
792 2. networks with a short RTTs, but not necessarily a small BDP
794 CUBIC is designed to behave very similarly to AIMD TCP in the above
795 two types of networks. The following two tables show the average
796 window sizes of AIMD TCP, HSTCP, and CUBIC. The average window sizes
797 of AIMD TCP and HSTCP are from [RFC3649]. The average window size of
798 CUBIC is calculated using Figure 6 and the CUBIC AIMD-friendly region
799 for three different values of _C_.
801 +=============+=======+========+================+=========+========+
802 | Loss Rate P | AIMD | HSTCP | CUBIC (C=0.04) | CUBIC | CUBIC |
803 | | | | | (C=0.4) | (C=4) |
804 +=============+=======+========+================+=========+========+
805 | 1.0e-02 | 12 | 12 | 12 | 12 | 12 |
806 +-------------+-------+--------+----------------+---------+--------+
807 | 1.0e-03 | 38 | 38 | 38 | 38 | 59 |
808 +-------------+-------+--------+----------------+---------+--------+
809 | 1.0e-04 | 120 | 263 | 120 | 187 | 333 |
810 +-------------+-------+--------+----------------+---------+--------+
811 | 1.0e-05 | 379 | 1795 | 593 | 1054 | 1874 |
812 +-------------+-------+--------+----------------+---------+--------+
813 | 1.0e-06 | 1200 | 12280 | 3332 | 5926 | 10538 |
814 +-------------+-------+--------+----------------+---------+--------+
815 | 1.0e-07 | 3795 | 83981 | 18740 | 33325 | 59261 |
816 +-------------+-------+--------+----------------+---------+--------+
817 | 1.0e-08 | 12000 | 574356 | 105383 | 187400 | 333250 |
818 +-------------+-------+--------+----------------+---------+--------+
820 Table 1: AIMD TCP, HSTCP, and CUBIC with RTT = 0.1 seconds
822 Table 1 describes the response function of AIMD TCP, HSTCP, and CUBIC
823 in networks with _RTT_ = 0.1 seconds. The average window size is in
824 MSS-sized segments.
826 +=============+=======+========+================+=========+=======+
827 | Loss Rate P | AIMD | HSTCP | CUBIC (C=0.04) | CUBIC | CUBIC |
828 | | | | | (C=0.4) | (C=4) |
829 +=============+=======+========+================+=========+=======+
830 | 1.0e-02 | 12 | 12 | 12 | 12 | 12 |
831 +-------------+-------+--------+----------------+---------+-------+
832 | 1.0e-03 | 38 | 38 | 38 | 38 | 38 |
833 +-------------+-------+--------+----------------+---------+-------+
834 | 1.0e-04 | 120 | 263 | 120 | 120 | 120 |
835 +-------------+-------+--------+----------------+---------+-------+
836 | 1.0e-05 | 379 | 1795 | 379 | 379 | 379 |
837 +-------------+-------+--------+----------------+---------+-------+
838 | 1.0e-06 | 1200 | 12280 | 1200 | 1200 | 1874 |
839 +-------------+-------+--------+----------------+---------+-------+
840 | 1.0e-07 | 3795 | 83981 | 3795 | 5926 | 10538 |
841 +-------------+-------+--------+----------------+---------+-------+
842 | 1.0e-08 | 12000 | 574356 | 18740 | 33325 | 59261 |
843 +-------------+-------+--------+----------------+---------+-------+
845 Table 2: AIMD TCP, HSTCP, and CUBIC with RTT = 0.01 seconds
847 Table 2 describes the response function of AIMD TCP, HSTCP, and CUBIC
848 in networks with _RTT_ = 0.01 seconds. The average window size is in
849 MSS-sized segments.
851 Both tables show that CUBIC with any of these three _C_ values is
852 more friendly to AIMD TCP than HSTCP, especially in networks with a
853 short _RTT_ where AIMD TCP performs reasonably well. For example, in
854 a network with _RTT_ = 0.01 seconds and p=10^-6, AIMD TCP has an
855 average window of 1200 packets. If the packet size is 1500 bytes,
856 then AIMD TCP can achieve an average rate of 1.44 Gbps. In this
857 case, CUBIC with _C_=0.04 or _C_=0.4 achieves exactly the same rate
858 as AIMD TCP, whereas HSTCP is about ten times more aggressive than
859 AIMD TCP.
861 We can see that _C_ determines the aggressiveness of CUBIC in
862 competing with other congestion control algorithms for bandwidth.
863 CUBIC is more friendly to AIMD TCP, if the value of _C_ is lower.
864 However, we do not recommend setting _C_ to a very low value like
865 0.04, since CUBIC with a low _C_ cannot efficiently use the bandwidth
866 in fast and long-distance networks. Based on these observations and
867 extensive deployment experience, we find _C_=0.4 gives a good balance
868 between AIMD- friendliness and aggressiveness of window increase.
869 Therefore, _C_ SHOULD be set to 0.4. With _C_ set to 0.4, Figure 6
870 is reduced to:
872 ____
873 3 / 4
874 |/ RTT
875 AVG_W = 1.054 * -------
876 cubic __
877 3 / 4
878 |/ p
880 Figure 7
882 Figure 7 is then used in the next subsection to show the scalability
883 of CUBIC.
885 5.2. Using Spare Capacity
887 CUBIC uses a more aggressive window increase function than AIMD TCP
888 for fast and long-distance networks.
890 The following table shows that to achieve the 10 Gbps rate, AIMD TCP
891 requires a packet loss rate of 2.0e-10, while CUBIC requires a packet
892 loss rate of 2.9e-8.
894 +===================+===========+=========+=========+=========+
895 | Throughput (Mbps) | Average W | AIMD P | HSTCP P | CUBIC P |
896 +===================+===========+=========+=========+=========+
897 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 |
898 +-------------------+-----------+---------+---------+---------+
899 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 |
900 +-------------------+-----------+---------+---------+---------+
901 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 |
902 +-------------------+-----------+---------+---------+---------+
903 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 |
904 +-------------------+-----------+---------+---------+---------+
905 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 |
906 +-------------------+-----------+---------+---------+---------+
908 Table 3: Required packet loss rate for AIMD TCP, HSTCP, and
909 CUBIC to achieve a certain throughput
911 Table 3 describes the required packet loss rate for AIMD TCP, HSTCP,
912 and CUBIC to achieve a certain throughput. We use 1500-byte packets
913 and an _RTT_ of 0.1 seconds.
915 Our test results in [HKLRX06] indicate that CUBIC uses the spare
916 bandwidth left unused by existing AIMD TCP flows in the same
917 bottleneck link without taking away much bandwidth from the existing
918 flows.
920 5.3. Difficult Environments
922 CUBIC is designed to remedy the poor performance of AIMD TCP in fast
923 and long-distance networks.
925 5.4. Investigating a Range of Environments
927 There is decade-long deployment experience with CUBIC on the
928 Internet. CUBIC has also been extensively studied by using both NS-2
929 simulation and testbed experiments, covering a wide range of network
930 environments. More information can be found in [HKLRX06].
932 Same as AIMD TCP, CUBIC is a loss-based congestion control algorithm.
933 Because CUBIC is designed to be more aggressive (due to a faster
934 window increase function and bigger multiplicative decrease factor)
935 than AIMD TCP in fast and long-distance networks, it can fill large
936 drop-tail buffers more quickly than AIMD TCP and increases the risk
937 of a standing queue [RFC8511]. In this case, proper queue sizing and
938 management [RFC7567] could be used to reduce the packet queuing
939 delay.
941 5.5. Protection against Congestion Collapse
943 With regard to the potential of causing congestion collapse, CUBIC
944 behaves like AIMD TCP, since CUBIC modifies only the window
945 adjustment algorithm of AIMD TCP. Thus, it does not modify the ACK
946 clocking and timeout behaviors of AIMD TCP.
948 5.6. Fairness within the Alternative Congestion Control Algorithm
950 CUBIC ensures convergence of competing CUBIC flows with the same RTT
951 in the same bottleneck links to an equal throughput. When competing
952 flows have different RTT values, their throughput ratio is linearly
953 proportional to the inverse of their RTT ratios. This is true
954 independently of the level of statistical multiplexing on the link.
956 5.7. Performance with Misbehaving Nodes and Outside Attackers
958 This is not considered in the current CUBIC design.
960 5.8. Behavior for Application-Limited Flows
962 CUBIC does not increase its congestion window size if a flow is
963 currently limited by the application instead of the congestion
964 window. In case of long periods during which _cwnd_ has not been
965 updated due to such an application limit, such as idle periods, _t_
966 in Figure 1 MUST NOT include these periods; otherwise, W_cubic(_t_)
967 might be very high after restarting from these periods.
969 5.9. Responses to Sudden or Transient Events
971 If there is a sudden congestion, a routing change, or a mobility
972 event, CUBIC behaves the same as AIMD TCP.
974 5.10. Incremental Deployment
976 CUBIC requires only changes to TCP senders, and it does not require
977 any changes at TCP receivers. That is, a CUBIC sender works
978 correctly with the AIMD TCP receivers. In addition, CUBIC does not
979 require any changes to routers and does not require any assistance
980 from routers.
982 6. Security Considerations
984 CUBIC makes no changes to the underlying security of TCP. More
985 information about TCP security concerns can be found in [RFC5681].
987 7. IANA Considerations
989 This document does not require any IANA actions.
991 8. References
993 8.1. Normative References
995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
996 Requirement Levels", BCP 14, RFC 2119,
997 DOI 10.17487/RFC2119, March 1997,
998 .
1000 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
1001 of Explicit Congestion Notification (ECN) to IP",
1002 RFC 3168, DOI 10.17487/RFC3168, September 2001,
1003 .
1005 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
1006 Control Algorithms", BCP 133, RFC 5033,
1007 DOI 10.17487/RFC5033, August 2007,
1008 .
1010 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
1011 Friendly Rate Control (TFRC): Protocol Specification",
1012 RFC 5348, DOI 10.17487/RFC5348, September 2008,
1013 .
1015 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
1016 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
1017 .
1019 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
1020 "Computing TCP's Retransmission Timer", RFC 6298,
1021 DOI 10.17487/RFC6298, June 2011,
1022 .
1024 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
1025 NewReno Modification to TCP's Fast Recovery Algorithm",
1026 RFC 6582, DOI 10.17487/RFC6582, April 2012,
1027 .
1029 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
1030 and Y. Nishida, "A Conservative Loss Recovery Algorithm
1031 Based on Selective Acknowledgment (SACK) for TCP",
1032 RFC 6675, DOI 10.17487/RFC6675, August 2012,
1033 .
1035 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
1036 Recommendations Regarding Active Queue Management",
1037 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
1038 .
1040 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1041 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1042 May 2017, .
1044 [RFC8985] Cheng, Y., Cardwell, N., Dukkipati, N., and P. Jha, "The
1045 RACK-TLP Loss Detection Algorithm for TCP", RFC 8985,
1046 DOI 10.17487/RFC8985, February 2021,
1047 .
1049 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
1050 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
1051 May 2021, .
1053 8.2. Informative References
1055 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic
1056 Ordering for Internet Congestion Control and its
1057 Applications", IEEE INFOCOM 2007 - 26th IEEE International
1058 Conference on Computer Communications,
1059 DOI 10.1109/infcom.2007.111, 2007,
1060 .
1062 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of
1063 Equation-Based and AIMD Congestion Control", May 2000,
1064 .
1066 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary
1067 Adjustment Algorithms", Technical Report TR2002-29,
1068 Department of Computer Sciences, The University of
1069 Texas at Austin, 11 August 2002,
1070 .
1072 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step
1073 toward Realistic Performance Evaluation of High-Speed TCP
1074 Variants", International Workshop on Protocols for Fast
1075 Long-Distance Networks, February 2006,
1076 .
1078 [HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth
1079 and Long-Distance Networks", International Workshop
1080 on Protocols for Fast Long-Distance Networks, March 2008,
1081 .
1084 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly
1085 high-speed TCP variant", ACM SIGOPS Operating Systems
1086 Review Vol. 42, pp. 64-74, DOI 10.1145/1400097.1400105,
1087 July 2008, .
1089 [K03] Kelly, T., "Scalable TCP: improving performance in
1090 highspeed wide area networks", ACM SIGCOMM Computer
1091 Communication Review Vol. 33, pp. 83-91,
1092 DOI 10.1145/956981.956989, April 2003,
1093 .
1095 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte
1096 Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February
1097 2003, .
1099 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
1100 for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003,
1101 .
1103 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
1104 RFC 3649, DOI 10.17487/RFC3649, December 2003,
1105 .
1107 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
1108 Acknowledgement (DSACKs) and Stream Control Transmission
1109 Protocol (SCTP) Duplicate Transmission Sequence Numbers
1110 (TSNs) to Detect Spurious Retransmissions", RFC 3708,
1111 DOI 10.17487/RFC3708, February 2004,
1112 .
1114 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
1115 Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March
1116 2004, .
1118 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
1119 RFC 4960, DOI 10.17487/RFC4960, September 2007,
1120 .
1122 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,
1123 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
1124 Spurious Retransmission Timeouts with TCP", RFC 5682,
1125 DOI 10.17487/RFC5682, September 2009,
1126 .
1128 [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
1129 TCP to Support Rate-Limited Traffic", RFC 7661,
1130 DOI 10.17487/RFC7661, October 2015,
1131 .
1133 [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and
1134 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks",
1135 RFC 8312, DOI 10.17487/RFC8312, February 2018,
1136 .
1138 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
1139 "TCP Alternative Backoff with ECN (ABE)", RFC 8511,
1140 DOI 10.17487/RFC8511, December 2018,
1141 .
1143 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
1144 Multiplexed and Secure Transport", RFC 9000,
1145 DOI 10.17487/RFC9000, May 2021,
1146 .
1148 [SXEZ19] Sun, W., Xu, L., Elbaum, S., and D. Zhao, "Model-Agnostic
1149 and Efficient Exploration of Numerical State Space of
1150 Real-World TCP Congestion Control Implementations", USENIX
1151 NSDI 2019, February 2019,
1152 .
1154 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase
1155 Congestion Control (BIC) for Fast Long-Distance Networks",
1156 IEEE INFOCOM 2004, DOI 10.1109/infcom.2004.1354672, March
1157 2004, .
1159 Appendix A. Acknowledgments
1161 Richard Scheffenegger and Alexander Zimmermann originally co-authored
1162 [RFC8312].
1164 Appendix B. Evolution of CUBIC
1166 B.1. Since draft-ietf-tcpm-rfc8312bis-03
1168 * Remove reference from abstract (#82
1169 (https://github.com/NTAP/rfc8312bis/pull/82))
1171 B.2. Since draft-ietf-tcpm-rfc8312bis-02
1173 * Decription of packet loss rate _p_ (#65
1174 (https://github.com/NTAP/rfc8312bis/issues/65))
1176 * Clarification of TCP Friendly Equation for ABC and Delayed ACK
1177 (#66 (https://github.com/NTAP/rfc8312bis/issues/66))
1179 * add applicability to QUIC and SCTP (#61
1180 (https://github.com/NTAP/rfc8312bis/issues/61))
1182 * clarity on setting alpha__aimd_ to 1 (#68
1183 (https://github.com/NTAP/rfc8312bis/issues/68))
1185 * introduce alpha__cubic_ (#64 (https://github.com/NTAP/rfc8312bis/
1186 issues/64))
1188 * clarify _cwnd_ growth in convex region (#69
1189 (https://github.com/NTAP/rfc8312bis/issues/69))
1191 * add guidance for using bytes and mention that segments count is
1192 decimal (#67 (https://github.com/NTAP/rfc8312bis/issues/67))
1194 * add loss events detected by RACK and QUIC loss detection (#62
1195 (https://github.com/NTAP/rfc8312bis/issues/62))
1197 B.3. Since draft-ietf-tcpm-rfc8312bis-01
1199 * address Michael Scharf's editorial suggestions. (#59
1200 (https://github.com/NTAP/rfc8312bis/issues/59))
1202 * add "Note to the RFC Editor" about removing underscores
1204 B.4. Since draft-ietf-tcpm-rfc8312bis-00
1206 * use updated xml2rfc with better text rendering of subscripts
1208 B.5. Since draft-eggert-tcpm-rfc8312bis-03
1210 * fix spelling nits
1212 * rename to draft-ietf
1214 * define _W_max_ more clearly
1216 B.6. Since draft-eggert-tcpm-rfc8312bis-02
1218 * add definition for segments_acked and alpha__aimd_. (#47
1219 (https://github.com/NTAP/rfc8312bis/issues/47))
1221 * fix a mistake in _W_max_ calculation in the fast convergence
1222 section. (#51 (https://github.com/NTAP/rfc8312bis/issues/51))
1224 * clarity on setting _ssthresh_ and _cwnd_start_ during
1225 multiplicative decrease. (#53 (https://github.com/NTAP/rfc8312bis/
1226 issues/53))
1228 B.7. Since draft-eggert-tcpm-rfc8312bis-01
1229 * rename TCP-Friendly to AIMD-Friendly and rename Standard TCP to
1230 AIMD TCP to avoid confusion as CUBIC has been widely used on the
1231 Internet. (#38 (https://github.com/NTAP/rfc8312bis/issues/38))
1233 * change introductory text to reflect the significant broader
1234 deployment of CUBIC on the Internet. (#39
1235 (https://github.com/NTAP/rfc8312bis/issues/39))
1237 * rephrase introduction to avoid referring to variables that have
1238 not been defined yet.
1240 B.8. Since draft-eggert-tcpm-rfc8312bis-00
1242 * acknowledge former co-authors (#15
1243 (https://github.com/NTAP/rfc8312bis/issues/15))
1245 * prevent _cwnd_ from becoming less than two (#7
1246 (https://github.com/NTAP/rfc8312bis/issues/7))
1248 * add list of variables and constants (#5
1249 (https://github.com/NTAP/rfc8312bis/issues/5), #6
1250 (https://github.com/NTAP/rfc8312bis/issues/6))
1252 * update _K_'s definition and add bounds for CUBIC _target_ _cwnd_
1253 [SXEZ19] (#1 (https://github.com/NTAP/rfc8312bis/issues/1), #14
1254 (https://github.com/NTAP/rfc8312bis/issues/14))
1256 * update _W_est_ to use AIMD approach (#20
1257 (https://github.com/NTAP/rfc8312bis/issues/20))
1259 * set alpha__aimd_ to 1 once _W_est_ reaches _W_max_ (#2
1260 (https://github.com/NTAP/rfc8312bis/issues/2))
1262 * add Vidhi as co-author (#17 (https://github.com/NTAP/rfc8312bis/
1263 issues/17))
1265 * note for Fast Recovery during _cwnd_ decrease due to congestion
1266 event (#11 (https://github.com/NTAP/rfc8312bis/issues/11))
1268 * add section for spurious congestion events (#23
1269 (https://github.com/NTAP/rfc8312bis/issues/23))
1271 * initialize _W_est_ after timeout and remove variable
1272 _W_(last_max)_ (#28 (https://github.com/NTAP/rfc8312bis/
1273 issues/28))
1275 B.9. Since RFC8312
1276 * converted to Markdown and xml2rfc v3
1278 * updated references (as part of the conversion)
1280 * updated author information
1282 * various formatting changes
1284 * move to Standards Track
1286 B.10. Since the Original Paper
1288 CUBIC has gone through a few changes since the initial release
1289 [HRX08] of its algorithm and implementation. Below we highlight the
1290 differences between its original paper and [RFC8312].
1292 * The original paper [HRX08] includes the pseudocode of CUBIC
1293 implementation using Linux's pluggable congestion control
1294 framework, which excludes system-specific optimizations. The
1295 simplified pseudocode might be a good source to start with and
1296 understand CUBIC.
1298 * [HRX08] also includes experimental results showing its performance
1299 and fairness.
1301 * The definition of beta__cubic_ constant was changed in [RFC8312].
1302 For example, beta__cubic_ in the original paper was the window
1303 decrease constant while [RFC8312] changed it to CUBIC
1304 multiplication decrease factor. With this change, the current
1305 congestion window size after a congestion event in [RFC8312] was
1306 beta__cubic_ * _W_max_ while it was (1-beta__cubic_) * _W_max_ in
1307 the original paper.
1309 * Its pseudocode used _W_(last_max)_ while [RFC8312] used _W_max_.
1311 * Its AIMD-friendly window was _W_tcp_ while [RFC8312] used _W_est_.
1313 Authors' Addresses
1315 Lisong Xu
1316 University of Nebraska-Lincoln
1317 Department of Computer Science and Engineering
1318 Lincoln, NE 68588-0115
1319 United States of America
1321 Email: xu@unl.edu
1322 URI: https://cse.unl.edu/~xu/
1323 Sangtae Ha
1324 University of Colorado at Boulder
1325 Department of Computer Science
1326 Boulder, CO 80309-0430
1327 United States of America
1329 Email: sangtae.ha@colorado.edu
1330 URI: https://netstech.org/sangtaeha/
1332 Injong Rhee
1333 Bowery Farming
1334 151 W 26TH Street, 12TH Floor
1335 New York, NY 10001
1336 United States of America
1338 Email: injongrhee@gmail.com
1340 Vidhi Goel
1341 Apple Inc.
1342 One Apple Park Way
1343 Cupertino, California 95014
1344 United States of America
1346 Email: vidhi_goel@apple.com
1348 Lars Eggert (editor)
1349 NetApp
1350 Stenbergintie 12 B
1351 FI-02700 Kauniainen
1352 Finland
1354 Email: lars@eggert.org
1355 URI: https://eggert.org/