idnits 2.17.1 draft-ietf-tcpm-cubic-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2016) is 3022 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions (TCPM) WG I. Rhee 3 Internet-Draft NCSU 4 Intended status: Informational L. Xu 5 Expires: July 21, 2016 UNL 6 S. Ha 7 Colorado 8 A. Zimmermann 9 L. Eggert 10 R. Scheffenegger 11 NetApp 12 January 18, 2016 14 CUBIC for Fast Long-Distance Networks 15 draft-ietf-tcpm-cubic-01 17 Abstract 19 CUBIC is an extension to the current TCP standards. The protocol 20 differs from the current TCP standards only in the congestion window 21 adjustment function in the sender side. In particular, it uses a 22 cubic function instead of a linear window increase of the current TCP 23 standards to improve scalability and stability under fast and long 24 distance networks. BIC-TCP, a predecessor of CUBIC, has been a 25 default TCP adopted by Linux since year 2005 and has already been 26 deployed globally and in use for several years by the Internet 27 community at large. CUBIC is using a similar window growth function 28 as BIC-TCP and is designed to be less aggressive and fairer to TCP in 29 bandwidth usage than BIC-TCP while maintaining the strengths of BIC- 30 TCP such as stability, window scalability and RTT fairness. Through 31 extensive testing in various Internet scenarios, we believe that 32 CUBIC is safe for deployment and testing in the global Internet. The 33 intent of this document is to provide the protocol specification of 34 CUBIC for a third party implementation and solicit the community 35 feedback through experimentation on the performance of CUBIC. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on July 21, 2016. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5 74 3.1. Window growth function . . . . . . . . . . . . . . . . . 5 75 3.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 6 76 3.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7 77 3.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7 78 3.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 7 79 3.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 7 80 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 8 82 4.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 10 83 4.3. Difficult Environments . . . . . . . . . . . . . . . . . 11 84 4.4. Investigating a Range of Environments . . . . . . . . . . 11 85 4.5. Protection against Congestion Collapse . . . . . . . . . 11 86 4.6. Fairness within the Alternative Congestion Control 87 Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.7. Performance with Misbehaving Nodes and Outside Attackers 11 89 4.8. Responses to Sudden or Transient Events . . . . . . . . . 11 90 4.9. Incremental Deployment . . . . . . . . . . . . . . . . . 11 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 96 8.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 100 1. Introduction 102 The low utilization problem of TCP in fast long-distance networks is 103 well documented in [K03][RFC3649]. This problem arises from a slow 104 increase of congestion window following a congestion event in a 105 network with a large bandwidth delay product (BDP). Our experience 106 [HKLRX06] indicates that this problem is frequently observed even in 107 the range of congestion window sizes over several hundreds of packets 108 (each packet is sized around 1000 bytes) especially under a network 109 path with over 100ms round-trip times (RTTs). This problem is 110 equally applicable to all Reno style TCP standards and their 111 variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP- 112 SACK [RFC2018], SCTP [RFC4960], TFRC [RFC5348] that use the same 113 linear increase function for window growth, which we refer to 114 collectively as Standard TCP below. 116 CUBIC [HRX08] is a modification to the congestion control mechanism 117 of Standard TCP, in particular, to the window increase function of 118 Standard TCP senders, to remedy this problem. It uses a cubic 119 increase function in terms of the elapsed time from the last 120 congestion event. While most alternative algorithms to Standard TCP 121 uses a convex increase function where after a loss event, the window 122 increment is always increasing, CUBIC uses both the concave and 123 convex profiles of a cubic function for window increase. After a 124 window reduction following a loss event, it registers the window size 125 where it got the loss event as W_max and performs a multiplicative 126 decrease of congestion window and the regular fast recovery and 127 retransmit of Standard TCP. After it enters into congestion 128 avoidance from fast recovery, it starts to increase the window using 129 the concave profile of the cubic function. The cubic function is set 130 to have its plateau at W_max so the concave growth continues until 131 the window size becomes W_max. After that, the cubic function turns 132 into a convex profile and the convex window growth begins. This 133 style of window adjustment (concave and then convex) improves 134 protocol and network stability while maintaining high network 135 utilization [CEHRX07]. This is because the window size remains 136 almost constant, forming a plateau around W_max where network 137 utilization is deemed highest and under steady state, most window 138 size samples of CUBIC are close to W_max, thus promoting high network 139 utilization and protocol stability. Note that protocols with convex 140 increase functions have the maximum increments around W_max and 141 introduces a large number of packet bursts around the saturation 142 point of the network, likely causing frequent global loss 143 synchronizations. 145 Another notable feature of CUBIC is that its window increase rate is 146 mostly independent of RTT, and follows a (cubic) function of the 147 elapsed time since the last loss event. This feature promotes per- 148 flow fairness to Standard TCP as well as RTT-fairness. Note that 149 Standard TCP performs well under short RTT and small bandwidth (or 150 small BDP) networks. Only in a large long RTT and large bandwidth 151 (or large BDP) networks, it has the scalability problem. An 152 alternative protocol to Standard TCP designed to be friendly to 153 Standard TCP at a per-flow basis must operate to increase its window 154 much less aggressively in small BDP networks than in large BDP 155 networks. In CUBIC, its window growth rate is slowest around the 156 inflection point of the cubic function and this function does not 157 depend on RTT. In a smaller BDP network where Standard TCP flows are 158 working well, the absolute amount of the window decrease at a loss 159 event is always smaller because of the multiplicative decrease. 160 Therefore, in CUBIC, the starting window size after a loss event from 161 which the window starts to increase, is smaller in a smaller BDP 162 network, thus falling nearer to the plateau of the cubic function 163 where the growth rate is slowest. By setting appropriate values of 164 the cubic function parameters, CUBIC sets its growth rate always no 165 faster than Standard TCP around its inflection point. When the cubic 166 function grows slower than the window of Standard TCP, CUBIC simply 167 follows the window size of Standard TCP to ensure fairness to 168 Standard TCP in a small BDP network. We call this region where CUBIC 169 behaves like Standard TCP, the TCP-friendly region. 171 CUBIC maintains the same window growth rate independent of RTTs 172 outside of the TCP-friendly region, and flows with different RTTs 173 have the similar window sizes under steady state when they operate 174 outside the TCP-friendly region. This ensures CUBIC flows with 175 different RTTs to have their bandwidth shares linearly proportional 176 to the inverse of their RTT ratio (the longer RTT, the smaller the 177 share). This behavior is the same as that of Standard TCP under high 178 statistical multiplexing environments where packet losses are 179 independent of individual flow rates. However, under low statistical 180 multiplexing environments, the bandwidth share ratio of Standard TCP 181 flows with different RTTs is squarely proportional to the inverse of 182 their RTT ratio [XHR04]. CUBIC always ensures the linear ratio 183 independent of the levels of statistical multiplexing. This is an 184 improvement over Standard TCP. While there is no consensus on a 185 particular bandwidth share ratios of different RTT flows, we believe 186 that under wired Internet, use of the linear share notion seems more 187 reasonable than equal share or a higher order shares. HTCP [LS08] 188 currently uses the equal share. 190 CUBIC sets the multiplicative window decrease factor to 0.7 while 191 Standard TCP uses 0.5. While this improves the scalability of the 192 protocol, a side effect of this decision is slower convergence 193 especially under low statistical multiplexing environments. This 194 design choice is following the observation that the author of HSTCP 195 [RFC3649] has made along with other researchers (e.g., [GV02]): the 196 current Internet becomes more asynchronous with less frequent loss 197 synchronizations with high statistical multiplexing. Under this 198 environment, even strict MIMD can converge. CUBIC flows with the 199 same RTT always converge to the same share of bandwidth independent 200 of statistical multiplexing, thus achieving intra-protocol fairness. 201 We also find that under the environments with sufficient statistical 202 multiplexing, the convergence speed of CUBIC flows is reasonable. 204 In the ensuing sections, we provide the exact specification of CUBIC 205 and discuss the safety features of CUBIC following the guidelines 206 specified in [RFC5033]. 208 2. Conventions 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [RFC2119]. 214 3. CUBIC Congestion Control 216 The unit of all window sizes in this document is segments of the 217 maximum segment size (MSS), and the unit of all times is seconds. 219 3.1. Window growth function 221 CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by 222 increasing congestion window only at the reception of ACK. The 223 protocol does not make any change to the fast recovery and retransmit 224 of TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During congestion 225 avoidance after fast recovery, CUBIC changes the window update 226 algorithm of Standard TCP. Suppose that W_max is the window size 227 before the window is reduced in the last fast retransmit and 228 recovery. 230 The window growth function of CUBIC uses the following function: 232 W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) 234 where C is a constant fixed to determine the aggressiveness of window 235 growth in high BDP networks, t is the elapsed time from the last 236 window reduction,and K is the time period that the above function 237 takes to increase the current window size to W_max when there is no 238 further loss event and is calculated by using the following equation: 240 K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2) 242 where beta_cubic is the CUBIC multiplication decrease factor, that 243 is, when a packet loss occurs, CUBIC reduces its current window cwnd 244 to cwnd*beta_cubic. We discuss how we set C in the next Section in 245 more details. 247 Upon receiving an ACK during congestion avoidance, CUBIC computes the 248 window growth rate during the next RTT period using Eq. 1. It sets 249 W_cubic(t+RTT) as the candidate target value of congestion window. 251 Depending on the value of the current window size cwnd, CUBIC runs in 252 three different modes. First, if cwnd is less than the window size 253 that Standard TCP would reach at time t after the last loss event, 254 then CUBIC is in the TCP friendly region (we describe below how to 255 determine this window size of Standard TCP in term of time t). 256 Otherwise, if cwnd is less than W_max, then CUBIC is the concave 257 region, and if cwnd is larger than W_max, CUBIC is in the convex 258 region. Below, we describe the exact actions taken by CUBIC in each 259 region. 261 3.2. TCP-friendly region 263 When receiving an ACK in congestion avoidance, we first check whether 264 the protocol is in the TCP region or not. This is done as follows. 265 We can analyze the window size of a TCP-friendly AIMD in terms of the 266 elapsed time t. Using a simple analysis in [FHP00], we can analyze 267 the average window size of additive increase and multiplicative 268 decrease (AIMD) with an additive factor alpha_aimd and a 269 multiplicative factor beta_aimd with the following function: 271 AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / 272 (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) 274 By the same analysis, the average window size of Standard TCP is 275 (1.5/p)^0.5, as the Standard TCP is a special case of AIMD with 276 alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as 277 that of Standard TCP, alpha_aimd must be equal to 278 3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by 279 alpha_aimd per RTT, we can get the window size of AIMD in terms of 280 the elapsed time t as follows: 282 W_aimd(t) = W_max*beta_aimd + 283 [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) 285 If W_cubic(t) is less than W_aimd(t), then the protocol is in the TCP 286 friendly region and cwnd SHOULD be set to W_aimd(t) at each reception 287 of ACK. 289 3.3. Concave region 291 When receiving an ACK in congestion avoidance, if the protocol is not 292 in the TCP-friendly region and cwnd is less than W_max, then the 293 protocol is in the concave region. In this region, cwnd MUST be 294 incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK. 296 3.4. Convex region 298 When the current window size of CUBIC is larger than W_max, it passes 299 the plateau of the cubic function after which CUBIC follows the 300 convex profile of the cubic function. Since cwnd is larger than the 301 previous saturation point W_max, this indicates that the network 302 conditions might have been perturbed since the last loss event, 303 possibly implying more available bandwidth after some flow 304 departures. Since the Internet is highly asynchronous, some amount 305 of perturbation is always possible without causing a major change in 306 available bandwidth. In this phase, CUBIC is being very careful by 307 very slowly increasing its window size. The convex profile ensures 308 that the window increases very slowly at the beginning and gradually 309 increases its growth rate. We also call this phase as the maximum 310 probing phase since CUBIC is searching for a new W_max. In this 311 region, cwnd MUST be incremented by (W_cubic(t+RTT) - cwnd)/cwnd for 312 each received ACK. 314 3.5. Multiplicative decrease 316 When a packet loss occurs, CUBIC reduces its window size by a factor 317 of beta. Parameter beta_cubic SHOULD be set to 0.7. 319 W_max = cwnd; // save window size before reduction 320 cwnd = cwnd * beta_cubic; // window reduction 322 A side effect of setting beta_cubic to a bigger value than 0.5 is 323 slower convergence. We believe that while a more adaptive setting of 324 beta_cubic could result in faster convergence, it will make the 325 analysis of the protocol much harder. This adaptive adjustment of 326 beta_cubic is an item for the next version of CUBIC. 328 3.6. Fast convergence 330 To improve the convergence speed of CUBIC, we add a heuristic in the 331 protocol. When a new flow joins the network, existing flows in the 332 network need to give up their bandwidth shares to allow the flow some 333 room for growth if the existing flows have been using all the 334 bandwidth of the network. To increase this release of bandwidth by 335 existing flows, the following mechanism called fast convergence 336 SHOULD be implemented. 338 With fast convergence, when a loss event occurs, before a window 339 reduction of congestion window, a flow remembers the last value of 340 W_max before it updates W_max for the current loss event. Let us 341 call the last value of W_max to be W_last_max. 343 if (W_max < W_last_max){ // check downward trend 344 W_last_max = W_max; // remember the last W_max 345 W_max = W_max*(1+beta_cubic)/2; // further reduce W_max 346 } else { // check upward trend 347 W_last_max = W_max // remember the last W_max 348 } 350 This allows W_max to be slightly less than the original W_max. Since 351 flows spend most of time around their W_max, flows with larger 352 bandwidth shares tend to spend more time around the plateau allowing 353 more time for flows with smaller shares to increase their windows. 355 4. Discussion 357 With a deterministic loss model where the number of packets between 358 two successive lost events is always 1/p, CUBIC always operates with 359 the concave window profile which greatly simplifies the performance 360 analysis of CUBIC. The average window size of CUBIC can be obtained 361 by the following function: 363 AVG_W_cubic = [C*(3+beta_cubic)/(4*(1-beta_cubic))]^0.25 * 364 (RTT^0.75) / (p^0.75) (Eq. 5) 366 With beta_cubic set to 0.7, the above formula is reduced to: 368 AVG_W_cubic = (C*3.7/1.2)^0.25 * (RTT^0.75) / (p^0.75) (Eq. 6) 370 We will determine the value of C in the following subsection using 371 Eq. 6. 373 4.1. Fairness to standard TCP 375 In environments where standard TCP is able to make reasonable use of 376 the available bandwidth, CUBIC does not significantly change this 377 state. 379 Standard TCP performs well in the following two types of networks: 381 1. networks with a small bandwidth-delay product (BDP) 383 2. networks with a short RTT, but not necessarily a small BDP 385 CUBIC is designed to behave very similarly to standard TCP in the 386 above two types of networks. The following two tables show the 387 average window size of standard TCP, HSTCP, and CUBIC. The average 388 window size of standard TCP and HSTCP is from [RFC3649]. The average 389 window size of CUBIC is calculated by using Eq. 6 and CUBIC TCP 390 friendly mode for three different values of C. 392 +----------+-------+--------+-------------+-------------+-----------+ 393 | Loss | TCP | HSTCP | CUBIC | CUBIC | CUBIC | 394 | Rate P | | | (C=0.04) | (C=0.4) | (C=4) | 395 +----------+-------+--------+-------------+-------------+-----------+ 396 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 397 | 10^-3 | 38 | 38 | 38 | 38 | 59 | 398 | 10^-4 | 120 | 263 | 120 | 187 | 333 | 399 | 10^-5 | 379 | 1795 | 593 | 1054 | 1874 | 400 | 10^-6 | 1200 | 12279 | 3332 | 5926 | 10538 | 401 | 10^-7 | 3795 | 83981 | 18740 | 33325 | 59261 | 402 | 10^-8 | 12000 | 574356 | 105383 | 187400 | 333250 | 403 +----------+-------+--------+-------------+-------------+-----------+ 405 Response function of standard TCP, HSTCP, and CUBIC in networks with 406 RTT = 0.1 seconds. The average window size is in MSS-sized segments. 408 Table 1 410 +--------+-----------+-----------+------------+-----------+---------+ 411 | Loss | Average | Average | CUBIC | CUBIC | CUBIC | 412 | Rate P | TCP W | HSTCP W | (C=0.04) | (C=0.4) | (C=4) | 413 +--------+-----------+-----------+------------+-----------+---------+ 414 | 10^-2 | 12 | 12 | 12 | 12 | 12 | 415 | 10^-3 | 38 | 38 | 38 | 38 | 38 | 416 | 10^-4 | 120 | 263 | 120 | 120 | 120 | 417 | 10^-5 | 379 | 1795 | 379 | 379 | 379 | 418 | 10^-6 | 1200 | 12279 | 1200 | 1200 | 1874 | 419 | 10^-7 | 3795 | 83981 | 3795 | 5926 | 10538 | 420 | 10^-8 | 12000 | 574356 | 18740 | 33325 | 59261 | 421 +--------+-----------+-----------+------------+-----------+---------+ 423 Response function of standard TCP, HSTCP, and CUBIC in networks with 424 RTT = 0.01 seconds. The average window size is in MSS-sized 425 segments. 427 Table 2 429 Both tables show that CUBIC with any of these three C values is more 430 friendly to TCP than HSTCP, especially in networks with a short RTT 431 where TCP performs reasonably well. For example, in a network with 432 RTT = 0.01 seconds and p=10^-6, TCP has an average window of 1200 433 packets. If the packet size is 1500 bytes, then TCP can achieve an 434 average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 435 achieves exactly the same rate as Standard TCP, whereas HSTCP is 436 about ten times more aggressive than Standard TCP. 438 We can see that C determines the aggressiveness of CUBIC in competing 439 with other protocols for the bandwidth. CUBIC is more friendly to 440 the Standard TCP, if the value of C is lower. However, we do not 441 recommend to set C to a very low value like 0.04, since CUBIC with a 442 low C cannot efficiently use the bandwidth in long RTT and high 443 bandwidth networks. Based on these observations, we find C=0.4 gives 444 a good balance between TCP-friendliness and aggressiveness of window 445 growth. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6 446 is reduced to: 448 AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) 450 Eq. 7 is then used in the next subsection to show the scalability of 451 CUBIC. 453 4.2. Using Spare Capacity 455 CUBIC uses a more aggressive window growth function than Standard TCP 456 under long RTT and high bandwidth networks. 458 The following table shows that to achieve 10Gbps rate, standard TCP 459 requires a packet loss rate of 2.0e-10, while CUBIC requires a packet 460 loss rate of 2.9e-8. 462 +------------------+-----------+---------+---------+---------+ 463 | Throughput(Mbps) | Average W | TCP P | HSTCP P | CUBIC P | 464 +------------------+-----------+---------+---------+---------+ 465 | 1 | 8.3 | 2.0e-2 | 2.0e-2 | 2.0e-2 | 466 | 10 | 83.3 | 2.0e-4 | 3.9e-4 | 2.9e-4 | 467 | 100 | 833.3 | 2.0e-6 | 2.5e-5 | 1.4e-5 | 468 | 1000 | 8333.3 | 2.0e-8 | 1.5e-6 | 6.3e-7 | 469 | 10000 | 83333.3 | 2.0e-10 | 1.0e-7 | 2.9e-8 | 470 +------------------+-----------+---------+---------+---------+ 472 Required packet loss rate for Standard TCP, HSTCP, and CUBIC to 473 achieve a certain throughput. We use 1500-byte packets and an RTT of 474 0.1 seconds. 476 Table 3 478 Our test results in [HKLRX06] indicate that CUBIC uses the spare 479 bandwidth left unused by existing Standard TCP flows in the same 480 bottleneck link without taking away much bandwidth from the existing 481 flows. 483 4.3. Difficult Environments 485 CUBIC is designed to remedy the poor performance of TCP in fast long- 486 distance networks. It is not designed for wireless networks. 488 4.4. Investigating a Range of Environments 490 CUBIC has been extensively studied by using both NS-2 simulation and 491 test-bed experiments covering a wide range of network environments. 492 More information can be found in [HKLRX06]. 494 4.5. Protection against Congestion Collapse 496 In case that there is congestion collapse, CUBIC behaves likely 497 standard TCP since CUBIC modifies only the window adjustment 498 algorithm of TCP. Thus, it does not modify the ACK clocking and 499 Timeout behaviors of Standard TCP. 501 4.6. Fairness within the Alternative Congestion Control Algorithm. 503 CUBIC ensures convergence of competing CUBIC flows with the same RTT 504 in the same bottleneck links to an equal bandwidth share. When 505 competing flows have different RTTs, their bandwidth shares are 506 linearly proportional to the inverse of their RTT ratios. This is 507 true independent of the level of statistical multiplexing in the 508 link. 510 4.7. Performance with Misbehaving Nodes and Outside Attackers 512 This is not considered in the current CUBIC. 514 4.8. Responses to Sudden or Transient Events 516 In case that there is a sudden congestion, a routing change, or a 517 mobility event, CUBIC behaves the same as Standard TCP. 519 4.9. Incremental Deployment 521 CUBIC requires only the change of TCP senders, and does not require 522 any assistant of routers. 524 5. Security Considerations 526 This proposal makes no changes to the underlying security of TCP. 528 6. IANA Considerations 530 There are no IANA considerations regarding this document. 532 7. Acknowledgements 534 Alexander Zimmermann and Lars Eggert have received funding from the 535 European Union's Horizon 2020 research and innovation program 536 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document 537 reflects only the authors' views and the European Commission is not 538 responsible for any use that may be made of the information it 539 contains. 541 8. References 543 8.1. Normative References 545 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 546 Selective Acknowledgment Options", RFC 2018, 547 DOI 10.17487/RFC2018, October 1996, 548 . 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 556 RFC 3649, DOI 10.17487/RFC3649, December 2003, 557 . 559 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 560 RFC 4960, DOI 10.17487/RFC4960, September 2007, 561 . 563 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 564 Control Algorithms", BCP 133, RFC 5033, 565 DOI 10.17487/RFC5033, August 2007, 566 . 568 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 569 Friendly Rate Control (TFRC): Protocol Specification", 570 RFC 5348, DOI 10.17487/RFC5348, September 2008, 571 . 573 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 574 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 575 . 577 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 578 NewReno Modification to TCP's Fast Recovery Algorithm", 579 RFC 6582, DOI 10.17487/RFC6582, April 2012, 580 . 582 8.2. Informative References 584 [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic 585 Ordering for Internet Congestion Control and its 586 Applications", In Proceedings of IEEE INFOCOM , May 2007. 588 [FHP00] Floyd, S., Handley, M., and J. Padhye, "A Comparison of 589 Equation-Based and AIMD Congestion Control", May 2000. 591 [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary 592 Adjustment Algorithms", Technical Report TR2002-29, 593 Department of Computer Sciences , The University of Texas 594 at Austin , August 2002. 596 [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step 597 toward Realistic Performance Evaluation of High-Speed TCP 598 Variants", International Workshop on Protocols for Fast 599 Long-Distance Networks , February 2006. 601 [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly 602 High-Speed TCP Variant", ACM SIGOPS Operating System 603 Review , 2008. 605 [K03] Kelly, T., "Scalable TCP: Improving Performance in 606 HighSpeed Wide Area Networks", ACM SIGCOMM Computer 607 Communication Review , April 2003. 609 [LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control 610 for High Bandwidth-Delay Product Paths", Internet-draft 611 draft-leith-tcp-htcp-06 , April 2008. 613 [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase 614 Congestion Control for Fast, Long Distance Networks", In 615 Proceedings of IEEE INFOCOM , March 2004. 617 Authors' Addresses 619 Injong Rhee 620 North Carolina State University 621 Department of Computer Science 622 Raleigh, NC 27695-7534 623 US 625 Email: rhee@ncsu.edu 627 Lisong Xu 628 University of Nebraska-Lincoln 629 Department of Computer Science and Engineering 630 Lincoln, NE 68588-01150 631 US 633 Email: xu@unl.edu 635 Sangtae Ha 636 University of Colorado at Boulder 637 Department of Computer Science 638 Boulder, CO 80309-0430 639 US 641 Email: sangtae.ha@colorado.edu 643 Alexander Zimmermann 644 NetApp 645 Sonnenallee 1 646 Kirchheim 85551 647 Germany 649 Phone: +49 89 900594712 650 Email: alexander.zimmermann@netapp.com 652 Lars Eggert 653 NetApp 654 Sonnenallee 1 655 Kirchheim 85551 656 Germany 658 Phone: +49 151 12055791 659 Email: lars@netapp.com 660 Richard Scheffenegger 661 NetApp 662 Am Euro Platz 2 663 Vienna 1120 664 Austria 666 Phone: +43 1 3676811 3146 667 Email: rs@netapp.com