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/