idnits 2.17.1 draft-ietf-tcpm-rfc8312bis-00.txt: 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 29 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 abstract seems to contain references ([RFC8312]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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 485 has weird spacing: '... aimd aimd...' == Line 500 has weird spacing: '... aimd cub...' == Line 515 has weird spacing: '... est est...' == Line 660 has weird spacing: '... max max...' -- The document date (15 March 2021) is 1138 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: 2 errors (**), 0 flaws (~~), 6 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: 16 September 2021 I. Rhee 7 Bowery 8 V. Goel 9 Apple Inc. 10 L. Eggert, Ed. 11 NetApp 12 15 March 2021 14 CUBIC for Fast and Long-Distance Networks 15 draft-ietf-tcpm-rfc8312bis-00 17 Abstract 19 CUBIC is an extension to the traditional TCP standards. It differs 20 from the traditional TCP standards only in the congestion control 21 algorithm on the sender side. In particular, it uses a cubic 22 function instead of the linear window increase function of the 23 traditional TCP standards to improve scalability and stability under 24 fast and long-distance networks. CUBIC has been adopted as the 25 default TCP congestion control algorithm by the Linux, Windows, and 26 Apple stacks. 28 This document updates the specification of CUBIC to include 29 algorithmic improvements based on these implementations and recent 30 academic work. Based on the extensive deployment experience with 31 CUBIC, it also moves the specification to the Standards Track, 32 obsoleting [RFC8312]. 34 Note to Readers 36 Discussion of this draft takes place on the TCPM working group 37 mailing list (mailto:tcpm@ietf.org), which is archived at 38 https://mailarchive.ietf.org/arch/browse/tcpm/. 40 Working Group information can be found at 41 https://datatracker.ietf.org/wg/tcpm/; source code and issues list 42 for this draft can be found at https://github.com/NTAP/rfc8312bis. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 16 September 2021. 61 Copyright Notice 63 Copyright (c) 2021 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Simplified BSD License text 72 as described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3. Design Principles of CUBIC . . . . . . . . . . . . . . . . . 4 80 3.1. Principle 1 for the CUBIC Increase Function . . . . . . . 5 81 3.2. Principle 2 for AIMD Friendliness . . . . . . . . . . . . 6 82 3.3. Principle 3 for RTT Fairness . . . . . . . . . . . . . . 6 83 3.4. Principle 4 for the CUBIC Decrease Factor . . . . . . . . 7 84 4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 7 85 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 86 4.1.1. Constants of Interest . . . . . . . . . . . . . . . . 7 87 4.1.2. Variables of Interest . . . . . . . . . . . . . . . . 8 88 4.2. Window Increase Function . . . . . . . . . . . . . . . . 9 89 4.3. AIMD-Friendly Region . . . . . . . . . . . . . . . . . . 10 90 4.4. Concave Region . . . . . . . . . . . . . . . . . . . . . 12 91 4.5. Convex Region . . . . . . . . . . . . . . . . . . . . . . 12 92 4.6. Multiplicative Decrease . . . . . . . . . . . . . . . . . 13 93 4.7. Fast Convergence . . . . . . . . . . . . . . . . . . . . 13 94 4.8. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 4.9. Spurious Congestion Events . . . . . . . . . . . . . . . 14 96 4.10. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 16 98 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 5.1. Fairness to AIMD TCP . . . . . . . . . . . . . . . . . . 17 100 5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 19 101 5.3. Difficult Environments . . . . . . . . . . . . . . . . . 20 102 5.4. Investigating a Range of Environments . . . . . . . . . . 20 103 5.5. Protection against Congestion Collapse . . . . . . . . . 21 104 5.6. Fairness within the Alternative Congestion Control 105 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 21 106 5.7. Performance with Misbehaving Nodes and Outside 107 Attackers . . . . . . . . . . . . . . . . . . . . . . . 21 108 5.8. Behavior for Application-Limited Flows . . . . . . . . . 21 109 5.9. Responses to Sudden or Transient Events . . . . . . . . . 21 110 5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 21 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 112 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 113 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 114 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 115 8.2. Informative References . . . . . . . . . . . . . . . . . 23 116 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 117 Appendix B. Evolution of CUBIC . . . . . . . . . . . . . . . . . 25 118 B.1. Since draft-eggert-tcpm-rfc8312bis-03 . . . . . . . . . . 25 119 B.2. Since draft-eggert-tcpm-rfc8312bis-02 . . . . . . . . . . 25 120 B.3. Since draft-eggert-tcpm-rfc8312bis-01 . . . . . . . . . . 25 121 B.4. Since draft-eggert-tcpm-rfc8312bis-00 . . . . . . . . . . 26 122 B.5. Since RFC8312 . . . . . . . . . . . . . . . . . . . . . . 26 123 B.6. Since the Original Paper . . . . . . . . . . . . . . . . 27 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 126 1. Introduction 128 The low utilization problem of traditional TCP in fast and long- 129 distance networks is well documented in [K03] and [RFC3649]. This 130 problem arises from a slow increase of the congestion window 131 following a congestion event in a network with a large bandwidth- 132 delay product (BDP). [HKLRX06] indicates that this problem is 133 frequently observed even in the range of congestion window sizes over 134 several hundreds of packets. This problem is equally applicable to 135 all Reno-style TCP standards and their variants, including TCP-Reno 136 [RFC5681], TCP-NewReno [RFC6582][RFC6675], SCTP [RFC4960], and TFRC 137 [RFC5348], which use the same linear increase function for window 138 growth. We refer to all Reno-style TCP standards and their variants 139 collectively as "AIMD TCP" below because they use the Additive 140 Increase and Multiplicative Decrease algorithm (AIMD). 142 CUBIC, originally proposed in [HRX08], is a modification to the 143 congestion control algorithm of traditional AIMD TCP to remedy this 144 problem. This document describes the most recent specification of 145 CUBIC. Specifically, CUBIC uses a cubic function instead of the 146 linear window increase function of AIMD TCP to improve scalability 147 and stability under fast and long-distance networks. 149 Binary Increase Congestion Control (BIC-TCP) [XHR04], a predecessor 150 of CUBIC, was selected as the default TCP congestion control 151 algorithm by Linux in the year 2005 and had been used for several 152 years by the Internet community at large. 154 CUBIC uses a similar window increase function as BIC-TCP and is 155 designed to be less aggressive and fairer to AIMD TCP in bandwidth 156 usage than BIC-TCP while maintaining the strengths of BIC-TCP such as 157 stability, window scalability, and round-trip time (RTT) fairness. 158 CUBIC has been adopted as the default TCP congestion control 159 algorithm in the Linux, Windows, and Apple stacks, and has been used 160 and deployed globally. Extensive, decade-long deployment experience 161 in vastly different Internet scenarios has convincingly demonstrated 162 that CUBIC is safe for deployment on the global Internet and delivers 163 substantial benefits over traditional AIMD congestion control. It is 164 therefore to be regarded as the current standard for TCP congestion 165 control. 167 In the following sections, we first briefly explain the design 168 principles of CUBIC, then provide the exact specification of CUBIC, 169 and finally discuss the safety features of CUBIC following the 170 guidelines specified in [RFC5033]. 172 2. Conventions 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in 177 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 3. Design Principles of CUBIC 182 CUBIC is designed according to the following design principles: 184 Principle 1: For better network utilization and stability, CUBIC 185 uses both the concave and convex profiles of a cubic function to 186 increase the congestion window size, instead of using just a 187 convex function. 189 Principle 2: To be AIMD-friendly, CUBIC is designed to behave like 190 AIMD TCP in networks with short RTTs and small bandwidth where 191 AIMD TCP performs well. 193 Principle 3: For RTT-fairness, CUBIC is designed to achieve linear 194 bandwidth sharing among flows with different RTTs. 196 Principle 4: CUBIC appropriately sets its multiplicative window 197 decrease factor in order to balance between the scalability and 198 convergence speed. 200 3.1. Principle 1 for the CUBIC Increase Function 202 For better network utilization and stability, CUBIC [HRX08] uses a 203 cubic window increase function in terms of the elapsed time from the 204 last congestion event. While most alternative congestion control 205 algorithms to AIMD TCP increase the congestion window using convex 206 functions, CUBIC uses both the concave and convex profiles of a cubic 207 function for window growth. 209 After a window reduction in response to a congestion event is 210 detected by duplicate ACKs or Explicit Congestion Notification-Echo 211 (ECN-Echo, ECE) ACKs [RFC3168], CUBIC remembers the congestion window 212 size where it received the congestion event and performs a 213 multiplicative decrease of the congestion window. When CUBIC enters 214 into congestion avoidance, it starts to increase the congestion 215 window using the concave profile of the cubic function. The cubic 216 function is set to have its plateau at the remembered congestion 217 window size, so that the concave window increase continues until 218 then. After that, the cubic function turns into a convex profile and 219 the convex window increase begins. 221 This style of window adjustment (concave and then convex) improves 222 the algorithm stability while maintaining high network utilization 223 [CEHRX07]. This is because the window size remains almost constant, 224 forming a plateau around the remembered congestion window size of the 225 last congestion event, where network utilization is deemed highest. 226 Under steady state, most window size samples of CUBIC are close to 227 that remembered congestion window size, thus promoting high network 228 utilization and stability. 230 Note that congestion control algorithms that only use convex 231 functions to increase the congestion window size have their maximum 232 increments around the remembered congestion window size of the last 233 congestion event, and thus introduce a large number of packet bursts 234 around the saturation point of the network, likely causing frequent 235 global loss synchronizations. 237 3.2. Principle 2 for AIMD Friendliness 239 CUBIC promotes per-flow fairness to AIMD TCP. Note that AIMD TCP 240 performs well over paths with short RTTs and small bandwidths (or 241 small BDPs). There is only a scalability problem in networks with 242 long RTTs and large bandwidths (or large BDPs). 244 A congestion control algorithm designed to be friendly to AIMD TCP on 245 a per-flow basis must increase its congestion window less 246 aggressively in small BDP networks than in large BDP networks. 248 The aggressiveness of CUBIC mainly depends on the maximum window size 249 before a window reduction, which is smaller in small-BDP networks 250 than in large-BDP networks. Thus, CUBIC increases its congestion 251 window less aggressively in small-BDP networks than in large-BDP 252 networks. 254 Furthermore, in cases when the cubic function of CUBIC would increase 255 the congestion window less aggressively than AIMD TCP, CUBIC simply 256 follows the window size of AIMD TCP to ensure that CUBIC achieves at 257 least the same throughput as AIMD TCP in small-BDP networks. We call 258 this region where CUBIC behaves like AIMD TCP the "AIMD-friendly 259 region". 261 3.3. Principle 3 for RTT Fairness 263 Two CUBIC flows with different RTTs have a throughput ratio that is 264 linearly proportional to the inverse of their RTT ratio, where the 265 throughput of a flow is approximately the size of its congestion 266 window divided by its RTT. 268 Specifically, CUBIC maintains a window increase rate independent of 269 RTTs outside of the AIMD-friendly region, and thus flows with 270 different RTTs have similar congestion window sizes under steady 271 state when they operate outside the AIMD-friendly region. 273 This notion of a linear throughput ratio is similar to that of AIMD 274 TCP under high statistical multiplexing where packet loss is 275 independent of individual flow rates. However, under low statistical 276 multiplexing, the throughput ratio of AIMD TCP flows with different 277 RTTs is quadratically proportional to the inverse of their RTT ratio 278 [XHR04]. 280 CUBIC always ensures a linear throughput ratio independent of the 281 amount of statistical multiplexing. This is an improvement over AIMD 282 TCP. While there is no consensus on particular throughput ratios for 283 different RTT flows, we believe that over wired Internet paths, use 284 of a linear throughput ratio seems more reasonable than equal 285 throughputs (i.e., the same throughput for flows with different RTTs) 286 or a higher-order throughput ratio (e.g., a quadratical throughput 287 ratio of AIMD TCP under low statistical multiplexing environments). 289 3.4. Principle 4 for the CUBIC Decrease Factor 291 To balance between scalability and convergence speed, CUBIC sets the 292 multiplicative window decrease factor to 0.7, whereas AIMD TCP uses 293 0.5. 295 While this improves the scalability of CUBIC, a side effect of this 296 decision is slower convergence, especially under low statistical 297 multiplexing. This design choice is following the observation that 298 HighSpeed TCP (HSTCP) [RFC3649] and other approaches (e.g., [GV02]) 299 made: the current Internet becomes more asynchronous with less 300 frequent loss synchronizations under high statistical multiplexing. 302 In such environments, even strict Multiplicative-Increase 303 Multiplicative-Decrease (MIMD) can converge. CUBIC flows with the 304 same RTT always converge to the same throughput independent of 305 statistical multiplexing, thus achieving intra-algorithm fairness. 306 We also find that in environments with sufficient statistical 307 multiplexing, the convergence speed of CUBIC is reasonable. 309 4. CUBIC Congestion Control 311 In this section, we discuss how the congestion window is updated 312 during the different stages of the CUBIC congestion controller. 314 4.1. Definitions 316 The unit of all window sizes in this document is segments of the 317 maximum segment size (MSS), and the unit of all times is seconds. 319 4.1.1. Constants of Interest 321 β__(cubic)_: CUBIC multiplication decrease factor as described in 322 Section 4.6. 324 α__(aimd)_: CUBIC additive increase factor used in AIMD-friendly 325 region as described in Section 4.3. 327 _C_: constant that determines the aggressiveness of CUBIC in 328 competing with other congestion control algorithms in high BDP 329 networks. Please see Section 5 for more explanation on how it is 330 set. The unit for _C_ is 331 segment 332 ------- 333 3 334 second 336 4.1.2. Variables of Interest 338 This section defines the variables required to implement CUBIC: 340 _RTT_: Smoothed round-trip time in seconds, calculated as described 341 in [RFC6298]. 343 _cwnd_: Current congestion window in segments. 345 _ssthresh_: Current slow start threshold in segments. 347 _W_(max)_: Size of _cwnd_ in segments just before _cwnd_ was reduced 348 in the last congestion event. 350 _K_: The time period in seconds it takes to increase the congestion 351 window size at the beginning of the current congestion avoidance 352 stage to _W_(max)_. 354 _current_time_: Current time of the system in seconds. 356 _epoch_(start)_: The time in seconds at which the current congestion 357 avoidance stage started. 359 _cwnd_(start)_: The _cwnd_ at the beginning of the current congestion 360 avoidance stage, i.e., at time _epoch_(start)_. 362 W_(cubic)(_t_): The congestion window in segments at time _t_ in 363 seconds based on the cubic increase function, as described in 364 Section 4.2. 366 _target_: Target value of congestion window in segments after the 367 next RTT, that is, W_(cubic)(_t_ + _RTT_), as described in 368 Section 4.2. 370 _W_(est)_: An estimate for the congestion window in segments in the 371 AIMD-friendly region, that is, an estimate for the congestion window 372 of AIMD TCP. 374 _segments_acked_: Number of segments acked when an ACK is received. 376 4.2. Window Increase Function 378 CUBIC maintains the acknowledgment (ACK) clocking of AIMD TCP by 379 increasing the congestion window only at the reception of an ACK. It 380 does not make any changes to the TCP Fast Recovery and Fast 381 Retransmit algorithms [RFC6582][RFC6675]. 383 During congestion avoidance after a congestion event where a packet 384 loss is detected by duplicate ACKs or by receiving packets carrying 385 ECE flags [RFC3168], CUBIC changes the window increase function of 386 AIMD TCP. 388 CUBIC uses the following window increase function: 390 3 391 W (t) = C * (t - K) + W 392 cubic max 394 Figure 1 396 where _t_ is the elapsed time in seconds from the beginning of the 397 current congestion avoidance stage, that is, 399 t = current_time - epoch 400 start 402 and where _epoch_(start)_ is the time at which the current congestion 403 avoidance stage starts. _K_ is the time period that the above 404 function takes to increase the congestion window size at the 405 beginning of the current congestion avoidance stage to _W_(max)_ if 406 there are no further congestion events and is calculated using the 407 following equation: 409 ________________ 410 /W - cwnd 411 3 / max start 412 K = | / ---------------- 413 |/ C 415 Figure 2 417 where _cwnd_(start)_ is the congestion window at the beginning of the 418 current congestion avoidance stage. For example, right after a 419 congestion event, _cwnd_(start)_ is equal to the new cwnd calculated 420 as described in Section 4.6. 422 Upon receiving an ACK during congestion avoidance, CUBIC computes the 423 _target_ congestion window size after the next _RTT_ using Figure 1 424 as follows, where _RTT_ is the smoothed round-trip time. The lower 425 and upper bounds below ensure that CUBIC's congestion window increase 426 rate is non-decreasing and is less than the increase rate of slow 427 start. 429 / 430 | if W (t + RTT) < cwnd 431 |cwnd cubic 432 | 433 | 434 | 435 target = < if W (t + RTT) > 1.5 * cwnd 436 |1.5 * cwnd cubic 437 | 438 | 439 |W (t + RTT) 440 | cubic otherwise 441 \ 443 Depending on the value of the current congestion window size _cwnd_, 444 CUBIC runs in three different regions: 446 1. The AIMD-friendly region, which ensures that CUBIC achieves at 447 least the same throughput as AIMD TCP. 449 2. The concave region, if CUBIC is not in the AIMD-friendly region 450 and _cwnd_ is less than _W_(max)_. 452 3. The convex region, if CUBIC is not in the AIMD-friendly region 453 and _cwnd_ is greater than _W_(max)_. 455 Below, we describe the exact actions taken by CUBIC in each region. 457 4.3. AIMD-Friendly Region 459 AIMD TCP performs well in certain types of networks, for example, 460 under short RTTs and small bandwidths (or small BDPs). In these 461 networks, CUBIC remains in the AIMD-friendly region to achieve at 462 least the same throughput as AIMD TCP. 464 The AIMD-friendly region is designed according to the analysis in 465 [FHP00], which studies the performance of an AIMD algorithm with an 466 additive factor of α__(aimd)_ (segments per _RTT_) and a 467 multiplicative factor of β__(aimd)_, denoted by AIMD(α__(aimd)_, 468 β__(aimd)_). Specifically, the average congestion window size of 469 AIMD(α__(aimd)_, β__(aimd)_) can be calculated using Figure 3. The 470 analysis shows that AIMD(α__(aimd)_, β__(aimd)_) with 472 1 - β 473 cubic 474 α = 3 * ---------- 475 aimd 1 + β 476 cubic 478 achieves the same average window size as AIMD TCP that uses AIMD(1, 479 0.5). 481 ___________________ 482 /α * (1 + β ) 483 / aimd aimd 484 AVG_AIMD(α , β ) = | / ------------------- 485 aimd aimd | / 2 * (1 - β ) * p 486 |/ aimd 488 Figure 3 490 Based on the above analysis, CUBIC uses Figure 4 to estimate the 491 window size _W_(est)_ of AIMD(α__(aimd)_, β__(aimd)_) with 493 1 - β 494 cubic 495 α = 3 * ---------- 496 aimd 1 + β 497 cubic 499 β = β 500 aimd cubic 502 which achieves the same average window size as AIMD TCP. When 503 receiving an ACK in congestion avoidance (where _cwnd_ could be 504 greater than or less than _W_(max)_), CUBIC checks whether 505 W_(cubic)(_t_) is less than _W_(est)_. If so, CUBIC is in the AIMD- 506 friendly region and _cwnd_ SHOULD be set to _W_(est)_ at each 507 reception of an ACK. 509 _W_(est)_ is set equal to _cwnd_(start)_ at the start of the 510 congestion avoidance stage. After that, on every ACK, _W_(est)_ is 511 updated using Figure 4. 513 segments_acked 514 W = W + α * -------------- 515 est est aimd cwnd 517 Figure 4 519 Note that once _W_(est)_ reaches _W_(max)_, that is, _W_(est)_ >= 520 _W_(max)_, α__(aimd)_ SHOULD be set to 1 to achieve the same 521 congestion window increment as AIMD TCP, which uses AIMD(1, 0.5). 523 4.4. Concave Region 525 When receiving an ACK in congestion avoidance, if CUBIC is not in the 526 AIMD-friendly region and _cwnd_ is less than _W_(max)_, then CUBIC is 527 in the concave region. In this region, _cwnd_ MUST be incremented by 529 target - cwnd 530 ------------- 531 cwnd 533 for each received ACK, where _target_ is calculated as described in 534 Section 4.2. 536 4.5. Convex Region 538 When receiving an ACK in congestion avoidance, if CUBIC is not in the 539 AIMD-friendly region and _cwnd_ is larger than or equal to _W_(max)_, 540 then CUBIC is in the convex region. 542 The convex region indicates that the network conditions might have 543 changed since the last congestion event, possibly implying more 544 available bandwidth after some flow departures. Since the Internet 545 is highly asynchronous, some amount of perturbation is always 546 possible without causing a major change in available bandwidth. 548 In this region, CUBIC is very careful. The convex profile ensures 549 that the window increases very slowly at the beginning and gradually 550 increases its increase rate. We also call this region the "maximum 551 probing phase", since CUBIC is searching for a new _W_(max)_. In this 552 region, _cwnd_ MUST be incremented by 554 target - cwnd 555 ------------- 556 cwnd 558 for each received ACK, where _target_ is calculated as described in 559 Section 4.2. 561 4.6. Multiplicative Decrease 563 When a packet loss is detected by duplicate ACKs or by receiving 564 packets carrying ECE flags, CUBIC updates _W_(max)_ and reduces 565 _cwnd_ and _ssthresh_ immediately as described below. An 566 implementation MAY set a smaller _ssthresh_ than suggested below to 567 accommodate rate-limited applications as described in [RFC7661]. For 568 both packet loss and congestion detection through ECN, the sender MAY 569 employ a Fast Recovery algorithm to gradually adjust the congestion 570 window to its new reduced _ssthresh_ value. The parameter 571 β__(cubic)_ SHOULD be set to 0.7. 573 ssthresh = cwnd * β // new slow-start threshold 574 cubic 576 ssthresh = max(ssthresh, 2) // threshold is at least 2 MSS 578 // window reduction 579 cwnd = ssthresh 581 A side effect of setting β__(cubic)_ to a value bigger than 0.5 is 582 slower convergence. We believe that while a more adaptive setting of 583 β__(cubic)_ could result in faster convergence, it will make the 584 analysis of CUBIC much harder. 586 4.7. Fast Convergence 588 To improve convergence speed, CUBIC uses a heuristic. When a new 589 flow joins the network, existing flows need to give up some of their 590 bandwidth to allow the new flow some room for growth, if the existing 591 flows have been using all the network bandwidth. To speed up this 592 bandwidth release by existing flows, the following "Fast Convergence" 593 mechanism SHOULD be implemented. 595 With Fast Convergence, when a congestion event occurs, we update 596 _W_(max)_ as follows, before the window reduction as described in 597 Section 4.6. 599 / 600 | 1 + β 601 | cubic if cwnd < W and fast convergence is enabled, 602 |cwnd * ---------- max 603 | 2 604 W = < 605 max | further reduce W 606 | max 607 | 608 | otherwise, remember cwnd before reduction 609 \cwnd 611 At a congestion event, if the current _cwnd_ is less than _W_(max)_, 612 this indicates that the saturation point experienced by this flow is 613 getting reduced because of a change in available bandwidth. Then we 614 allow this flow to release more bandwidth by reducing _W_(max)_ 615 further. This action effectively lengthens the time for this flow to 616 increase its congestion window, because the reduced _W_(max)_ forces 617 the flow to plateau earlier. This allows more time for the new flow 618 to catch up to its congestion window size. 620 Fast Convergence is designed for network environments with multiple 621 CUBIC flows. In network environments with only a single CUBIC flow 622 and without any other traffic, Fast Convergence SHOULD be disabled. 624 4.8. Timeout 626 In case of a timeout, CUBIC follows AIMD TCP to reduce _cwnd_ 627 [RFC5681], but sets _ssthresh_ using β__(cubic)_ (same as in 628 Section 4.6) in a way that is different from AIMD TCP [RFC5681]. 630 During the first congestion avoidance stage after a timeout, CUBIC 631 increases its congestion window size using Figure 1, where _t_ is the 632 elapsed time since the beginning of the current congestion avoidance, 633 _K_ is set to 0, and _W_(max)_ is set to the congestion window size 634 at the beginning of the current congestion avoidance stage. In 635 addition, for the AIMD-friendly region, _W_(est)_ SHOULD be set to 636 the congestion window size at the beginning of the current congestion 637 avoidance. 639 4.9. Spurious Congestion Events 641 In cases where CUBIC reduces its congestion window in response to 642 having detected packet loss via duplicate ACKs or timeouts, there is 643 a possibility that the missing ACK would arrive after the congestion 644 window reduction and a corresponding packet retransmission. For 645 example, packet reordering could trigger this behavior. A high 646 degree of packet reordering could cause multiple congestion window 647 reduction events, where spurious losses are incorrectly interpreted 648 as congestion signals, thus degrading CUBIC's performance 649 significantly. 651 When there is a congestion event, a CUBIC implementation SHOULD save 652 the current value of the following variables before the congestion 653 window reduction. 655 prior_cwnd = cwnd 657 prior_ssthresh = ssthresh 659 prior_W = W 660 max max 662 prior_K = K 664 prior_epoch = epoch 665 start start 667 prior_W_{est} = W 668 est 670 CUBIC MAY implement an algorithm to detect spurious retransmissions, 671 such as DSACK [RFC3708], Forward RTO-Recovery [RFC5682] or Eifel 672 [RFC3522]. Once a spurious congestion event is detected, CUBIC 673 SHOULD restore the original values of above mentioned variables as 674 follows if the current _cwnd_ is lower than _prior_cwnd_. Restoring 675 the original values ensures that CUBIC's performance is similar to 676 what it would be without spurious losses. 678 \ 679 cwnd = prior_cwnd | 680 | 681 ssthresh = prior_ssthresh | 682 | 683 W = prior_W | 684 max max | 685 >if cwnd < prior_cwnd 686 K = prior_K | 687 | 688 epoch = prior_epoch | 689 start start| 690 | 691 W = prior_W | 692 est est / 694 In rare cases, when the detection happens long after a spurious loss 695 event and the current _cwnd_ is already higher than _prior_cwnd_, 696 CUBIC SHOULD continue to use the current and the most recent values 697 of these variables. 699 4.10. Slow Start 701 CUBIC MUST employ a slow-start algorithm, when _cwnd_ is no more than 702 _ssthresh_. Among the slow-start algorithms, CUBIC MAY choose the 703 AIMD TCP slow start [RFC5681] in general networks, or the limited 704 slow start [RFC3742] or hybrid slow start [HR08] for fast and long- 705 distance networks. 707 When CUBIC uses hybrid slow start [HR08], it may exit the first slow 708 start without incurring any packet loss and thus _W_(max)_ is 709 undefined. In this special case, CUBIC switches to congestion 710 avoidance and increases its congestion window size using Figure 1, 711 where _t_ is the elapsed time since the beginning of the current 712 congestion avoidance, _K_ is set to 0, and _W_(max)_ is set to the 713 congestion window size at the beginning of the current congestion 714 avoidance stage. 716 5. Discussion 718 In this section, we further discuss the safety features of CUBIC 719 following the guidelines specified in [RFC5033]. 721 With a deterministic loss model where the number of packets between 722 two successive packet losses is always _1/p_, CUBIC always operates 723 with the concave window profile, which greatly simplifies the 724 performance analysis of CUBIC. The average window size of CUBIC can 725 be obtained by the following function: 727 ________________ ____ 728 /C * (3 + β ) 3 / 4 729 4 / cubic |/ RTT 730 AVG_W = | / ---------------- * ------- 731 cubic | / 4 * (1 - β ) __ 732 |/ cubic 3 / 4 733 |/ p 735 Figure 5 737 With β__(cubic)_ set to 0.7, the above formula reduces to: 739 ____ 740 _______ 3 / 4 741 4 /C * 3.7 |/ RTT 742 AVG_W = | / ------- * ------- 743 cubic |/ 1.2 __ 744 3 / 4 745 |/ p 747 Figure 6 749 We will determine the value of _C_ in the following subsection using 750 Figure 6. 752 5.1. Fairness to AIMD TCP 754 In environments where AIMD TCP is able to make reasonable use of the 755 available bandwidth, CUBIC does not significantly change this state. 757 AIMD TCP performs well in the following two types of networks: 759 1. networks with a small bandwidth-delay product (BDP) 761 2. networks with a short RTTs, but not necessarily a small BDP 763 CUBIC is designed to behave very similarly to AIMD TCP in the above 764 two types of networks. The following two tables show the average 765 window sizes of AIMD TCP, HSTCP, and CUBIC. The average window sizes 766 of AIMD TCP and HSTCP are from [RFC3649]. The average window size of 767 CUBIC is calculated using Figure 6 and the CUBIC AIMD-friendly region 768 for three different values of _C_. 770 +=============+=======+========+================+=========+========+ 771 | Loss Rate P | AIMD | HSTCP | CUBIC (C=0.04) | CUBIC | CUBIC | 772 | | | | | (C=0.4) | (C=4) | 773 +=============+=======+========+================+=========+========+ 774 | 1.0e-02 | 12 | 12 | 12 | 12 | 12 | 775 +-------------+-------+--------+----------------+---------+--------+ 776 | 1.0e-03 | 38 | 38 | 38 | 38 | 59 | 777 +-------------+-------+--------+----------------+---------+--------+ 778 | 1.0e-04 | 120 | 263 | 120 | 187 | 333 | 779 +-------------+-------+--------+----------------+---------+--------+ 780 | 1.0e-05 | 379 | 1795 | 593 | 1054 | 1874 | 781 +-------------+-------+--------+----------------+---------+--------+ 782 | 1.0e-06 | 1200 | 12280 | 3332 | 5926 | 10538 | 783 +-------------+-------+--------+----------------+---------+--------+ 784 | 1.0e-07 | 3795 | 83981 | 18740 | 33325 | 59261 | 785 +-------------+-------+--------+----------------+---------+--------+ 786 | 1.0e-08 | 12000 | 574356 | 105383 | 187400 | 333250 | 787 +-------------+-------+--------+----------------+---------+--------+ 789 Table 1: AIMD TCP, HSTCP, and CUBIC with RTT = 0.1 seconds 791 Table 1 describes the response function of AIMD TCP, HSTCP, and CUBIC 792 in networks with _RTT_ = 0.1 seconds. The average window size is in 793 MSS-sized segments. 795 +=============+=======+========+================+=========+=======+ 796 | Loss Rate P | AIMD | HSTCP | CUBIC (C=0.04) | CUBIC | CUBIC | 797 | | | | | (C=0.4) | (C=4) | 798 +=============+=======+========+================+=========+=======+ 799 | 1.0e-02 | 12 | 12 | 12 | 12 | 12 | 800 +-------------+-------+--------+----------------+---------+-------+ 801 | 1.0e-03 | 38 | 38 | 38 | 38 | 38 | 802 +-------------+-------+--------+----------------+---------+-------+ 803 | 1.0e-04 | 120 | 263 | 120 | 120 | 120 | 804 +-------------+-------+--------+----------------+---------+-------+ 805 | 1.0e-05 | 379 | 1795 | 379 | 379 | 379 | 806 +-------------+-------+--------+----------------+---------+-------+ 807 | 1.0e-06 | 1200 | 12280 | 1200 | 1200 | 1874 | 808 +-------------+-------+--------+----------------+---------+-------+ 809 | 1.0e-07 | 3795 | 83981 | 3795 | 5926 | 10538 | 810 +-------------+-------+--------+----------------+---------+-------+ 811 | 1.0e-08 | 12000 | 574356 | 18740 | 33325 | 59261 | 812 +-------------+-------+--------+----------------+---------+-------+ 814 Table 2: AIMD TCP, HSTCP, and CUBIC with RTT = 0.01 seconds 816 Table 2 describes the response function of AIMD TCP, HSTCP, and CUBIC 817 in networks with _RTT_ = 0.01 seconds. The average window size is in 818 MSS-sized segments. 820 Both tables show that CUBIC with any of these three _C_ values is 821 more friendly to AIMD TCP than HSTCP, especially in networks with a 822 short _RTT_ where AIMD TCP performs reasonably well. For example, in 823 a network with _RTT_ = 0.01 seconds and p=10^-6, AIMD TCP has an 824 average window of 1200 packets. If the packet size is 1500 bytes, 825 then AIMD TCP can achieve an average rate of 1.44 Gbps. In this 826 case, CUBIC with _C_=0.04 or _C_=0.4 achieves exactly the same rate 827 as AIMD TCP, whereas HSTCP is about ten times more aggressive than 828 AIMD TCP. 830 We can see that _C_ determines the aggressiveness of CUBIC in 831 competing with other congestion control algorithms for bandwidth. 832 CUBIC is more friendly to AIMD TCP, if the value of _C_ is lower. 833 However, we do not recommend setting _C_ to a very low value like 834 0.04, since CUBIC with a low _C_ cannot efficiently use the bandwidth 835 in fast and long-distance networks. Based on these observations and 836 extensive deployment experience, we find _C_=0.4 gives a good balance 837 between AIMD- friendliness and aggressiveness of window increase. 838 Therefore, _C_ SHOULD be set to 0.4. With _C_ set to 0.4, Figure 6 839 is reduced to: 841 ____ 842 3 / 4 843 |/ RTT 844 AVG_W = 1.054 * ------- 845 cubic __ 846 3 / 4 847 |/ p 849 Figure 7 851 Figure 7 is then used in the next subsection to show the scalability 852 of CUBIC. 854 5.2. Using Spare Capacity 856 CUBIC uses a more aggressive window increase function than AIMD TCP 857 for fast and long-distance networks. 859 The following table shows that to achieve the 10 Gbps rate, AIMD TCP 860 requires a packet loss rate of 2.0e-10, while CUBIC requires a packet 861 loss rate of 2.9e-8. 863 +===================+===========+=========+=========+=========+ 864 | Throughput (Mbps) | Average W | AIMD P | HSTCP P | CUBIC P | 865 +===================+===========+=========+=========+=========+ 866 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | 867 +-------------------+-----------+---------+---------+---------+ 868 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | 869 +-------------------+-----------+---------+---------+---------+ 870 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | 871 +-------------------+-----------+---------+---------+---------+ 872 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | 873 +-------------------+-----------+---------+---------+---------+ 874 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | 875 +-------------------+-----------+---------+---------+---------+ 877 Table 3: Required packet loss rate for AIMD TCP, HSTCP, and 878 CUBIC to achieve a certain throughput 880 Table 3 describes the required packet loss rate for AIMD TCP, HSTCP, 881 and CUBIC to achieve a certain throughput. We use 1500-byte packets 882 and an _RTT_ of 0.1 seconds. 884 Our test results in [HKLRX06] indicate that CUBIC uses the spare 885 bandwidth left unused by existing AIMD TCP flows in the same 886 bottleneck link without taking away much bandwidth from the existing 887 flows. 889 5.3. Difficult Environments 891 CUBIC is designed to remedy the poor performance of AIMD TCP in fast 892 and long-distance networks. 894 5.4. Investigating a Range of Environments 896 CUBIC has been extensively studied by using both NS-2 simulation and 897 testbed experiments, covering a wide range of network environments. 898 More information can be found in [HKLRX06]. Additionally, there is 899 decade-long deployment experience with CUBIC on the Internet. 901 Same as AIMD TCP, CUBIC is a loss-based congestion control algorithm. 902 Because CUBIC is designed to be more aggressive (due to a faster 903 window increase function and bigger multiplicative decrease factor) 904 than AIMD TCP in fast and long-distance networks, it can fill large 905 drop-tail buffers more quickly than AIMD TCP and increases the risk 906 of a standing queue [RFC8511]. In this case, proper queue sizing and 907 management [RFC7567] could be used to reduce the packet queuing 908 delay. 910 5.5. Protection against Congestion Collapse 912 With regard to the potential of causing congestion collapse, CUBIC 913 behaves like AIMD TCP, since CUBIC modifies only the window 914 adjustment algorithm of AIMD TCP. Thus, it does not modify the ACK 915 clocking and timeout behaviors of AIMD TCP. 917 5.6. Fairness within the Alternative Congestion Control Algorithm 919 CUBIC ensures convergence of competing CUBIC flows with the same RTT 920 in the same bottleneck links to an equal throughput. When competing 921 flows have different RTT values, their throughput ratio is linearly 922 proportional to the inverse of their RTT ratios. This is true 923 independently of the level of statistical multiplexing on the link. 925 5.7. Performance with Misbehaving Nodes and Outside Attackers 927 This is not considered in the current CUBIC design. 929 5.8. Behavior for Application-Limited Flows 931 CUBIC does not increase its congestion window size if a flow is 932 currently limited by the application instead of the congestion 933 window. In case of long periods during which _cwnd_ has not been 934 updated due to such an application limit, such as idle periods, _t_ 935 in Figure 1 MUST NOT include these periods; otherwise, W_(cubic)(_t_) 936 might be very high after restarting from these periods. 938 5.9. Responses to Sudden or Transient Events 940 If there is a sudden congestion, a routing change, or a mobility 941 event, CUBIC behaves the same as AIMD TCP. 943 5.10. Incremental Deployment 945 CUBIC requires only changes to TCP senders, and it does not require 946 any changes at TCP receivers. That is, a CUBIC sender works 947 correctly with the AIMD TCP receivers. In addition, CUBIC does not 948 require any changes to routers and does not require any assistance 949 from routers. 951 6. Security Considerations 953 CUBIC makes no changes to the underlying security of TCP. More 954 information about TCP security concerns can be found in [RFC5681]. 956 7. IANA Considerations 958 This document does not require any IANA actions. 960 8. References 962 8.1. Normative References 964 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 965 Requirement Levels", BCP 14, RFC 2119, 966 DOI 10.17487/RFC2119, March 1997, 967 . 969 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 970 of Explicit Congestion Notification (ECN) to IP", 971 RFC 3168, DOI 10.17487/RFC3168, September 2001, 972 . 974 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 975 Control Algorithms", BCP 133, RFC 5033, 976 DOI 10.17487/RFC5033, August 2007, 977 . 979 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 980 Friendly Rate Control (TFRC): Protocol Specification", 981 RFC 5348, DOI 10.17487/RFC5348, September 2008, 982 . 984 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 985 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 986 . 988 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 989 "Computing TCP's Retransmission Timer", RFC 6298, 990 DOI 10.17487/RFC6298, June 2011, 991 . 993 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 994 NewReno Modification to TCP's Fast Recovery Algorithm", 995 RFC 6582, DOI 10.17487/RFC6582, April 2012, 996 . 998 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 999 and Y. Nishida, "A Conservative Loss Recovery Algorithm 1000 Based on Selective Acknowledgment (SACK) for TCP", 1001 RFC 6675, DOI 10.17487/RFC6675, August 2012, 1002 . 1004 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 1005 Recommendations Regarding Active Queue Management", 1006 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 1007 . 1009 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1010 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1011 May 2017, . 1013 8.2. Informative References 1015 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic 1016 Ordering for Internet Congestion Control and its 1017 Applications", IEEE INFOCOM 2007 - 26th IEEE International 1018 Conference on Computer Communications, 1019 DOI 10.1109/infcom.2007.111, 2007, 1020 . 1022 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of 1023 Equation-Based and AIMD Congestion Control", May 2000, 1024 . 1026 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary 1027 Adjustment Algorithms", Technical Report TR2002-29, 1028 Department of Computer Sciences, The University of 1029 Texas at Austin, 11 August 2002, 1030 . 1032 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step 1033 toward Realistic Performance Evaluation of High-Speed TCP 1034 Variants", International Workshop on Protocols for Fast 1035 Long-Distance Networks, February 2006, 1036 . 1038 [HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth 1039 and Long-Distance Networks", International Workshop 1040 on Protocols for Fast Long-Distance Networks, March 2008, 1041 . 1044 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly 1045 high-speed TCP variant", ACM SIGOPS Operating Systems 1046 Review Vol. 42, pp. 64-74, DOI 10.1145/1400097.1400105, 1047 July 2008, . 1049 [K03] Kelly, T., "Scalable TCP: improving performance in 1050 highspeed wide area networks", ACM SIGCOMM Computer 1051 Communication Review Vol. 33, pp. 83-91, 1052 DOI 10.1145/956981.956989, April 2003, 1053 . 1055 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 1056 for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, 1057 . 1059 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 1060 RFC 3649, DOI 10.17487/RFC3649, December 2003, 1061 . 1063 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 1064 Acknowledgement (DSACKs) and Stream Control Transmission 1065 Protocol (SCTP) Duplicate Transmission Sequence Numbers 1066 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 1067 DOI 10.17487/RFC3708, February 2004, 1068 . 1070 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 1071 Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March 1072 2004, . 1074 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1075 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1076 . 1078 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 1079 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 1080 Spurious Retransmission Timeouts with TCP", RFC 5682, 1081 DOI 10.17487/RFC5682, September 2009, 1082 . 1084 [RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating 1085 TCP to Support Rate-Limited Traffic", RFC 7661, 1086 DOI 10.17487/RFC7661, October 2015, 1087 . 1089 [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 1090 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 1091 RFC 8312, DOI 10.17487/RFC8312, February 2018, 1092 . 1094 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 1095 "TCP Alternative Backoff with ECN (ABE)", RFC 8511, 1096 DOI 10.17487/RFC8511, December 2018, 1097 . 1099 [SXEZ19] Sun, W., Xu, L., Elbaum, S., and D. Zhao, "Model-Agnostic 1100 and Efficient Exploration of Numerical State Space of 1101 Real-World TCP Congestion Control Implementations", USENIX 1102 NSDI 2019, February 2019, 1103 . 1105 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase 1106 Congestion Control (BIC) for Fast Long-Distance Networks", 1107 IEEE INFOCOM 2004, DOI 10.1109/infcom.2004.1354672, March 1108 2004, . 1110 Appendix A. Acknowledgements 1112 Richard Scheffenegger and Alexander Zimmermann originally co-authored 1113 [RFC8312]. 1115 Appendix B. Evolution of CUBIC 1117 B.1. Since draft-eggert-tcpm-rfc8312bis-03 1119 * fix spelling nits 1121 * rename to draft-ietf 1123 B.2. Since draft-eggert-tcpm-rfc8312bis-02 1125 * add definition for segments_acked and alpha__(aimd)_. (#47 1126 (https://github.com/NTAP/rfc8312bis/issues/47)) 1128 * fix a mistake in _W_(max)_ calculation in the fast convergence 1129 section. (#51 (https://github.com/NTAP/rfc8312bis/issues/51)) 1131 * clarity on setting _ssthresh_ and _cwnd_(start)_ during 1132 multiplicative decrease. (#53 (https://github.com/NTAP/rfc8312bis/ 1133 issues/53)) 1135 B.3. Since draft-eggert-tcpm-rfc8312bis-01 1137 * rename TCP-Friendly to AIMD-Friendly and rename Standard TCP to 1138 AIMD TCP to avoid confusion as CUBIC has been widely used in the 1139 Internet. (#38 (https://github.com/NTAP/rfc8312bis/issues/38)) 1141 * change introductory text to reflect the significant broader 1142 deployment of CUBIC in the Internet. (#39 1143 (https://github.com/NTAP/rfc8312bis/issues/39)) 1145 * rephrase introduction to avoid referring to variables that have 1146 not been defined yet. 1148 B.4. Since draft-eggert-tcpm-rfc8312bis-00 1150 * acknowledge former co-authors (#15 1151 (https://github.com/NTAP/rfc8312bis/issues/15)) 1153 * prevent _cwnd_ from becoming less than two (#7 1154 (https://github.com/NTAP/rfc8312bis/issues/7)) 1156 * add list of variables and constants (#5 1157 (https://github.com/NTAP/rfc8312bis/issues/5), #6 1158 (https://github.com/NTAP/rfc8312bis/issues/6)) 1160 * update _K_'s definition and add bounds for CUBIC _target_ _cwnd_ 1161 [SXEZ19] (#1 (https://github.com/NTAP/rfc8312bis/issues/1), #14 1162 (https://github.com/NTAP/rfc8312bis/issues/14)) 1164 * update _W_(est)_ to use AIMD approach (#20 1165 (https://github.com/NTAP/rfc8312bis/issues/20)) 1167 * set alpha__(aimd)_ to 1 once _W_(est)_ reaches _W_(max)_ (#2 1168 (https://github.com/NTAP/rfc8312bis/issues/2)) 1170 * add Vidhi as co-author (#17 (https://github.com/NTAP/rfc8312bis/ 1171 issues/17)) 1173 * note for Fast Recovery during _cwnd_ decrease due to congestion 1174 event (#11 (https://github.com/NTAP/rfc8312bis/issues/11)) 1176 * add section for spurious congestion events (#23 1177 (https://github.com/NTAP/rfc8312bis/issues/23)) 1179 * initialize _W_(est)_ after timeout and remove variable 1180 _W_(last_max)_ (#28 (https://github.com/NTAP/rfc8312bis/ 1181 issues/28)) 1183 B.5. Since RFC8312 1185 * converted to Markdown and xml2rfc v3 1187 * updated references (as part of the conversion) 1188 * updated author information 1190 * various formatting changes 1192 * move to Standards Track 1194 B.6. Since the Original Paper 1196 CUBIC has gone through a few changes since the initial release 1197 [HRX08] of its algorithm and implementation. Below we highlight the 1198 differences between its original paper and [RFC8312]. 1200 * The original paper [HRX08] includes the pseudocode of CUBIC 1201 implementation using Linux's pluggable congestion control 1202 framework, which excludes system-specific optimizations. The 1203 simplified pseudocode might be a good source to start with and 1204 understand CUBIC. 1206 * [HRX08] also includes experimental results showing its performance 1207 and fairness. 1209 * The definition of beta__(cubic)_ constant was changed in 1210 [RFC8312]. For example, beta__(cubic)_ in the original paper was 1211 the window decrease constant while [RFC8312] changed it to CUBIC 1212 multiplication decrease factor. With this change, the current 1213 congestion window size after a congestion event in [RFC8312] was 1214 beta__(cubic)_ * _W_(max)_ while it was (1-beta__(cubic)_) * 1215 _W_(max)_ in the original paper. 1217 * Its pseudocode used _W_(last_max)_ while [RFC8312] used _W_(max)_. 1219 * Its AIMD-friendly window was W_(tcp) while [RFC8312] used 1220 _W_(est)_. 1222 Authors' Addresses 1224 Lisong Xu 1225 University of Nebraska-Lincoln 1226 Department of Computer Science and Engineering 1227 Lincoln, NE 68588-0115 1228 United States of America 1230 Email: xu@unl.edu 1231 URI: https://cse.unl.edu/~xu/ 1232 Sangtae Ha 1233 University of Colorado at Boulder 1234 Department of Computer Science 1235 Boulder, CO 80309-0430 1236 United States of America 1238 Email: sangtae.ha@colorado.edu 1239 URI: https://netstech.org/sangtaeha/ 1241 Injong Rhee 1242 Bowery Farming 1243 151 W 26TH Street, 12TH Floor 1244 New York, NY 10001 1245 United States of America 1247 Email: injongrhee@gmail.com 1249 Vidhi Goel 1250 Apple Inc. 1251 One Apple Park Way 1252 Cupertino, California 95014 1253 United States of America 1255 Email: vidhi_goel@apple.com 1257 Lars Eggert (editor) 1258 NetApp 1259 Stenbergintie 12 B 1260 FI-02700 Kauniainen 1261 Finland 1263 Email: lars@eggert.org 1264 URI: https://eggert.org/