idnits 2.17.1 draft-eggert-tcpm-rfc8312bis-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8312]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 446 has weird spacing: '... aimd aimd...' == Line 461 has weird spacing: '... aimd cub...' == Line 475 has weird spacing: '... est est...' == Line 615 has weird spacing: '... max max...' -- The document date (2 February 2021) is 1176 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 (==), 3 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: 6 August 2021 I. Rhee 7 Bowery 8 V. Goel 9 Apple Inc. 10 L. Eggert, Ed. 11 NetApp 12 2 February 2021 14 CUBIC for Fast Long-Distance Networks 15 draft-eggert-tcpm-rfc8312bis-01 17 Abstract 19 CUBIC is an extension to the current TCP standards. It differs from 20 the current TCP standards only in the congestion control algorithm on 21 the sender side. In particular, it uses a cubic function instead of 22 a linear window increase function of the current TCP standards to 23 improve scalability and stability under fast and long-distance 24 networks. CUBIC and its predecessor algorithm have been adopted as 25 defaults by Linux and have been used for many years. This document 26 provides a specification of CUBIC to enable third-party 27 implementations and to solicit community feedback through 28 experimentation on the performance of CUBIC. 30 This documents obsoletes [RFC8312], updating the specification of 31 CUBIC to conform to the current Linux version. 33 Note to Readers 35 Discussion of this draft takes place on the TCPM working group 36 mailing list (mailto:tcpm@ietf.org), which is archived at 37 https://mailarchive.ietf.org/arch/browse/tcpm/. 39 Working Group information can be found at 40 https://datatracker.ietf.org/wg/tcpm/; source code and issues list 41 for this draft can be found at https://github.com/NTAP/rfc8312bis. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on 6 August 2021. 60 Copyright Notice 62 Copyright (c) 2021 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 67 license-info) in effect on the date of publication of this document. 68 Please review these documents carefully, as they describe your rights 69 and restrictions with respect to this document. Code Components 70 extracted from this document must include Simplified BSD License text 71 as described in Section 4.e of the Trust Legal Provisions and are 72 provided without warranty as described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Design Principles of CUBIC . . . . . . . . . . . . . . . . . 4 79 4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 6 80 4.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 81 4.1.1. Constants of Interest . . . . . . . . . . . . . . . . 6 82 4.1.2. Variables of Interest . . . . . . . . . . . . . . . . 7 83 4.2. Window Increase Function . . . . . . . . . . . . . . . . 8 84 4.3. TCP-Friendly Region . . . . . . . . . . . . . . . . . . . 9 85 4.4. Concave Region . . . . . . . . . . . . . . . . . . . . . 11 86 4.5. Convex Region . . . . . . . . . . . . . . . . . . . . . . 11 87 4.6. Multiplicative Decrease . . . . . . . . . . . . . . . . . 12 88 4.7. Fast Convergence . . . . . . . . . . . . . . . . . . . . 12 89 4.8. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 4.9. Spurious Congestion Events . . . . . . . . . . . . . . . 13 91 4.10. Slow Start . . . . . . . . . . . . . . . . . . . . . . . 15 92 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 5.1. Fairness to Standard TCP . . . . . . . . . . . . . . . . 16 94 5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 18 95 5.3. Difficult Environments . . . . . . . . . . . . . . . . . 19 96 5.4. Investigating a Range of Environments . . . . . . . . . . 19 97 5.5. Protection against Congestion Collapse . . . . . . . . . 19 98 5.6. Fairness within the Alternative Congestion Control 99 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 19 100 5.7. Performance with Misbehaving Nodes and Outside 101 Attackers . . . . . . . . . . . . . . . . . . . . . . . 19 102 5.8. Behavior for Application-Limited Flows . . . . . . . . . 19 103 5.9. Responses to Sudden or Transient Events . . . . . . . . . 20 104 5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 20 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 107 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 108 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 109 8.2. Informative References . . . . . . . . . . . . . . . . . 21 110 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23 111 Appendix B. Evolution of CUBIC . . . . . . . . . . . . . . . . . 23 112 B.1. Since draft-eggert-tcpm-rfc8312bis-00 . . . . . . . . . . 23 113 B.2. Since RFC8312 . . . . . . . . . . . . . . . . . . . . . . 24 114 B.3. Since the Original Paper . . . . . . . . . . . . . . . . 24 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 117 1. Introduction 119 The low utilization problem of TCP in fast long-distance networks is 120 well documented in [K03] and [RFC3649]. This problem arises from a 121 slow increase of the congestion window following a congestion event 122 in a network with a large bandwidth-delay product (BDP). [HKLRX06] 123 indicates that this problem is frequently observed even in the range 124 of congestion window sizes over several hundreds of packets. This 125 problem is equally applicable to all Reno-style TCP standards and 126 their variants, including TCP-Reno [RFC5681], TCP-NewReno 127 [RFC6582][RFC6675], SCTP [RFC4960], and TFRC [RFC5348], which use the 128 same linear increase function for window growth, which we refer to 129 collectively as "Standard TCP" below. 131 CUBIC, originally proposed in [HRX08], is a modification to the 132 congestion control algorithm of Standard TCP to remedy this problem. 133 This document describes the most recent specification of CUBIC. 134 Specifically, CUBIC uses a cubic function instead of a linear window 135 increase function of Standard TCP to improve scalability and 136 stability under fast and long-distance networks. 138 Binary Increase Congestion Control (BIC-TCP) [XHR04], a predecessor 139 of CUBIC, was selected as the default TCP congestion control 140 algorithm by Linux in the year 2005 and has been used for several 141 years by the Internet community at large. CUBIC uses a similar 142 window increase function as BIC-TCP and is designed to be less 143 aggressive and fairer to Standard TCP in bandwidth usage than BIC-TCP 144 while maintaining the strengths of BIC-TCP such as stability, window 145 scalability, and RTT fairness. CUBIC has already replaced BIC-TCP as 146 the default TCP congestion control algorithm in Linux and has been 147 deployed globally by Linux. Through extensive testing in various 148 Internet scenarios, we believe that CUBIC is safe for testing and 149 deployment in the global Internet. 151 In the following sections, we first briefly explain the design 152 principles of CUBIC, then provide the exact specification of CUBIC, 153 and finally discuss the safety features of CUBIC following the 154 guidelines specified in [RFC5033]. 156 2. Conventions 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 160 "OPTIONAL" in this document are to be interpreted as described in 161 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 162 capitals, as shown here. 164 3. Design Principles of CUBIC 166 CUBIC is designed according to the following design principles: 168 Principle 1: For better network utilization and stability, CUBIC 169 uses both the concave and convex profiles of a cubic function to 170 increase the congestion window size, instead of using just a 171 convex function. 173 Principle 2: To be TCP-friendly, CUBIC is designed to behave like 174 Standard TCP in networks with short RTTs and small bandwidth where 175 Standard TCP performs well. 177 Principle 3: For RTT-fairness, CUBIC is designed to achieve linear 178 bandwidth sharing among flows with different RTTs. 180 Principle 4: CUBIC appropriately sets its multiplicative window 181 decrease factor in order to balance between the scalability and 182 convergence speed. 184 Principle 1: For better network utilization and stability, CUBIC 185 [HRX08] uses a cubic window increase function in terms of the elapsed 186 time from the last congestion event. While most alternative 187 congestion control algorithms to Standard TCP increase the congestion 188 window using convex functions, CUBIC uses both the concave and convex 189 profiles of a cubic function for window growth. After a window 190 reduction in response to a congestion event is detected by duplicate 191 ACKs or Explicit Congestion Notification-Echo (ECN-Echo) ACKs 193 [RFC3168], CUBIC registers the congestion window size where it got 194 the congestion event as _W_(max)_ and performs a multiplicative 195 decrease of congestion window. After it enters into congestion 196 avoidance, it starts to increase the congestion window using the 197 concave profile of the cubic function. The cubic function is set to 198 have its plateau at _W_(max)_ so that the concave window increase 199 continues until the window size becomes _W_(max)_. After that, the 200 cubic function turns into a convex profile and the convex window 201 increase begins. This style of window adjustment (concave and then 202 convex) improves the algorithm stability while maintaining high 203 network utilization [CEHRX07]. This is because the window size 204 remains almost constant, forming a plateau around _W_(max)_ where 205 network utilization is deemed highest. Under steady state, most 206 window size samples of CUBIC are close to _W_(max)_, thus promoting 207 high network utilization and stability. Note that those congestion 208 control algorithms using only convex functions to increase the 209 congestion window size have the maximum increments around _W_(max)_, 210 and thus introduce a large number of packet bursts around the 211 saturation point of the network, likely causing frequent global loss 212 synchronizations. 214 Principle 2: CUBIC promotes per-flow fairness to Standard TCP. Note 215 that Standard TCP performs well under short RTT and small bandwidth 216 (or small BDP) networks. There is only a scalability problem in 217 networks with long RTTs and large bandwidth (or large BDP). An 218 alternative congestion control algorithm to Standard TCP designed to 219 be friendly to Standard TCP on a per-flow basis must operate to 220 increase its congestion window less aggressively in small BDP 221 networks than in large BDP networks. The aggressiveness of CUBIC 222 mainly depends on the maximum window size before a window reduction, 223 which is smaller in small BDP networks than in large BDP networks. 224 Thus, CUBIC increases its congestion window less aggressively in 225 small BDP networks than in large BDP networks. Furthermore, in cases 226 when the cubic function of CUBIC increases its congestion window less 227 aggressively than Standard TCP, CUBIC simply follows the window size 228 of Standard TCP to ensure that CUBIC achieves at least the same 229 throughput as Standard TCP in small BDP networks. We call this 230 region where CUBIC behaves like Standard TCP, the "TCP-friendly 231 region". 233 Principle 3: Two CUBIC flows with different RTTs have their 234 throughput ratio linearly proportional to the inverse of their RTT 235 ratio, where the throughput of a flow is approximately the size of 236 its congestion window divided by its RTT. Specifically, CUBIC 237 maintains a window increase rate independent of RTTs outside of the 238 TCP-friendly region, and thus flows with different RTTs have similar 239 congestion window sizes under steady state when they operate outside 240 the TCP-friendly region. This notion of a linear throughput ratio is 241 similar to that of Standard TCP under high statistical multiplexing 242 environments where packet losses are independent of individual flow 243 rates. However, under low statistical multiplexing environments, the 244 throughput ratio of Standard TCP flows with different RTTs is 245 quadratically proportional to the inverse of their RTT ratio [XHR04]. 246 CUBIC always ensures the linear throughput ratio independent of the 247 levels of statistical multiplexing. This is an improvement over 248 Standard TCP. While there is no consensus on particular throughput 249 ratios of different RTT flows, we believe that under wired Internet, 250 use of a linear throughput ratio seems more reasonable than equal 251 throughputs (i.e., the same throughput for flows with different RTTs) 252 or a higher-order throughput ratio (e.g., a quadratical throughput 253 ratio of Standard TCP under low statistical multiplexing 254 environments). 256 Principle 4: To balance between the scalability and convergence 257 speed, CUBIC sets the multiplicative window decrease factor to 0.7 258 while Standard TCP uses 0.5. While this improves the scalability of 259 CUBIC, a side effect of this decision is slower convergence, 260 especially under low statistical multiplexing environments. This 261 design choice is following the observation that the author of 262 HighSpeed TCP (HSTCP) [RFC3649] has made along with other researchers 263 (e.g., [GV02]): the current Internet becomes more asynchronous with 264 less frequent loss synchronizations with high statistical 265 multiplexing. Under this environment, even strict Multiplicative- 266 Increase Multiplicative-Decrease (MIMD) can converge. CUBIC flows 267 with the same RTT always converge to the same throughput independent 268 of statistical multiplexing, thus achieving intra-algorithm fairness. 269 We also find that under the environments with sufficient statistical 270 multiplexing, the convergence speed of CUBIC flows is reasonable. 272 4. CUBIC Congestion Control 274 In this section, we discuss how the congestion window is updated 275 during the different stages of the CUBIC congestion controller. 277 4.1. Definitions 279 The unit of all window sizes in this document is segments of the 280 maximum segment size (MSS), and the unit of all times is seconds. 282 4.1.1. Constants of Interest 284 β__(cubic)_: CUBIC multiplication decrease factor as described in 285 Section 4.6. 287 _C_: constant that determines the aggressiveness of CUBIC in 288 competing with other congestion control algorithms in high BDP 289 networks. Please see Section 5 for more explanation on how it is 290 set. The unit for _C_ is 292 segment 293 ------- 294 3 295 second 297 4.1.2. Variables of Interest 299 Variables required to implement CUBIC are described in this section. 301 _RTT_: Smoothed round-trip time in seconds calculated as described in 302 [RFC6298]. 304 _cwnd_: Current congestion window in segments. 306 _ssthresh_: Current slow start threshold in segments. 308 _W_(max)_: Size of _cwnd_ in segments just before _cwnd_ is reduced 309 in the last congestion event. 311 _K_: The time period in seconds it takes to increase the congestion 312 window size at the beginning of the current congestion avoidance 313 stage to _W_(max)_. 315 _current_time_: Current time of the system in seconds. 317 _epoch_(start)_: The time in seconds at which the current congestion 318 avoidance stage starts. 320 _cwnd_(start)_: The _cwnd_ at the beginning of the current congestion 321 avoidance stage, i.e., at time _epoch_(start)_. 323 W_(cubic)(_t_): Target value of the congestion window in segments at 324 time t in seconds based on the cubic increase function as described 325 in Section 4.2. 327 _target_: Target value of congestion window in segments after the 328 next _RTT_, that is, W_(cubic)(_t_ + _RTT_) as described in 329 Section 4.2. 331 _W_(est)_: An estimate for the congestion window in segments in the 332 TCP-friendly region, that is, an estimate for the congestion window 333 using the AIMD approach similar to TCP-NewReno congestion controller. 335 4.2. Window Increase Function 337 CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by 338 increasing the congestion window only at the reception of an ACK. It 339 does not make any change to the fast recovery and retransmit of TCP, 340 such as TCP-NewReno [RFC6582][RFC6675]. During congestion avoidance 341 after a congestion event where a packet loss is detected by duplicate 342 ACKs or a network congestion is detected by ACKs with ECN-Echo flags 343 [RFC3168], CUBIC changes the window increase function of Standard 344 TCP. 346 CUBIC uses the following window increase function: 348 3 349 W (t) = C * (t - K) + W 350 cubic max 352 Figure 1 354 where t is the elapsed time in seconds from the beginning of the 355 current congestion avoidance stage, that is, 357 t = current_time - epoch 358 start 360 and where _epoch_(start)_ is the time at which the current congestion 361 avoidance stage starts. _K_ is the time period that the above 362 function takes to increase the congestion window size at the 363 beginning of the current congestion avoidance stage to _W_(max)_ if 364 there are no further congestion events and is calculated using the 365 following equation: 367 ________________ 368 /W - cwnd 369 3 / max start 370 K = | / ---------------- 371 |/ C 373 Figure 2 375 where _cwnd_(start)_ is the congestion window at the beginning of the 376 current congestion avoidance stage. _cwnd_(start)_ is calculated as 377 described in Section 4.6 when a congestion event is detected, 378 although implementations can further adjust _cwnd_(start)_ based on 379 other fast recovery mechanisms. In special cases, if _cwnd_(start)_ 380 is greater than _W_(max)_, _K_ is set to 0. 382 Upon receiving an ACK during congestion avoidance, CUBIC computes the 383 _target_ congestion window size after the next _RTT_ using Figure 1 384 as follows, where _RTT_ is the smoothed round-trip time. The lower 385 and upper bounds below ensure that CUBIC's congestion window increase 386 rate is non-decreasing and is less than the increase rate of slow 387 start. 389 / 390 | if W (t + RTT) < cwnd 391 |cwnd cubic 392 | 393 | 394 | 395 target = < if W (t + RTT) > 1.5 * cwnd 396 |1.5 * cwnd cubic 397 | 398 | 399 |W (t + RTT) 400 | cubic otherwise 401 \ 403 Depending on the value of the current congestion window size _cwnd_, 404 CUBIC runs in three different modes. 406 1. The TCP-friendly region, which ensures that CUBIC achieves at 407 least the same throughput as Standard TCP. 409 2. The concave region, if CUBIC is not in the TCP-friendly region 410 and _cwnd_ is less than _W_(max)_. 412 3. The convex region, if CUBIC is not in the TCP-friendly region and 413 _cwnd_ is greater than _W_(max)_. 415 Below, we describe the exact actions taken by CUBIC in each region. 417 4.3. TCP-Friendly Region 419 Standard TCP performs well in certain types of networks, for example, 420 under short RTT and small bandwidth (or small BDP) networks. In 421 these networks, we use the TCP-friendly region to ensure that CUBIC 422 achieves at least the same throughput as Standard TCP. 424 The TCP-friendly region is designed according to the analysis 425 described in [FHP00]. The analysis studies the performance of an 426 Additive Increase and Multiplicative Decrease (AIMD) algorithm with 427 an additive factor of α__(aimd)_ (segments per _RTT_) and a 428 multiplicative factor of β__(aimd)_, denoted by AIMD(α__(aimd)_, 429 β__(aimd)_). Specifically, the average congestion window size of 430 AIMD(α__(aimd)_, β__(aimd)_) can be calculated using Figure 3. The 431 analysis shows that AIMD(α__(aimd)_, β__(aimd)_) with 433 1 - β 434 cubic 435 α = 3 * ---------- 436 aimd 1 + β 437 cubic 439 achieves the same average window size as Standard TCP that uses 440 AIMD(1, 0.5). 442 ___________________ 443 /α * (1 + β ) 444 / aimd aimd 445 AVG_AIMD(α , β ) = | / ------------------- 446 aimd aimd | / 2 * (1 - β ) * p 447 |/ aimd 449 Figure 3 451 Based on the above analysis, CUBIC uses Figure 4 to estimate the 452 window size _W_(est)_ of AIMD(α__(aimd)_, β__(aimd)_) with 454 1 - β 455 cubic 456 α = 3 * ---------- 457 aimd 1 + β 458 cubic 460 β = β 461 aimd cubic 463 which achieves the same average window size as Standard TCP. When 464 receiving an ACK in congestion avoidance (_cwnd_ could be greater 465 than or less than _W_(max)_), CUBIC checks whether W_(cubic)(_t_) is 466 less than _W_(est)_. If so, CUBIC is in the TCP-friendly region and 467 _cwnd_ SHOULD be set to _W_(est)_ at each reception of an ACK. 469 _W_(est)_ is set equal to _cwnd_ at the start of the congestion 470 avoidance stage. After that, on every ACK, _W_(est)_ is updated 471 using Figure 4. 473 segments_acked 474 W = W + α * -------------- 475 est est aimd cwnd 477 Figure 4 479 Note that once _W_(est)_ reaches _W_(max)_, that is, _W_(est)_ >= 480 _W_(max)_, α__(aimd)_ SHOULD be set to 1 to achieve the same 481 congestion window size as standard TCP that uses AIMD. 483 4.4. Concave Region 485 When receiving an ACK in congestion avoidance, if CUBIC is not in the 486 TCP-friendly region and _cwnd_ is less than _W_(max)_, then CUBIC is 487 in the concave region. In this region, _cwnd_ MUST be incremented by 489 target - cwnd 490 ------------- 491 cwnd 493 for each received ACK, where _target_ is calculated as described in 494 Section 4.2. 496 4.5. Convex Region 498 When receiving an ACK in congestion avoidance, if CUBIC is not in the 499 TCP-friendly region and _cwnd_ is larger than or equal to _W_(max)_, 500 then CUBIC is in the convex region. The convex region indicates that 501 the network conditions might have been perturbed since the last 502 congestion event, possibly implying more available bandwidth after 503 some flow departures. Since the Internet is highly asynchronous, 504 some amount of perturbation is always possible without causing a 505 major change in available bandwidth. In this region, CUBIC is being 506 very careful by very slowly increasing its window size. The convex 507 profile ensures that the window increases very slowly at the 508 beginning and gradually increases its increase rate. We also call 509 this region the "maximum probing phase" since CUBIC is searching for 510 a new _W_(max)_. In this region, _cwnd_ MUST be incremented by 512 target - cwnd 513 ------------- 514 cwnd 516 for each received ACK, where _target_ is calculated as described in 517 Section 4.2. 519 4.6. Multiplicative Decrease 521 When a packet loss is detected by duplicate ACKs or a network 522 congestion is detected by receiving packets marked with ECN-Echo 523 (ECE), CUBIC updates its _W_(max)_ and reduces its _cwnd_ and 524 _ssthresh_ immediately as below. For both packet loss and congestion 525 detection through ECN, the sender MAY employ a fast recovery 526 algorithm to gradually adjust the congestion window to its new 527 reduced value. Parameter β__(cubic)_ SHOULD be set to 0.7. 529 ssthresh = cwnd * β // new slow-start threshold 530 cubic 532 ssthresh = max(ssthresh, 2) // threshold is at least 2 MSS 534 // window reduction 535 cwnd = ssthresh 537 A side effect of setting β__(cubic)_ to a value bigger than 0.5 is 538 slower convergence. We believe that while a more adaptive setting of 539 β__(cubic)_ could result in faster convergence, it will make the 540 analysis of CUBIC much harder. This adaptive adjustment of 541 β__(cubic)_ is an item for the next version of CUBIC. 543 4.7. Fast Convergence 545 To improve the convergence speed of CUBIC, we add a heuristic in 546 CUBIC. When a new flow joins the network, existing flows in the 547 network need to give up some of their bandwidth to allow the new flow 548 some room for growth if the existing flows have been using all the 549 bandwidth of the network. To speed up this bandwidth release by 550 existing flows, the following mechanism called "fast convergence" 551 SHOULD be implemented. 553 With fast convergence, when a congestion event occurs, we update 554 _W_(max)_ as follows before the window reduction as described in 555 Section 4.6. 557 / 1 + β 558 | cubic if cwnd < W , further reduce W 559 |W * ---------- max max 560 W = < max 2 561 max | 562 | otherwise, remember cwnd before reduction 563 \cwnd 565 At a congestion event, if the current _cwnd_ is less than _W_(max)_, 566 this indicates that the saturation point experienced by this flow is 567 getting reduced because of the change in available bandwidth. Then 568 we allow this flow to release more bandwidth by reducing _W_(max)_ 569 further. This action effectively lengthens the time for this flow to 570 increase its congestion window because the reduced _W_(max)_ forces 571 the flow to have the plateau earlier. This allows more time for the 572 new flow to catch up to its congestion window size. 574 The fast convergence is designed for network environments with 575 multiple CUBIC flows. In network environments with only a single 576 CUBIC flow and without any other traffic, the fast convergence SHOULD 577 be disabled. 579 4.8. Timeout 581 In case of timeout, CUBIC follows Standard TCP to reduce _cwnd_ 582 [RFC5681], but sets _ssthresh_ using β__(cubic)_ (same as in 583 Section 4.6) that is different from Standard TCP [RFC5681]. 585 During the first congestion avoidance after a timeout, CUBIC 586 increases its congestion window size using Figure 1, where t is the 587 elapsed time since the beginning of the current congestion avoidance, 588 _K_ is set to 0, and _W_(max)_ is set to the congestion window size 589 at the beginning of the current congestion avoidance. In addition, 590 for the tcp-friendliness region, _W_(est)_ should be set to the 591 congestion window size at the beginning of the current congestion 592 avoidance. 594 4.9. Spurious Congestion Events 596 For the case where CUBIC reduces its congestion window in response to 597 detection of packet loss via duplicate ACKs or timeout, there is a 598 possibility that the missing ACK would arrive after the congestion 599 window reduction and the corresponding packet retransmission. For 600 example, packet reordering which is common in networks could trigger 601 this behavior. A high degree of packet reordering could cause 602 multiple events of congestion window reduction where spurious losses 603 are incorrectly interpreted as congestion signals, thus degrading 604 CUBIC's performance significantly. 606 When there is a congestion event, a CUBIC implementation SHOULD save 607 the current value of the following variables before the congestion 608 window reduction. 610 prior_cwnd = cwnd 612 prior_ssthresh = ssthresh 614 prior_W = W 615 max max 617 prior_K = K 619 prior_epoch = epoch 620 start start 622 prior_W_{est} = W 623 est 625 CUBIC MAY implement an algorithm to detect spurious retransmissions, 626 such as DSACK [RFC3708], Forward RTO-Recovery [RFC5682] or Eifel 627 [RFC3522]. Once a spurious congestion event is detected, CUBIC 628 SHOULD restore the original values of above mentioned variables as 629 follows if the current _cwnd_ is lower than _prior_cwnd_. Restoring 630 to the original values ensures that CUBIC's performance is similar to 631 what it would be if there were no spurious losses. 633 \ 634 cwnd = prior_cwnd | 635 | 636 ssthresh = prior_ssthresh | 637 | 638 W = prior_W | 639 max max | 640 >if cwnd < prior_cwnd 641 K = prior_K | 642 | 643 epoch = prior_epoch | 644 start start| 645 | 646 W = prior_W | 647 est est / 649 In rare cases, when the detection happens long after a spurious loss 650 event and the current _cwnd_ is already higher than the _prior_cwnd_, 651 CUBIC SHOULD continue to use the current and the most recent values 652 of these variables. 654 4.10. Slow Start 656 CUBIC MUST employ a slow-start algorithm, when _cwnd_ is no more than 657 _ssthresh_. Among the slow-start algorithms, CUBIC MAY choose the 658 standard TCP slow start [RFC5681] in general networks, or the limited 659 slow start [RFC3742] or hybrid slow start [HR08] for fast and long- 660 distance networks. 662 In the case when CUBIC runs the hybrid slow start [HR08], it may exit 663 the first slow start without incurring any packet loss and thus 664 _W_(max)_ is undefined. In this special case, CUBIC switches to 665 congestion avoidance and increases its congestion window size using 666 Figure 1, where t is the elapsed time since the beginning of the 667 current congestion avoidance, _K_ is set to 0, and _W_(max)_ is set 668 to the congestion window size at the beginning of the current 669 congestion avoidance. 671 5. Discussion 673 In this section, we further discuss the safety features of CUBIC 674 following the guidelines specified in [RFC5033]. 676 With a deterministic loss model where the number of packets between 677 two successive packet losses is always _1/p_, CUBIC always operates 678 with the concave window profile, which greatly simplifies the 679 performance analysis of CUBIC. The average window size of CUBIC can 680 be obtained by the following function: 682 ________________ ____ 683 /C * (3 + β ) 3 / 4 684 4 / cubic |/ RTT 685 AVG_W = | / ---------------- * ------- 686 cubic | / 4 * (1 - β ) __ 687 |/ cubic 3 / 4 688 |/ p 690 Figure 5 692 With β__(cubic)_ set to 0.7, the above formula is reduced to: 694 ____ 695 _______ 3 / 4 696 4 /C * 3.7 |/ RTT 697 AVG_W = | / ------- * ------- 698 cubic |/ 1.2 __ 699 3 / 4 700 |/ p 702 Figure 6 704 We will determine the value of _C_ in the following subsection using 705 Figure 6. 707 5.1. Fairness to Standard TCP 709 In environments where Standard TCP is able to make reasonable use of 710 the available bandwidth, CUBIC does not significantly change this 711 state. 713 Standard TCP performs well in the following two types of networks: 715 1. networks with a small bandwidth-delay product (BDP) 717 2. networks with a short RTTs, but not necessarily a small BDP 719 CUBIC is designed to behave very similarly to Standard TCP in the 720 above two types of networks. The following two tables show the 721 average window sizes of Standard TCP, HSTCP, and CUBIC. The average 722 window sizes of Standard TCP and HSTCP are from [RFC3649]. The 723 average window size of CUBIC is calculated using Figure 6 and the 724 CUBIC TCP-friendly region for three different values of _C_. 726 +=============+=======+========+================+=========+========+ 727 | Loss Rate P | TCP | HSTCP | CUBIC (C=0.04) | CUBIC | CUBIC | 728 | | | | | (C=0.4) | (C=4) | 729 +=============+=======+========+================+=========+========+ 730 | 1.0e-02 | 12 | 12 | 12 | 12 | 12 | 731 +-------------+-------+--------+----------------+---------+--------+ 732 | 1.0e-03 | 38 | 38 | 38 | 38 | 59 | 733 +-------------+-------+--------+----------------+---------+--------+ 734 | 1.0e-04 | 120 | 263 | 120 | 187 | 333 | 735 +-------------+-------+--------+----------------+---------+--------+ 736 | 1.0e-05 | 379 | 1795 | 593 | 1054 | 1874 | 737 +-------------+-------+--------+----------------+---------+--------+ 738 | 1.0e-06 | 1200 | 12280 | 3332 | 5926 | 10538 | 739 +-------------+-------+--------+----------------+---------+--------+ 740 | 1.0e-07 | 3795 | 83981 | 18740 | 33325 | 59261 | 741 +-------------+-------+--------+----------------+---------+--------+ 742 | 1.0e-08 | 12000 | 574356 | 105383 | 187400 | 333250 | 743 +-------------+-------+--------+----------------+---------+--------+ 745 Table 1: Standard TCP, HSTCP, and CUBIC with RTT = 0.1 seconds 747 Table 1 describes the response function of Standard TCP, HSTCP, and 748 CUBIC in networks with _RTT_ = 0.1 seconds. The average window size 749 is in MSS-sized segments. 751 +=============+=======+========+================+=========+=======+ 752 | Loss Rate P | TCP | HSTCP | CUBIC (C=0.04) | CUBIC | CUBIC | 753 | | | | | (C=0.4) | (C=4) | 754 +=============+=======+========+================+=========+=======+ 755 | 1.0e-02 | 12 | 12 | 12 | 12 | 12 | 756 +-------------+-------+--------+----------------+---------+-------+ 757 | 1.0e-03 | 38 | 38 | 38 | 38 | 38 | 758 +-------------+-------+--------+----------------+---------+-------+ 759 | 1.0e-04 | 120 | 263 | 120 | 120 | 120 | 760 +-------------+-------+--------+----------------+---------+-------+ 761 | 1.0e-05 | 379 | 1795 | 379 | 379 | 379 | 762 +-------------+-------+--------+----------------+---------+-------+ 763 | 1.0e-06 | 1200 | 12280 | 1200 | 1200 | 1874 | 764 +-------------+-------+--------+----------------+---------+-------+ 765 | 1.0e-07 | 3795 | 83981 | 3795 | 5926 | 10538 | 766 +-------------+-------+--------+----------------+---------+-------+ 767 | 1.0e-08 | 12000 | 574356 | 18740 | 33325 | 59261 | 768 +-------------+-------+--------+----------------+---------+-------+ 770 Table 2: Standard TCP, HSTCP, and CUBIC with RTT = 0.01 seconds 772 Table 2 describes the response function of Standard TCP, HSTCP, and 773 CUBIC in networks with _RTT_ = 0.01 seconds. The average window size 774 is in MSS-sized segments. 776 Both tables show that CUBIC with any of these three _C_ values is 777 more friendly to TCP than HSTCP, especially in networks with a short 778 _RTT_ where TCP performs reasonably well. For example, in a network 779 with _RTT_ = 0.01 seconds and p=10^-6, TCP has an average window of 780 1200 packets. If the packet size is 1500 bytes, then TCP can achieve 781 an average rate of 1.44 Gbps. In this case, CUBIC with _C_=0.04 or 782 _C_=0.4 achieves exactly the same rate as Standard TCP, whereas HSTCP 783 is about ten times more aggressive than Standard TCP. 785 We can see that _C_ determines the aggressiveness of CUBIC in 786 competing with other congestion control algorithms for bandwidth. 787 CUBIC is more friendly to Standard TCP, if the value of _C_ is lower. 788 However, we do not recommend setting _C_ to a very low value like 789 0.04, since CUBIC with a low _C_ cannot efficiently use the bandwidth 790 in long-_RTT_ and high-bandwidth networks. Based on these 791 observations and our experiments, we find _C_=0.4 gives a good 792 balance between TCP- friendliness and aggressiveness of window 793 increase. Therefore, _C_ SHOULD be set to 0.4. With _C_ set to 0.4, 794 Figure 6 is reduced to: 796 ____ 797 3 / 4 798 |/ RTT 799 AVG_W = 1.054 * ------- 800 cubic __ 801 3 / 4 802 |/ p 804 Figure 7 806 Figure 7 is then used in the next subsection to show the scalability 807 of CUBIC. 809 5.2. Using Spare Capacity 811 CUBIC uses a more aggressive window increase function than Standard 812 TCP under long-_RTT_ and high-bandwidth networks. 814 The following table shows that to achieve the 10 Gbps rate, Standard 815 TCP requires a packet loss rate of 2.0e-10, while CUBIC requires a 816 packet loss rate of 2.9e-8. 818 +===================+===========+=========+=========+=========+ 819 | Throughput (Mbps) | Average W | TCP P | HSTCP P | CUBIC P | 820 +===================+===========+=========+=========+=========+ 821 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | 822 +-------------------+-----------+---------+---------+---------+ 823 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | 824 +-------------------+-----------+---------+---------+---------+ 825 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | 826 +-------------------+-----------+---------+---------+---------+ 827 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | 828 +-------------------+-----------+---------+---------+---------+ 829 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | 830 +-------------------+-----------+---------+---------+---------+ 832 Table 3: Required packet loss rate for Standard TCP, HSTCP, 833 and CUBIC to achieve a certain throughput 835 Table 3 describes the required packet loss rate for Standard TCP, 836 HSTCP, and CUBIC to achieve a certain throughput. We use 1500-byte 837 packets and an _RTT_ of 0.1 seconds. 839 Our test results in [HKLRX06] indicate that CUBIC uses the spare 840 bandwidth left unused by existing Standard TCP flows in the same 841 bottleneck link without taking away much bandwidth from the existing 842 flows. 844 5.3. Difficult Environments 846 CUBIC is designed to remedy the poor performance of TCP in fast and 847 long-distance networks. 849 5.4. Investigating a Range of Environments 851 CUBIC has been extensively studied by using both NS-2 simulation and 852 test-bed experiments covering a wide range of network environments. 853 More information can be found in [HKLRX06]. 855 Same as Standard TCP, CUBIC is a loss-based congestion control 856 algorithm. Because CUBIC is designed to be more aggressive (due to a 857 faster window increase function and bigger multiplicative decrease 858 factor) than Standard TCP in fast and long-distance networks, it can 859 fill large drop-tail buffers more quickly than Standard TCP and 860 increase the risk of a standing queue [RFC8511]. In this case, 861 proper queue sizing and management [RFC7567] could be used to reduce 862 the packet queuing delay. 864 5.5. Protection against Congestion Collapse 866 With regard to the potential of causing congestion collapse, CUBIC 867 behaves like Standard TCP since CUBIC modifies only the window 868 adjustment algorithm of TCP. Thus, it does not modify the ACK 869 clocking and Timeout behaviors of Standard TCP. 871 5.6. Fairness within the Alternative Congestion Control Algorithm 873 CUBIC ensures convergence of competing CUBIC flows with the same 874 _RTT_ in the same bottleneck links to an equal throughput. When 875 competing flows have different _RTT_ values, their throughput ratio 876 is linearly proportional to the inverse of their _RTT_ ratios. This 877 is true independent of the level of statistical multiplexing in the 878 link. 880 5.7. Performance with Misbehaving Nodes and Outside Attackers 882 This is not considered in the current CUBIC. 884 5.8. Behavior for Application-Limited Flows 886 CUBIC does not raise its congestion window size if the flow is 887 currently limited by the application instead of the congestion 888 window. In case of long periods when _cwnd_ has not been updated due 889 to the application rate limit, such as idle periods, t in Figure 1 890 MUST NOT include these periods; otherwise, W_(cubic)(_t_) might be 891 very high after restarting from these periods. 893 5.9. Responses to Sudden or Transient Events 895 If there is a sudden congestion, a routing change, or a mobility 896 event, CUBIC behaves the same as Standard TCP. 898 5.10. Incremental Deployment 900 CUBIC requires only the change of TCP senders, and it does not make 901 any changes to TCP receivers. That is, a CUBIC sender works 902 correctly with the Standard TCP receivers. In addition, CUBIC does 903 not require any changes to the routers and does not require any 904 assistance from the routers. 906 6. Security Considerations 908 This proposal makes no changes to the underlying security of TCP. 909 More information about TCP security concerns can be found in 910 [RFC5681]. 912 7. IANA Considerations 914 This document does not require any IANA actions. 916 8. References 918 8.1. Normative References 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, 922 DOI 10.17487/RFC2119, March 1997, 923 . 925 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 926 of Explicit Congestion Notification (ECN) to IP", 927 RFC 3168, DOI 10.17487/RFC3168, September 2001, 928 . 930 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 931 Control Algorithms", BCP 133, RFC 5033, 932 DOI 10.17487/RFC5033, August 2007, 933 . 935 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 936 Friendly Rate Control (TFRC): Protocol Specification", 937 RFC 5348, DOI 10.17487/RFC5348, September 2008, 938 . 940 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 941 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 942 . 944 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 945 "Computing TCP's Retransmission Timer", RFC 6298, 946 DOI 10.17487/RFC6298, June 2011, 947 . 949 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 950 NewReno Modification to TCP's Fast Recovery Algorithm", 951 RFC 6582, DOI 10.17487/RFC6582, April 2012, 952 . 954 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 955 and Y. Nishida, "A Conservative Loss Recovery Algorithm 956 Based on Selective Acknowledgment (SACK) for TCP", 957 RFC 6675, DOI 10.17487/RFC6675, August 2012, 958 . 960 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 961 Recommendations Regarding Active Queue Management", 962 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 963 . 965 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 966 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 967 May 2017, . 969 8.2. Informative References 971 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic 972 Ordering for Internet Congestion Control and its 973 Applications", IEEE INFOCOM 2007 - 26th IEEE International 974 Conference on Computer Communications, 975 DOI 10.1109/infcom.2007.111, 2007, 976 . 978 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of 979 Equation-Based and AIMD Congestion Control", May 2000, 980 . 982 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary 983 Adjustment Algorithms", Technical Report TR2002-29, 984 Department of Computer Sciences, The University of 985 Texas at Austin, 11 August 2002, 986 . 988 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step 989 toward Realistic Performance Evaluation of High-Speed TCP 990 Variants", International Workshop on Protocols for Fast 991 Long-Distance Networks, February 2006, 992 . 994 [HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth 995 and Long-Distance Networks", International Workshop 996 on Protocols for Fast Long-Distance Networks, March 2008, 997 . 1000 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: a new TCP-friendly 1001 high-speed TCP variant", ACM SIGOPS Operating Systems 1002 Review Vol. 42, pp. 64-74, DOI 10.1145/1400097.1400105, 1003 July 2008, . 1005 [K03] Kelly, T., "Scalable TCP: improving performance in 1006 highspeed wide area networks", ACM SIGCOMM Computer 1007 Communication Review Vol. 33, pp. 83-91, 1008 DOI 10.1145/956981.956989, April 2003, 1009 . 1011 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 1012 for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003, 1013 . 1015 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 1016 RFC 3649, DOI 10.17487/RFC3649, December 2003, 1017 . 1019 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 1020 Acknowledgement (DSACKs) and Stream Control Transmission 1021 Protocol (SCTP) Duplicate Transmission Sequence Numbers 1022 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 1023 DOI 10.17487/RFC3708, February 2004, 1024 . 1026 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 1027 Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March 1028 2004, . 1030 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1031 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1032 . 1034 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 1035 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 1036 Spurious Retransmission Timeouts with TCP", RFC 5682, 1037 DOI 10.17487/RFC5682, September 2009, 1038 . 1040 [RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and 1041 R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", 1042 RFC 8312, DOI 10.17487/RFC8312, February 2018, 1043 . 1045 [RFC8511] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst, 1046 "TCP Alternative Backoff with ECN (ABE)", RFC 8511, 1047 DOI 10.17487/RFC8511, December 2018, 1048 . 1050 [SXEZ19] Sun, W., Xu, L., Elbaum, S., and D. Zhao, "Model-Agnostic 1051 and Efficient Exploration of Numerical State Space of 1052 Real-World TCP Congestion Control Implementations", USENIX 1053 NSDI 2019, February 2019, 1054 . 1056 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase 1057 Congestion Control (BIC) for Fast Long-Distance Networks", 1058 IEEE INFOCOM 2004, DOI 10.1109/infcom.2004.1354672, March 1059 2004, . 1061 Appendix A. Acknowledgements 1063 Richard Scheffenegger and Alexander Zimmermann originally co-authored 1064 [RFC8312]. 1066 Appendix B. Evolution of CUBIC 1068 B.1. Since draft-eggert-tcpm-rfc8312bis-00 1070 * acknowledge former co-authors (#15 1071 (https://github.com/NTAP/rfc8312bis/issues/15)) 1073 * prevent _cwnd_ from becoming less than two (#7 1074 (https://github.com/NTAP/rfc8312bis/issues/7)) 1076 * add list of variables and constants (#5 1077 (https://github.com/NTAP/rfc8312bis/issues/5), #6 1078 (https://github.com/NTAP/rfc8312bis/issues/5)) 1080 * update _K_'s definition and add bounds for CUBIC _target_ _cwnd_ 1081 [SXEZ19] (#1 (https://github.com/NTAP/rfc8312bis/issues/1), #14 1082 (https://github.com/NTAP/rfc8312bis/issues/14)) 1084 * update _W_(est)_ to use AIMD approach (#20 1085 (https://github.com/NTAP/rfc8312bis/issues/20)) 1087 * set alpha__(aimd)_ to 1 once _W_(est)_ reaches _W_(max)_ (#2 1088 (https://github.com/NTAP/rfc8312bis/issues/2)) 1090 * add Vidhi as co-author 1092 * (#17 (https://github.com/NTAP/rfc8312bis/issues/17)) 1094 * note for fast recovery during _cwnd_ decrease due to congestion 1095 event (#11 (https://github.com/NTAP/rfc8312bis11/issues/11)) 1097 * add section for spurious congestion events (#23 1098 (https://github.com/NTAP/rfc8312bis/issues/23)) 1100 * initialize _W_(est)_ after timeout and remove variable 1101 _W_(last_max)_ (#28 (https://github.com/NTAP/rfc8312bis/ 1102 issues/28)) 1104 B.2. Since RFC8312 1106 * converted to Markdown and xml2rfc v3 1108 * updated references (as part of the conversion) 1110 * updated author information 1112 * various formatting changes 1114 * move to Standards Track 1116 B.3. Since the Original Paper 1118 CUBIC has gone through a few changes since the initial release 1119 [HRX08] of its algorithm and implementation. Below we highlight the 1120 differences between its original paper and [RFC8312]. 1122 * The original paper [HRX08] includes the pseudocode of CUBIC 1123 implementation using Linux's pluggable congestion control 1124 framework, which excludes system-specific optimizations. The 1125 simplified pseudocode might be a good source to start with and 1126 understand CUBIC. 1128 * [HRX08] also includes experimental results showing its performance 1129 {{and fairness. 1131 * The definition of beta__(cubic)_ constant was changed in 1132 [RFC8312]. For example, beta__(cubic)_ in the original paper was 1133 the window decrease constant while [RFC8312] changed it to CUBIC 1134 multiplication decrease factor. With this change, the current 1135 congestion window size after a congestion event in [RFC8312] was 1136 beta__(cubic)_ * _W_(max)_ while it was (1-beta__(cubic)_) * 1137 _W_(max)_ in the original paper. 1139 * Its pseudocode used _W_(last_max)_ while [RFC8312] used _W_(max)_. 1141 * Its TCP friendly window was W_(tcp) while [RFC8312] used 1142 _W_(est)_. 1144 Authors' Addresses 1146 Lisong Xu 1147 University of Nebraska-Lincoln 1148 Department of Computer Science and Engineering 1149 Lincoln, NE 68588-0115 1150 United States of America 1152 Email: xu@unl.edu 1153 URI: https://cse.unl.edu/~xu/ 1155 Sangtae Ha 1156 University of Colorado at Boulder 1157 Department of Computer Science 1158 Boulder, CO 80309-0430 1159 United States of America 1161 Email: sangtae.ha@colorado.edu 1162 URI: https://netstech.org/sangtaeha/ 1164 Injong Rhee 1165 Bowery Farming 1166 151 W 26TH Street, 12TH Floor 1167 New York, NY 10001 1168 United States of America 1170 Email: injongrhee@gmail.com 1171 Vidhi Goel 1172 Apple Inc. 1173 One Apple Park Way 1174 Cupertino, California 95014 1175 United States of America 1177 Email: vidhi_goel@apple.com 1179 Lars Eggert (editor) 1180 NetApp 1181 Stenbergintie 12 B 1182 FI-02700 Kauniainen 1183 Finland 1185 Email: lars@eggert.org 1186 URI: https://eggert.org/