idnits 2.17.1 draft-eggert-tcpm-rfc8312bis-02.txt: -(564): 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 28 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 481 has weird spacing: '... aimd aimd...' == Line 496 has weird spacing: '... aimd cub...' == Line 511 has weird spacing: '... est est...' == Line 650 has weird spacing: '... max max...' -- The document date (22 February 2021) is 1152 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 (~~), 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: 26 August 2021 I. Rhee 7 Bowery 8 V. Goel 9 Apple Inc. 10 L. Eggert, Ed. 11 NetApp 12 22 February 2021 14 CUBIC for Fast and Long-Distance Networks 15 draft-eggert-tcpm-rfc8312bis-02 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 a 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 Linux, Windows, and Apple 26 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 26 August 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 . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 8 89 4.3. AIMD-Friendly Region . . . . . . . . . . . . . . . . . . 10 90 4.4. Concave Region . . . . . . . . . . . . . . . . . . . . . 12 91 4.5. Convex Region . . . . . . . . . . . . . . . . . . . . . . 12 92 4.6. Multiplicative Decrease . . . . . . . . . . . . . . . . . 12 93 4.7. Fast Convergence . . . . . . . . . . . . . . . . . . . . 13 94 4.8. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 4.9. Spurious Congestion Events . . . . . . . . . . . . . . . 14 96 4.10. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 15 98 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 5.1. Fairness to AIMD TCP . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . 20 104 5.6. Fairness within the Alternative Congestion Control 105 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 20 106 5.7. Performance with Misbehaving Nodes and Outside 107 Attackers . . . . . . . . . . . . . . . . . . . . . . . 20 108 5.8. Behavior for Application-Limited Flows . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . 21 113 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 114 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 115 8.2. Informative References . . . . . . . . . . . . . . . . . 22 116 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 117 Appendix B. Evolution of CUBIC . . . . . . . . . . . . . . . . . 24 118 B.1. Since draft-eggert-tcpm-rfc8312bis-01 . . . . . . . . . . 24 119 B.2. Since draft-eggert-tcpm-rfc8312bis-00 . . . . . . . . . . 25 120 B.3. Since RFC8312 . . . . . . . . . . . . . . . . . . . . . . 25 121 B.4. Since the Original Paper . . . . . . . . . . . . . . . . 26 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 124 1. Introduction 126 The low utilization problem of traditional TCP in fast and long- 127 distance networks is well documented in [K03] and [RFC3649]. This 128 problem arises from a slow increase of the congestion window 129 following a congestion event in a network with a large bandwidth- 130 delay product (BDP). [HKLRX06] indicates that this problem is 131 frequently observed even in the range of congestion window sizes over 132 several hundreds of packets. This problem is equally applicable to 133 all Reno-style TCP standards and their variants, including TCP-Reno 134 [RFC5681], TCP-NewReno [RFC6582][RFC6675], SCTP [RFC4960], and TFRC 135 [RFC5348], which use the same linear increase function for window 136 growth. We refer to all Reno-style TCP standards and their variants 137 collectively as "AIMD TCP" below because they use the Additive 138 Increase and Multiplicative Decrease algorithm (AIMD). 140 CUBIC, originally proposed in [HRX08], is a modification to the 141 congestion control algorithm of traditional AIMD TCP to remedy this 142 problem. This document describes the most recent specification of 143 CUBIC. Specifically, CUBIC uses a cubic function instead of a linear 144 window increase function of AIMD TCP to improve scalability and 145 stability under and long-distance networks. 147 Binary Increase Congestion Control (BIC-TCP) [XHR04], a predecessor 148 of CUBIC, was selected as the default TCP congestion control 149 algorithm by Linux in the year 2005 and had been used for several 150 years by the Internet community at large. 152 CUBIC uses a similar window increase function as BIC-TCP and is 153 designed to be less aggressive and fairer to AIMD TCP in bandwidth 154 usage than BIC-TCP while maintaining the strengths of BIC-TCP such as 155 stability, window scalability, and round-trip time (RTT) fairness. 156 CUBIC has been adopted as the default TCP congestion control 157 algorithm in Linux, Windows, and Apple stacks, and has been used and 158 deployed globally. Extensive, decade-long deployment experience in 159 vastly different Internet scenarios has convincingly demonstrated 160 that CUBIC is safe for deployment on the global Internet and delivers 161 substantial benefits over traditional AIMD congestion control. It is 162 therefore to be regarded as the current standard for TCP congestion 163 control. 165 In the following sections, we first briefly explain the design 166 principles of CUBIC, then provide the exact specification of CUBIC, 167 and finally discuss the safety features of CUBIC following the 168 guidelines specified in [RFC5033]. 170 2. Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in 175 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 3. Design Principles of CUBIC 180 CUBIC is designed according to the following design principles: 182 Principle 1: For better network utilization and stability, CUBIC 183 uses both the concave and convex profiles of a cubic function to 184 increase the congestion window size, instead of using just a 185 convex function. 187 Principle 2: To be AIMD-friendly, CUBIC is designed to behave like 188 AIMD TCP in networks with short RTTs and small bandwidth where 189 AIMD TCP performs well. 191 Principle 3: For RTT-fairness, CUBIC is designed to achieve linear 192 bandwidth sharing among flows with different RTTs. 194 Principle 4: CUBIC appropriately sets its multiplicative window 195 decrease factor in order to balance between the scalability and 196 convergence speed. 198 3.1. Principle 1 for the CUBIC Increase Function 200 For better network utilization and stability, CUBIC [HRX08] uses a 201 cubic window increase function in terms of the elapsed time from the 202 last congestion event. While most alternative congestion control 203 algorithms to AIMD TCP increase the congestion window using convex 204 functions, CUBIC uses both the concave and convex profiles of a cubic 205 function for window growth. 207 After a window reduction in response to a congestion event is 208 detected by duplicate ACKs or Explicit Congestion Notification-Echo 209 (ECN-Echo, ECE) ACKs [RFC3168], CUBIC remembers the congestion window 210 size where it received the congestion event and performs a 211 multiplicative decrease of the congestion window. When CUBIC enters 212 into congestion avoidance, it starts to increase the congestion 213 window using the concave profile of the cubic function. The cubic 214 function is set to have its plateau at the remembered congestion 215 window size, so that the concave window increase continues until 216 then. After that, the cubic function turns into a convex profile and 217 the convex window increase begins. 219 This style of window adjustment (concave and then convex) improves 220 the algorithm stability while maintaining high network utilization 221 [CEHRX07]. This is because the window size remains almost constant, 222 forming a plateau around the remembered congestion window size of the 223 last congestion event, where network utilization is deemed highest. 224 Under steady state, most window size samples of CUBIC are close to 225 that remembered congestion window size, thus promoting high network 226 utilization and stability. 228 Note that congestion control algorithms that only use convex 229 functions to increase the congestion window size have their maximum 230 increments around the remembered congestion window size of the last 231 congestion event, and thus introduce a large number of packet bursts 232 around the saturation point of the network, likely causing frequent 233 global loss synchronizations. 235 3.2. Principle 2 for AIMD Friendliness 237 CUBIC promotes per-flow fairness to AIMD TCP. Note that AIMD TCP 238 performs well over paths with short RTTs and small bandwidths (or 239 small BDPs). There is only a scalability problem in networks with 240 long RTTs and large bandwidths (or large BDPs). 242 A congestion control algorithm designed to be friendly to AIMD TCP on 243 a per-flow basis must increase its congestion window less 244 aggressively in small BDP networks than in large BDP networks. 246 The aggressiveness of CUBIC mainly depends on the maximum window size 247 before a window reduction, which is smaller in small-BDP networks 248 than in large-BDP networks. Thus, CUBIC increases its congestion 249 window less aggressively in small-BDP networks than in large-BDP 250 networks. 252 Furthermore, in cases when the cubic function of CUBIC would increase 253 the congestion window less aggressively than AIMD TCP, CUBIC simply 254 follows the window size of AIMD TCP to ensure that CUBIC achieves at 255 least the same throughput as AIMD TCP in small-BDP networks. We call 256 this region where CUBIC behaves like AIMD TCP the "AIMD-friendly 257 region". 259 3.3. Principle 3 for RTT Fairness 261 Two CUBIC flows with different RTTs have a throughput ratio that is 262 linearly proportional to the inverse of their RTT ratio, where the 263 throughput of a flow is approximately the size of its congestion 264 window divided by its RTT. 266 Specifically, CUBIC maintains a window increase rate independent of 267 RTTs outside of the AIMD-friendly region, and thus flows with 268 different RTTs have similar congestion window sizes under steady 269 state when they operate outside the AIMD-friendly region. 271 This notion of a linear throughput ratio is similar to that of AIMD 272 TCP under high statistical multiplexing where packet loss is 273 independent of individual flow rates. However, under low statistical 274 multiplexing, the throughput ratio of AIMD TCP flows with different 275 RTTs is quadratically proportional to the inverse of their RTT ratio 276 [XHR04]. 278 CUBIC always ensures a linear throughput ratio independent of the 279 amount of statistical multiplexing. This is an improvement over AIMD 280 TCP. While there is no consensus on particular throughput ratios for 281 different RTT flows, we believe that over wired Internet paths, use 282 of a linear throughput ratio seems more reasonable than equal 283 throughputs (i.e., the same throughput for flows with different RTTs) 284 or a higher-order throughput ratio (e.g., a quadratical throughput 285 ratio of AIMD TCP under low statistical multiplexing environments). 287 3.4. Principle 4 for the CUBIC Decrease Factor 289 To balance between scalability and convergence speed, CUBIC sets the 290 multiplicative window decrease factor to 0.7, whereas AIMD TCP uses 291 0.5. 293 While this improves the scalability of CUBIC, a side effect of this 294 decision is slower convergence, especially under low statistical 295 multiplexing. This design choice is following the observation that 296 HighSpeed TCP (HSTCP) [RFC3649] and other approaches (e.g., [GV02]) 297 made: the current Internet becomes more asynchronous with less 298 frequent loss synchronizations under high statistical multiplexing. 300 In such environments, even strict Multiplicative-Increase 301 Multiplicative-Decrease (MIMD) can converge. CUBIC flows with the 302 same RTT always converge to the same throughput independent of 303 statistical multiplexing, thus achieving intra-algorithm fairness. 304 We also find that in environments with sufficient statistical 305 multiplexing, the convergence speed of CUBIC is reasonable. 307 4. CUBIC Congestion Control 309 In this section, we discuss how the congestion window is updated 310 during the different stages of the CUBIC congestion controller. 312 4.1. Definitions 314 The unit of all window sizes in this document is segments of the 315 maximum segment size (MSS), and the unit of all times is seconds. 317 4.1.1. Constants of Interest 319 β__(cubic)_: CUBIC multiplication decrease factor as described in 320 Section 4.6. 322 _C_: constant that determines the aggressiveness of CUBIC in 323 competing with other congestion control algorithms in high BDP 324 networks. Please see Section 5 for more explanation on how it is 325 set. The unit for _C_ is 327 segment 328 ------- 329 3 330 second 332 4.1.2. Variables of Interest 334 This section defines the variables required to implement CUBIC: 336 _RTT_: Smoothed round-trip time in seconds, calculated as described 337 in [RFC6298]. 339 _cwnd_: Current congestion window in segments. 341 _ssthresh_: Current slow start threshold in segments. 343 _W_(max)_: Size of _cwnd_ in segments just before _cwnd_ was reduced 344 in the last congestion event. 346 _K_: The time period in seconds it takes to increase the congestion 347 window size at the beginning of the current congestion avoidance 348 stage to _W_(max)_. 350 _current_time_: Current time of the system in seconds. 352 _epoch_(start)_: The time in seconds at which the current congestion 353 avoidance stage started. 355 _cwnd_(start)_: The _cwnd_ at the beginning of the current congestion 356 avoidance stage, i.e., at time _epoch_(start)_. 358 W_(cubic)(_t_): The congestion window in segments at time _t_ in 359 seconds based on the cubic increase function, as described in 360 Section 4.2. 362 _target_: Target value of congestion window in segments after the 363 next RTT, that is, W_(cubic)(_t_ + _RTT_), as described in 364 Section 4.2. 366 _W_(est)_: An estimate for the congestion window in segments in the 367 AIMD-friendly region, that is, an estimate for the congestion window 368 of AIMD TCP. 370 4.2. Window Increase Function 372 CUBIC maintains the acknowledgment (ACK) clocking of AIMD TCP by 373 increasing the congestion window only at the reception of an ACK. It 374 does not make any changes to the TCP Fast Recovery and Fast 375 Retransmit algorithms [RFC6582][RFC6675]. 377 During congestion avoidance after a congestion event where a packet 378 loss is detected by duplicate ACKs or by receiving packets carrying 379 ECE flags [RFC3168], CUBIC changes the window increase function of 380 AIMD TCP. 382 CUBIC uses the following window increase function: 384 3 385 W (t) = C * (t - K) + W 386 cubic max 388 Figure 1 390 where _t_ is the elapsed time in seconds from the beginning of the 391 current congestion avoidance stage, that is, 393 t = current_time - epoch 394 start 396 and where _epoch_(start)_ is the time at which the current congestion 397 avoidance stage starts. _K_ is the time period that the above 398 function takes to increase the congestion window size at the 399 beginning of the current congestion avoidance stage to _W_(max)_ if 400 there are no further congestion events and is calculated using the 401 following equation: 403 ________________ 404 /W - cwnd 405 3 / max start 406 K = | / ---------------- 407 |/ C 409 Figure 2 411 where _cwnd_(start)_ is the congestion window at the beginning of the 412 current congestion avoidance stage. _cwnd_(start)_ is calculated as 413 described in Section 4.6 when a congestion event is detected, 414 although implementations can further adjust _cwnd_(start)_ based on 415 other Fast Recovery mechanisms. In special cases, if _cwnd_(start)_ 416 is greater than _W_(max)_, _K_ is set to 0. 418 Upon receiving an ACK during congestion avoidance, CUBIC computes the 419 _target_ congestion window size after the next _RTT_ using Figure 1 420 as follows, where _RTT_ is the smoothed round-trip time. The lower 421 and upper bounds below ensure that CUBIC's congestion window increase 422 rate is non-decreasing and is less than the increase rate of slow 423 start. 425 / 426 | if W (t + RTT) < cwnd 427 |cwnd cubic 428 | 429 | 430 | 431 target = < if W (t + RTT) > 1.5 * cwnd 432 |1.5 * cwnd cubic 433 | 434 | 435 |W (t + RTT) 436 | cubic otherwise 437 \ 439 Depending on the value of the current congestion window size _cwnd_, 440 CUBIC runs in three different regions: 442 1. The AIMD-friendly region, which ensures that CUBIC achieves at 443 least the same throughput as AIMD TCP. 445 2. The concave region, if CUBIC is not in the AIMD-friendly region 446 and _cwnd_ is less than _W_(max)_. 448 3. The convex region, if CUBIC is not in the AIMD-friendly region 449 and _cwnd_ is greater than _W_(max)_. 451 Below, we describe the exact actions taken by CUBIC in each region. 453 4.3. AIMD-Friendly Region 455 AIMD TCP performs well in certain types of networks, for example, 456 under short RTTs and small bandwidths (or small BDPs). In these 457 networks, CUBIC remains in the AIMD-friendly region to achieve at 458 least the same throughput as AIMD TCP. 460 The AIMD-friendly region is designed according to the analysis in 461 [FHP00], which studies the performance of an AIMD algorithm with an 462 additive factor of α__(aimd)_ (segments per _RTT_) and a 463 multiplicative factor of β__(aimd)_, denoted by AIMD(α__(aimd)_, 464 β__(aimd)_). Specifically, the average congestion window size of 465 AIMD(α__(aimd)_, β__(aimd)_) can be calculated using Figure 3. The 466 analysis shows that AIMD(α__(aimd)_, β__(aimd)_) with 468 1 - β 469 cubic 470 α = 3 * ---------- 471 aimd 1 + β 472 cubic 474 achieves the same average window size as AIMD TCP that uses AIMD(1, 475 0.5). 477 ___________________ 478 /α * (1 + β ) 479 / aimd aimd 480 AVG_AIMD(α , β ) = | / ------------------- 481 aimd aimd | / 2 * (1 - β ) * p 482 |/ aimd 484 Figure 3 486 Based on the above analysis, CUBIC uses Figure 4 to estimate the 487 window size _W_(est)_ of AIMD(α__(aimd)_, β__(aimd)_) with 489 1 - β 490 cubic 491 α = 3 * ---------- 492 aimd 1 + β 493 cubic 495 β = β 496 aimd cubic 498 which achieves the same average window size as AIMD TCP. When 499 receiving an ACK in congestion avoidance (where _cwnd_ could be 500 greater than or less than _W_(max)_), CUBIC checks whether 501 W_(cubic)(_t_) is less than _W_(est)_. If so, CUBIC is in the AIMD- 502 friendly region and _cwnd_ SHOULD be set to _W_(est)_ at each 503 reception of an ACK. 505 _W_(est)_ is set equal to _cwnd_ at the start of the congestion 506 avoidance stage. After that, on every ACK, _W_(est)_ is updated 507 using Figure 4. 509 segments_acked 510 W = W + α * -------------- 511 est est aimd cwnd 513 Figure 4 515 Note that once _W_(est)_ reaches _W_(max)_, that is, _W_(est)_ >= 516 _W_(max)_, α__(aimd)_ SHOULD be set to 1 to achieve the same 517 congestion window increment as AIMD TCP, which uses AIMD(1, 0.5). 519 4.4. Concave Region 521 When receiving an ACK in congestion avoidance, if CUBIC is not in the 522 AIMD-friendly region and _cwnd_ is less than _W_(max)_, then CUBIC is 523 in the concave region. In this region, _cwnd_ MUST be incremented by 525 target - cwnd 526 ------------- 527 cwnd 529 for each received ACK, where _target_ is calculated as described in 530 Section 4.2. 532 4.5. Convex Region 534 When receiving an ACK in congestion avoidance, if CUBIC is not in the 535 AIMD-friendly region and _cwnd_ is larger than or equal to _W_(max)_, 536 then CUBIC is in the convex region. 538 The convex region indicates that the network conditions might have 539 changed since the last congestion event, possibly implying more 540 available bandwidth after some flow departures. Since the Internet 541 is highly asynchronous, some amount of perturbation is always 542 possible without causing a major change in available bandwidth. 544 In this region, CUBIC is very careful. The convex profile ensures 545 that the window increases very slowly at the beginning and gradually 546 increases its increase rate. We also call this region the "maximum 547 probing phase", since CUBIC is searching for a new _W_(max)_. In this 548 region, _cwnd_ MUST be incremented by 550 target - cwnd 551 ------------- 552 cwnd 554 for each received ACK, where _target_ is calculated as described in 555 Section 4.2. 557 4.6. Multiplicative Decrease 559 When a packet loss is detected by duplicate ACKs or by receiving 560 packets carrying ECE flags, CUBIC updates _W_(max)_ and reduces 561 _cwnd_ and _ssthresh_ immediately as described below. For both 562 packet loss and congestion detection through ECN, the sender MAY 563 employ a Fast Recovery algorithm to gradually adjust the congestion 564 window to its new reduced value. The parameter β__(cubic)_ SHOULD be 565 set to 0.7. 567 ssthresh = cwnd * β // new slow-start threshold 568 cubic 570 ssthresh = max(ssthresh, 2) // threshold is at least 2 MSS 572 // window reduction 573 cwnd = ssthresh 575 A side effect of setting β__(cubic)_ to a value bigger than 0.5 is 576 slower convergence. We believe that while a more adaptive setting of 577 β__(cubic)_ could result in faster convergence, it will make the 578 analysis of CUBIC much harder. 580 4.7. Fast Convergence 582 To improve convergence speed, CUBIC uses a heuristic. When a new 583 flow joins the network, existing flows need to give up some of their 584 bandwidth to allow the new flow some room for growth, if the existing 585 flows have been using all the network bandwidth. To speed up this 586 bandwidth release by existing flows, the following "Fast Convergence" 587 mechanism SHOULD be implemented. 589 With Fast Convergence, when a congestion event occurs, we update 590 _W_(max)_ as follows, before the window reduction as described in 591 Section 4.6. 593 / 1 + β 594 | cubic if cwnd < W , further reduce W 595 |W * ---------- max max 596 W = < max 2 597 max | 598 | otherwise, remember cwnd before reduction 599 \cwnd 601 At a congestion event, if the current _cwnd_ is less than _W_(max)_, 602 this indicates that the saturation point experienced by this flow is 603 getting reduced because of a change in available bandwidth. Then we 604 allow this flow to release more bandwidth by reducing _W_(max)_ 605 further. This action effectively lengthens the time for this flow to 606 increase its congestion window, because the reduced _W_(max)_ forces 607 the flow to plateau earlier. This allows more time for the new flow 608 to catch up to its congestion window size. 610 Fast Convergence is designed for network environments with multiple 611 CUBIC flows. In network environments with only a single CUBIC flow 612 and without any other traffic, Fast Convergence SHOULD be disabled. 614 4.8. Timeout 616 In case of a timeout, CUBIC follows AIMD TCP to reduce _cwnd_ 617 [RFC5681], but sets _ssthresh_ using β__(cubic)_ (same as in 618 Section 4.6) in a way that is different from AIMD TCP [RFC5681]. 620 During the first congestion avoidance stage after a timeout, CUBIC 621 increases its congestion window size using Figure 1, where _t_ is the 622 elapsed time since the beginning of the current congestion avoidance, 623 _K_ is set to 0, and _W_(max)_ is set to the congestion window size 624 at the beginning of the current congestion avoidance stage. In 625 addition, for the AIMD-friendly region, _W_(est)_ SHOULD be set to 626 the congestion window size at the beginning of the current congestion 627 avoidance. 629 4.9. Spurious Congestion Events 631 In cases where CUBIC reduces its congestion window in response to 632 having detected packet loss via duplicate ACKs or timeouts, there is 633 a possibility that the missing ACK would arrive after the congestion 634 window reduction and a corresponding packet retransmission. For 635 example, packet reordering could trigger this behavior. A high 636 degree of packet reordering could cause multiple congestion window 637 reduction events, where spurious losses are incorrectly interpreted 638 as congestion signals, thus degrading CUBIC's performance 639 significantly. 641 When there is a congestion event, a CUBIC implementation SHOULD save 642 the current value of the following variables before the congestion 643 window reduction. 645 prior_cwnd = cwnd 647 prior_ssthresh = ssthresh 649 prior_W = W 650 max max 652 prior_K = K 654 prior_epoch = epoch 655 start start 657 prior_W_{est} = W 658 est 660 CUBIC MAY implement an algorithm to detect spurious retransmissions, 661 such as DSACK [RFC3708], Forward RTO-Recovery [RFC5682] or Eifel 662 [RFC3522]. Once a spurious congestion event is detected, CUBIC 663 SHOULD restore the original values of above mentioned variables as 664 follows if the current _cwnd_ is lower than _prior_cwnd_. Restoring 665 the original values ensures that CUBIC's performance is similar to 666 what it would be without spurious losses. 668 \ 669 cwnd = prior_cwnd | 670 | 671 ssthresh = prior_ssthresh | 672 | 673 W = prior_W | 674 max max | 675 >if cwnd < prior_cwnd 676 K = prior_K | 677 | 678 epoch = prior_epoch | 679 start start| 680 | 681 W = prior_W | 682 est est / 684 In rare cases, when the detection happens long after a spurious loss 685 event and the current _cwnd_ is already higher than _prior_cwnd_, 686 CUBIC SHOULD continue to use the current and the most recent values 687 of these variables. 689 4.10. Slow Start 691 CUBIC MUST employ a slow-start algorithm, when _cwnd_ is no more than 692 _ssthresh_. Among the slow-start algorithms, CUBIC MAY choose the 693 AIMD TCP slow start [RFC5681] in general networks, or the limited 694 slow start [RFC3742] or hybrid slow start [HR08] for fast and long- 695 distance networks. 697 When CUBIC uses hybrid slow start [HR08], it may exit the first slow 698 start without incurring any packet loss and thus _W_(max)_ is 699 undefined. In this special case, CUBIC switches to congestion 700 avoidance and increases its congestion window size using Figure 1, 701 where _t_ is the elapsed time since the beginning of the current 702 congestion avoidance, _K_ is set to 0, and _W_(max)_ is set to the 703 congestion window size at the beginning of the current congestion 704 avoidance stage. 706 5. Discussion 708 In this section, we further discuss the safety features of CUBIC 709 following the guidelines specified in [RFC5033]. 711 With a deterministic loss model where the number of packets between 712 two successive packet losses is always _1/p_, CUBIC always operates 713 with the concave window profile, which greatly simplifies the 714 performance analysis of CUBIC. The average window size of CUBIC can 715 be obtained by the following function: 717 ________________ ____ 718 /C * (3 + β ) 3 / 4 719 4 / cubic |/ RTT 720 AVG_W = | / ---------------- * ------- 721 cubic | / 4 * (1 - β ) __ 722 |/ cubic 3 / 4 723 |/ p 725 Figure 5 727 With β__(cubic)_ set to 0.7, the above formula reduces to: 729 ____ 730 _______ 3 / 4 731 4 /C * 3.7 |/ RTT 732 AVG_W = | / ------- * ------- 733 cubic |/ 1.2 __ 734 3 / 4 735 |/ p 737 Figure 6 739 We will determine the value of _C_ in the following subsection using 740 Figure 6. 742 5.1. Fairness to AIMD TCP 744 In environments where AIMD TCP is able to make reasonable use of the 745 available bandwidth, CUBIC does not significantly change this state. 747 AIMD TCP performs well in the following two types of networks: 749 1. networks with a small bandwidth-delay product (BDP) 751 2. networks with a short RTTs, but not necessarily a small BDP 752 CUBIC is designed to behave very similarly to AIMD TCP in the above 753 two types of networks. The following two tables show the average 754 window sizes of AIMD TCP, HSTCP, and CUBIC. The average window sizes 755 of AIMD TCP and HSTCP are from [RFC3649]. The average window size of 756 CUBIC is calculated using Figure 6 and the CUBIC AIMD-friendly region 757 for three different values of _C_. 759 +=============+=======+========+================+=========+========+ 760 | Loss Rate P | AIMD | HSTCP | CUBIC (C=0.04) | CUBIC | CUBIC | 761 | | | | | (C=0.4) | (C=4) | 762 +=============+=======+========+================+=========+========+ 763 | 1.0e-02 | 12 | 12 | 12 | 12 | 12 | 764 +-------------+-------+--------+----------------+---------+--------+ 765 | 1.0e-03 | 38 | 38 | 38 | 38 | 59 | 766 +-------------+-------+--------+----------------+---------+--------+ 767 | 1.0e-04 | 120 | 263 | 120 | 187 | 333 | 768 +-------------+-------+--------+----------------+---------+--------+ 769 | 1.0e-05 | 379 | 1795 | 593 | 1054 | 1874 | 770 +-------------+-------+--------+----------------+---------+--------+ 771 | 1.0e-06 | 1200 | 12280 | 3332 | 5926 | 10538 | 772 +-------------+-------+--------+----------------+---------+--------+ 773 | 1.0e-07 | 3795 | 83981 | 18740 | 33325 | 59261 | 774 +-------------+-------+--------+----------------+---------+--------+ 775 | 1.0e-08 | 12000 | 574356 | 105383 | 187400 | 333250 | 776 +-------------+-------+--------+----------------+---------+--------+ 778 Table 1: AIMD TCP, HSTCP, and CUBIC with RTT = 0.1 seconds 780 Table 1 describes the response function of AIMD TCP, HSTCP, and CUBIC 781 in networks with _RTT_ = 0.1 seconds. The average window size is in 782 MSS-sized segments. 784 +=============+=======+========+================+=========+=======+ 785 | Loss Rate P | AIMD | HSTCP | CUBIC (C=0.04) | CUBIC | CUBIC | 786 | | | | | (C=0.4) | (C=4) | 787 +=============+=======+========+================+=========+=======+ 788 | 1.0e-02 | 12 | 12 | 12 | 12 | 12 | 789 +-------------+-------+--------+----------------+---------+-------+ 790 | 1.0e-03 | 38 | 38 | 38 | 38 | 38 | 791 +-------------+-------+--------+----------------+---------+-------+ 792 | 1.0e-04 | 120 | 263 | 120 | 120 | 120 | 793 +-------------+-------+--------+----------------+---------+-------+ 794 | 1.0e-05 | 379 | 1795 | 379 | 379 | 379 | 795 +-------------+-------+--------+----------------+---------+-------+ 796 | 1.0e-06 | 1200 | 12280 | 1200 | 1200 | 1874 | 797 +-------------+-------+--------+----------------+---------+-------+ 798 | 1.0e-07 | 3795 | 83981 | 3795 | 5926 | 10538 | 799 +-------------+-------+--------+----------------+---------+-------+ 800 | 1.0e-08 | 12000 | 574356 | 18740 | 33325 | 59261 | 801 +-------------+-------+--------+----------------+---------+-------+ 803 Table 2: AIMD TCP, HSTCP, and CUBIC with RTT = 0.01 seconds 805 Table 2 describes the response function of AIMD TCP, HSTCP, and CUBIC 806 in networks with _RTT_ = 0.01 seconds. The average window size is in 807 MSS-sized segments. 809 Both tables show that CUBIC with any of these three _C_ values is 810 more friendly to AIMD TCP than HSTCP, especially in networks with a 811 short _RTT_ where AIMD TCP performs reasonably well. For example, in 812 a network with _RTT_ = 0.01 seconds and p=10^-6, AIMD TCP has an 813 average window of 1200 packets. If the packet size is 1500 bytes, 814 then AIMD TCP can achieve an average rate of 1.44 Gbps. In this 815 case, CUBIC with _C_=0.04 or _C_=0.4 achieves exactly the same rate 816 as AIMD TCP, whereas HSTCP is about ten times more aggressive than 817 AIMD TCP. 819 We can see that _C_ determines the aggressiveness of CUBIC in 820 competing with other congestion control algorithms for bandwidth. 821 CUBIC is more friendly to AIMD TCP, if the value of _C_ is lower. 822 However, we do not recommend setting _C_ to a very low value like 823 0.04, since CUBIC with a low _C_ cannot efficiently use the bandwidth 824 in fast and long-distance networks. Based on these observations and 825 extensive deployment experience, we find _C_=0.4 gives a good balance 826 between AIMD- friendliness and aggressiveness of window increase. 827 Therefore, _C_ SHOULD be set to 0.4. With _C_ set to 0.4, Figure 6 828 is reduced to: 830 ____ 831 3 / 4 832 |/ RTT 833 AVG_W = 1.054 * ------- 834 cubic __ 835 3 / 4 836 |/ p 838 Figure 7 840 Figure 7 is then used in the next subsection to show the scalability 841 of CUBIC. 843 5.2. Using Spare Capacity 845 CUBIC uses a more aggressive window increase function than AIMD TCP 846 for fast and long-distance networks. 848 The following table shows that to achieve the 10 Gbps rate, AIMD TCP 849 requires a packet loss rate of 2.0e-10, while CUBIC requires a packet 850 loss rate of 2.9e-8. 852 +===================+===========+=========+=========+=========+ 853 | Throughput (Mbps) | Average W | AIMD P | HSTCP P | CUBIC P | 854 +===================+===========+=========+=========+=========+ 855 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | 856 +-------------------+-----------+---------+---------+---------+ 857 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | 858 +-------------------+-----------+---------+---------+---------+ 859 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | 860 +-------------------+-----------+---------+---------+---------+ 861 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | 862 +-------------------+-----------+---------+---------+---------+ 863 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | 864 +-------------------+-----------+---------+---------+---------+ 866 Table 3: Required packet loss rate for AIMD TCP, HSTCP, and 867 CUBIC to achieve a certain throughput 869 Table 3 describes the required packet loss rate for AIMD TCP, HSTCP, 870 and CUBIC to achieve a certain throughput. We use 1500-byte packets 871 and an _RTT_ of 0.1 seconds. 873 Our test results in [HKLRX06] indicate that CUBIC uses the spare 874 bandwidth left unused by existing AIMD TCP flows in the same 875 bottleneck link without taking away much bandwidth from the existing 876 flows. 878 5.3. Difficult Environments 880 CUBIC is designed to remedy the poor performance of AIMD TCP in fast 881 and long-distance networks. 883 5.4. Investigating a Range of Environments 885 CUBIC has been extensively studied by using both NS-2 simulation and 886 testbed experiments, covering a wide range of network environments. 887 More information can be found in [HKLRX06]. Additionally, there is 888 decade-long deployment experience with CUBIC on the Internet. 890 Same as AIMD TCP, CUBIC is a loss-based congestion control algorithm. 891 Because CUBIC is designed to be more aggressive (due to a faster 892 window increase function and bigger multiplicative decrease factor) 893 than AIMD TCP in fast and long-distance networks, it can fill large 894 drop-tail buffers more quickly than AIMD TCP and increases the risk 895 of a standing queue [RFC8511]. In this case, proper queue sizing and 896 management [RFC7567] could be used to reduce the packet queuing 897 delay. 899 5.5. Protection against Congestion Collapse 901 With regard to the potential of causing congestion collapse, CUBIC 902 behaves like AIMD TCP, since CUBIC modifies only the window 903 adjustment algorithm of AIMD TCP. Thus, it does not modify the ACK 904 clocking and timeout behaviors of AIMD TCP. 906 5.6. Fairness within the Alternative Congestion Control Algorithm 908 CUBIC ensures convergence of competing CUBIC flows with the same RTT 909 in the same bottleneck links to an equal throughput. When competing 910 flows have different RTT values, their throughput ratio is linearly 911 proportional to the inverse of their RTT ratios. This is true 912 independently of the level of statistical multiplexing on the link. 914 5.7. Performance with Misbehaving Nodes and Outside Attackers 916 This is not considered in the current CUBIC design. 918 5.8. Behavior for Application-Limited Flows 920 CUBIC does not increase its congestion window size if a flow is 921 currently limited by the application instead of the congestion 922 window. In case of long periods during which _cwnd_ has not been 923 updated due to such an application limit, such as idle periods, _t_ 924 in Figure 1 MUST NOT include these periods; otherwise, W_(cubic)(_t_) 925 might be very high after restarting from these periods. 927 5.9. Responses to Sudden or Transient Events 929 If there is a sudden congestion, a routing change, or a mobility 930 event, CUBIC behaves the same as AIMD TCP. 932 5.10. Incremental Deployment 934 CUBIC requires only changes to TCP senders, and it does not require 935 any changes at TCP receivers. That is, a CUBIC sender works 936 correctly with the AIMD TCP receivers. In addition, CUBIC does not 937 require any changes to routers and does not require any assistance 938 from routers. 940 6. Security Considerations 942 CUBIC makes no changes to the underlying security of TCP. More 943 information about TCP security concerns can be found in [RFC5681]. 945 7. IANA Considerations 947 This document does not require any IANA actions. 949 8. References 951 8.1. Normative References 953 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 954 Requirement Levels", BCP 14, RFC 2119, 955 DOI 10.17487/RFC2119, March 1997, 956 . 958 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 959 of Explicit Congestion Notification (ECN) to IP", 960 RFC 3168, DOI 10.17487/RFC3168, September 2001, 961 . 963 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 964 Control Algorithms", BCP 133, RFC 5033, 965 DOI 10.17487/RFC5033, August 2007, 966 . 968 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 969 Friendly Rate Control (TFRC): Protocol Specification", 970 RFC 5348, DOI 10.17487/RFC5348, September 2008, 971 . 973 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 974 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 975 . 977 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 978 "Computing TCP's Retransmission Timer", RFC 6298, 979 DOI 10.17487/RFC6298, June 2011, 980 . 982 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 983 NewReno Modification to TCP's Fast Recovery Algorithm", 984 RFC 6582, DOI 10.17487/RFC6582, April 2012, 985 . 987 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 988 and Y. Nishida, "A Conservative Loss Recovery Algorithm 989 Based on Selective Acknowledgment (SACK) for TCP", 990 RFC 6675, DOI 10.17487/RFC6675, August 2012, 991 . 993 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 994 Recommendations Regarding Active Queue Management", 995 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 996 . 998 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 999 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1000 May 2017, . 1002 8.2. Informative References 1004 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic 1005 Ordering for Internet Congestion Control and its 1006 Applications", IEEE INFOCOM 2007 - 26th IEEE International 1007 Conference on Computer Communications, 1008 DOI 10.1109/infcom.2007.111, 2007, 1009 . 1011 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of 1012 Equation-Based and AIMD Congestion Control", May 2000, 1013 . 1015 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary 1016 Adjustment Algorithms", Technical Report TR2002-29, 1017 Department of Computer Sciences, The University of 1018 Texas at Austin, 11 August 2002, 1019 . 1021 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step 1022 toward Realistic Performance Evaluation of High-Speed TCP 1023 Variants", International Workshop on Protocols for Fast 1024 Long-Distance Networks, February 2006, 1025 . 1027 [HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth 1028 and Long-Distance Networks", International Workshop 1029 on Protocols for Fast Long-Distance Networks, March 2008, 1030 . 1033 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly 1034 high-speed TCP variant", ACM SIGOPS Operating Systems 1035 Review Vol. 42, pp. 64-74, DOI 10.1145/1400097.1400105, 1036 July 2008, . 1038 [K03] Kelly, T., "Scalable TCP: improving performance in 1039 highspeed wide area networks", ACM SIGCOMM Computer 1040 Communication Review Vol. 33, pp. 83-91, 1041 DOI 10.1145/956981.956989, April 2003, 1042 . 1044 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 1045 for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, 1046 . 1048 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 1049 RFC 3649, DOI 10.17487/RFC3649, December 2003, 1050 . 1052 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 1053 Acknowledgement (DSACKs) and Stream Control Transmission 1054 Protocol (SCTP) Duplicate Transmission Sequence Numbers 1055 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 1056 DOI 10.17487/RFC3708, February 2004, 1057 . 1059 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 1060 Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March 1061 2004, . 1063 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1064 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1065 . 1067 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 1068 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 1069 Spurious Retransmission Timeouts with TCP", RFC 5682, 1070 DOI 10.17487/RFC5682, September 2009, 1071 . 1073 [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 1074 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 1075 RFC 8312, DOI 10.17487/RFC8312, February 2018, 1076 . 1078 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 1079 "TCP Alternative Backoff with ECN (ABE)", RFC 8511, 1080 DOI 10.17487/RFC8511, December 2018, 1081 . 1083 [SXEZ19] Sun, W., Xu, L., Elbaum, S., and D. Zhao, "Model-Agnostic 1084 and Efficient Exploration of Numerical State Space of 1085 Real-World TCP Congestion Control Implementations", USENIX 1086 NSDI 2019, February 2019, 1087 . 1089 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase 1090 Congestion Control (BIC) for Fast Long-Distance Networks", 1091 IEEE INFOCOM 2004, DOI 10.1109/infcom.2004.1354672, March 1092 2004, . 1094 Appendix A. Acknowledgements 1096 Richard Scheffenegger and Alexander Zimmermann originally co-authored 1097 [RFC8312]. 1099 Appendix B. Evolution of CUBIC 1101 B.1. Since draft-eggert-tcpm-rfc8312bis-01 1103 * Rename TCP-Friendly to AIMD-Friendly and rename Standard TCP to 1104 AIMD TCP to avoid confusion as CUBIC has been widely used in the 1105 Internet. (#38 (https://github.com/NTAP/rfc8312bis/issues/38)) 1107 * Change introductory text to reflect the significant broader 1108 deployment of CUBIC in the Internet. (#39 1109 (https://github.com/NTAP/rfc8312bis/issues/39)) 1111 * Rephrase introduction to avoid referring to variables that have 1112 not been defined yet. 1114 B.2. Since draft-eggert-tcpm-rfc8312bis-00 1116 * acknowledge former co-authors (#15 1117 (https://github.com/NTAP/rfc8312bis/issues/15)) 1119 * prevent _cwnd_ from becoming less than two (#7 1120 (https://github.com/NTAP/rfc8312bis/issues/7)) 1122 * add list of variables and constants (#5 1123 (https://github.com/NTAP/rfc8312bis/issues/5), #6 1124 (https://github.com/NTAP/rfc8312bis/issues/5)) 1126 * update _K_'s definition and add bounds for CUBIC _target_ _cwnd_ 1127 [SXEZ19] (#1 (https://github.com/NTAP/rfc8312bis/issues/1), #14 1128 (https://github.com/NTAP/rfc8312bis/issues/14)) 1130 * update _W_(est)_ to use AIMD approach (#20 1131 (https://github.com/NTAP/rfc8312bis/issues/20)) 1133 * set alpha__(aimd)_ to 1 once _W_(est)_ reaches _W_(max)_ (#2 1134 (https://github.com/NTAP/rfc8312bis/issues/2)) 1136 * add Vidhi as co-author (#17 (https://github.com/NTAP/rfc8312bis/ 1137 issues/17)) 1139 * note for Fast Recovery during _cwnd_ decrease due to congestion 1140 event (#11 (https://github.com/NTAP/rfc8312bis11/issues/11)) 1142 * add section for spurious congestion events (#23 1143 (https://github.com/NTAP/rfc8312bis/issues/23)) 1145 * initialize _W_(est)_ after timeout and remove variable 1146 _W_(last_max)_ (#28 (https://github.com/NTAP/rfc8312bis/ 1147 issues/28)) 1149 B.3. Since RFC8312 1151 * converted to Markdown and xml2rfc v3 1153 * updated references (as part of the conversion) 1155 * updated author information 1157 * various formatting changes 1159 * move to Standards Track 1161 B.4. Since the Original Paper 1163 CUBIC has gone through a few changes since the initial release 1164 [HRX08] of its algorithm and implementation. Below we highlight the 1165 differences between its original paper and [RFC8312]. 1167 * The original paper [HRX08] includes the pseudocode of CUBIC 1168 implementation using Linux's pluggable congestion control 1169 framework, which excludes system-specific optimizations. The 1170 simplified pseudocode might be a good source to start with and 1171 understand CUBIC. 1173 * [HRX08] also includes experimental results showing its performance 1174 {{and fairness. 1176 * The definition of beta__(cubic)_ constant was changed in 1177 [RFC8312]. For example, beta__(cubic)_ in the original paper was 1178 the window decrease constant while [RFC8312] changed it to CUBIC 1179 multiplication decrease factor. With this change, the current 1180 congestion window size after a congestion event in [RFC8312] was 1181 beta__(cubic)_ * _W_(max)_ while it was (1-beta__(cubic)_) * 1182 _W_(max)_ in the original paper. 1184 * Its pseudocode used _W_(last_max)_ while [RFC8312] used _W_(max)_. 1186 * Its AIMD-friendly window was W_(tcp) while [RFC8312] used 1187 _W_(est)_. 1189 Authors' Addresses 1191 Lisong Xu 1192 University of Nebraska-Lincoln 1193 Department of Computer Science and Engineering 1194 Lincoln, NE 68588-0115 1195 United States of America 1197 Email: xu@unl.edu 1198 URI: https://cse.unl.edu/~xu/ 1200 Sangtae Ha 1201 University of Colorado at Boulder 1202 Department of Computer Science 1203 Boulder, CO 80309-0430 1204 United States of America 1206 Email: sangtae.ha@colorado.edu 1207 URI: https://netstech.org/sangtaeha/ 1208 Injong Rhee 1209 Bowery Farming 1210 151 W 26TH Street, 12TH Floor 1211 New York, NY 10001 1212 United States of America 1214 Email: injongrhee@gmail.com 1216 Vidhi Goel 1217 Apple Inc. 1218 One Apple Park Way 1219 Cupertino, California 95014 1220 United States of America 1222 Email: vidhi_goel@apple.com 1224 Lars Eggert (editor) 1225 NetApp 1226 Stenbergintie 12 B 1227 FI-02700 Kauniainen 1228 Finland 1230 Email: lars@eggert.org 1231 URI: https://eggert.org/