idnits 2.17.00 (12 Aug 2021) /tmp/idnits28118/draft-you-iccrg-throughput-based-cwnd-increasing-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 20, 2015) is 2619 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3782 (Obsoleted by RFC 6582) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICC Research Group J. You 3 Internet-Draft Huawei 4 Intended status: Experimental March 20, 2015 5 Expires: September 21, 2015 7 Increasing TCP's CWND based on Throughput 8 draft-you-iccrg-throughput-based-cwnd-increasing-00 10 Abstract 12 With 4K technology, we can get more details compared to traditional 13 HD screens of the same size. However, 4K content increases the 14 demand for higher network throughput, which poses a big challenge for 15 delivering 4K content by TCP. This document proposes a target 16 throughput based method for increasing TCP's congestion window 17 (cwnd). Experimental results show that the proposed method can reach 18 the required throughput much more rapidly than traditional TCP 19 congestion algorithms, such as Reno, Cubic. Moreover, this method 20 prevents cwnd from increasing when cwnd reaching to the required 21 throughput. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 21, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Increasing CWND based on Throughput . . . . . . . . . . . . . 5 66 3.1. Window Growth Function . . . . . . . . . . . . . . . . . 6 67 3.2. Threshold . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4. Implementation Considerations . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Ultra HD (4K), or Ultra High Definition, is the next big step in HDTV 80 resolution. 4K introduced as a new projection standard for digital 81 cinema, bring digital cinema experience home with more details, more 82 colors, higher frame rate and smoother experience. 84 Basically, 4K content streaming requires throughput no less than 85 45Mbps. Table 1 shows the main parameters for different kinds of 4K 86 services when using traditional TCP [RFC793] congestion algorithms. 88 Table 1: Paramters for 4K Services 89 +----------+----------------+------------------+-------------+ 90 | | Burst of Speed | Packet Loss Rate |Packet Delay | 91 +----------+----------------+------------------+-------------+ 92 |Quasi 4K | > 30Mbps | < 5.6*10exp(-7) | RTT < 65ms | 93 +----------+----------------+------------------+-------------+ 94 |Basic 4K | > 60Mbps | < 5.6*10exp(-7) | RTT < 35ms | 95 +----------+----------------+------------------+-------------+ 96 |Ultra 4K | > 112Mbps | < 5.6*10exp(-7) | RTT < 22ms | 97 +----------+----------------+------------------+-------------+ 99 4K video can be encoded using different methods, such as CBR 100 (Constant Bit Rate), VBR (Variable Bit Rate). CBR encodes each frame 101 of video with the same bit rate, however, VBR adjusts the amount of 102 bits assigned to a frame depending on what the encoder believes is 103 happening in the frame. So the bit rate fluctuates over time when 104 using VBR. For example, one tested 4K video using VBR encoding, its 105 average bit rate is about 40Mbps and its maximum bit rate is about 106 60Mbps. 108 TCP uses slow start to increase the congestion window after a 109 connection is initialized. It may start with an initial window of 110 10MSS [RFC6928]. During the slow start phase, TCP increases the 111 congestion window very rapidly until packet loss occurs. TCP will 112 enter the congestion avoidance phase. 114 Given target throughput = 50Mbps, RTT = 60ms, then target window size 115 = 259MSS. During the slow start phase, the cwnd increases 116 exponentially per RTT, i.e. 10, 20, 40, 80, ... Assume a packet loss 117 occurs when cwnd = 130MSS. TCP Reno [RFC3782] cuts its congestion 118 window in half, i.e. 65MSS, and switches to the congestion avoidance 119 phase. In congestion avoidance phase, TCP's send rate increases 120 linearly, i.e. cwnd = cwnd+1. It takes 194 RTTs until the sender's 121 congestion window reaches to 259MSS, which needs about 11.64s. On 122 the whole, TCP Reno needs 198 RTTs, i.e. about 11.88s, to reach to 123 50Mbps from the beginning of a transfer. 125 Another example is TCP Cubic [CubicTCP]. Similarly assume a packet 126 loss occurs when cwnd = 130MSS, then the cwnd is reduced to 127 (717/1024)*130 = 91MSS. The congestion window of Cubic is determined 128 by the following function: 130 W(t) = C * (t-K)^3 + Wmax 132 where C is a scaling factor, t is the elapsed time from the last 133 window reduction, Wmax is the window size just before the last window 134 reduction, and 135 K = ((Wmax*beta)/C)^(1/3) 137 where beta is a constant multiplication decrease factor applied for 138 window reduction at the time of loss event, i.e., the window 139 reduction is beta*Wmax = (307/1024)*130 = 39MSS at the time of the 140 last reduction. Calculate K=9.9 with C = 0.04, then 141 0.04*(t-9.9)^3+130 = 259, so t = 25. TCP Cubic needs 29 RTTs, i.e. 142 about 1.74s, to reach to 50Mbps from the beginning of a transfer. 144 Throughput(Mbps) 145 ^ 146 | 147 | 148 | / 149 | | 150 cwnd=259 -50 / Cubic 151 | | 152 | / 153 | / 154 | / .../ 155 | / .../ 156 | _/ .../ Reno 157 | .--/ .../ 158 cwnd=130 -25 /| ./ .../ 159 | / |/ .../ 160 cwnd=91 -17.5 | | .../ 161 | / | .../ 162 cwnd=65 -12.5| |/ 163 | / 164 | / 165 |-/ 166 +-----------------------------------------------------------> 167 Time(s) 168 Figure 1: Cubic and Reno Window Curves 170 As shown in Figure 1, if packet loss occurs during the slow start 171 phase, TCP Reno takes much longer time to reach the required 172 throughput. TCP Cubic takes relatively shorter time compared to TCP 173 Reno, but cwnd continues to increase even though it has reached to 174 the target throughput. 176 This document proposes a target throughput based method for 177 increasing TCP's congestion window. Experimental results show that 178 the proposed method can reach the required throughput much more 179 rapidly than traditional TCP congestion algorithms, such as Reno, 180 Cubic. Moreover, this method prevents cwnd from increasing when cwnd 181 reaching to the required throughput. 183 2. Terminology 185 This section contains definitions of term frequently used throughout 186 this document. 188 4K: known as Ultra HD or UHD, is used to describe a new high 189 resolution video format with a minimum resolution of 3840 x 2160 190 pixels in a 16 x 9 aspect ratio for any display. 192 TCP: Transmission Control Protocol 194 RTT: Round-Trip Time 196 CBR: Constant Bit Rate 198 VBR: Variable Bit Rate 200 3. Increasing CWND based on Throughput 202 This document proposes a target throughput based method for 203 increasing TCP's congestion window. The main steps are shown in 204 Figure 2. 206 +---------+ +---------+ 207 | | | | 208 | APPs | | APPs |(1) 209 | | | | 210 +----+----+ +----+----+ 211 | | 212 | | 213 | |(2) 214 | | 215 | | 216 +----V----+ +----V----+ 217 | | | (3) | 218 |TCP Stack<--------------->TCP Stack| 219 | | | | 220 +---------+ +---------+ 221 Client Server 223 Figure 2: Increasing cwnd based on Throughput 225 Step 1: APP calculates the target throughput; take 4K VBR as an 226 example, 228 TARGET_THROUGHPUT = e * BR 230 where e>1, is a multiplication factor. 232 Step 2: Extend TCP socket option: setsockopt(); add a new parameter: 233 TARGET_THROUGHPUT, which will be transferred to TCP protocol stack. 235 Step 3: Calculate the increase factor alpha: 237 alpha = TARGET_THROUGHPUT * RTT - cwnd; 239 The increase factor for cwnd is calculated according to RTT and 240 TARGET_THROUGHPUT. TARGET_THROUGHPUT is input by APP, while RTT is 241 estimated based on current technology, which reflects the congestion 242 state of the network. Hence, 244 cwnd = cwnd + alpha 246 The cwnd can be adjusted for every RTT, as shown in Figure 3. 248 +----------+ 249 |Input | 250 |Target | 251 |Throughput| 252 +----+-----+ 253 | 254 | 255 | 256 | 257 --- | 258 / \ +----V-----+ +----------+ 259 / \ |Calculate | |Network | 260 + Every +-------->increase <----------+State | 261 \ RTT / |factor | |(RTT) | 262 \ / +-----+----+ +----------+ 263 --- | 264 ^ | 265 | | 266 +----+-----+ | 267 |Congestion| | 268 |Avoidance <-------------+ 269 | | 270 +----------+ 272 Figure 3: Procedures for Increasing cwnd 274 3.1. Window Growth Function 276 Alpha is an increase factor which is determined by the following 277 function: 279 alpha = TARGET_THROUGHPUT * RTT - cwnd 281 However, protection mechanism needs to be considered for alpha, for 282 example, when RTT is longer, the fast growth of cwnd may deteriorate 283 the delay or congestion. So a threshold T is defined to balance the 284 congestion state of the network. When BaseRTT =< RTT <= T; the 285 proposed alpha function will be applied, otherwise, current window 286 growth function (such as Reno, Cubic) will be applied, as shown in 287 Figure 4. 289 In Figure 4, BaseRTT is estimated as the minimum observed RTT for the 290 connection. Assume the TARGET_THROUGHPUT provide by the APP is no 291 larger than the actual network capacity, then 293 TARGET_cwnd = TARGET_THROUGHPUT * BaseRTT 295 When cwnd reaches to TARGET_cwnd, Alpha is zero with RTT = BaseRTT. 297 Alpha ^ . . . 298 | . . . 299 | . . . 300 | . . . 301 | . . . 302 | . alpha=TARGET_THROUGHPUT*RTT-cwnd 303 | . / . . 304 | . / . . 305 | . / . . 306 | . / . . 307 | . / alpha=TARGET_THROUGHPUT*RTT-TARGET_cwnd 308 | . / / . . 309 | . / / . . 310 | . / / . . 311 | . / / . . 312 | ./ / . . 313 | . / . . 314 | . / . . 315 | . / .e.g. Reno . 316 1 - . / ------------ 317 +-------------------------------------------> 318 BaseRTT T RTO RTT 320 Figure 4: Alpha during Congestion Avoidance 322 When T < RTT <= RTO, alpha will is determined by current congestion 323 algorithm, such as TCP Reno. RTO is the TCP retransmission timeout 324 time. Suppose we still use the above-mentioned alpha formula, i.e. 325 alpha = TARGET_THROUGHPUT * RTT - cwnd, then alpha will be larger. 326 However, at that time, the state of network is not good as RTT is 327 long. If still keeping large increase pace, it may deteriorate 328 congestion. So when RTT is during this range, alpha should be in 329 inverse proportion to RTT. For example, when RTT = RTO, the network 330 is very congested; alpha could be 1 MSS. 332 3.2. Threshold 334 Threshold T is defined to balance the congestion state of the 335 network. It has two main purposes: 337 o prevent alpha from fast increasing in case TARGET_THROUGHPUT is 338 larger than the actual network capacity. APP may overestimate the 339 network capacity, and provide the incorrect TARGET_THROUGHPUT. 341 o adjust T flexibly so as to adapt to different network. 343 When T = RTO, it shows the network capacity is enough to meet the 344 TARGET_THROUGHPUT. When T = BaseRTT, the proposed method doesn't 345 work. 347 4. Implementation Considerations 349 Given target throughput = 50Mbps, RTT = 60ms, then target window size 350 = 259MSS. Assume initial cwnd = 10MSS, during the slow start phase, 352 alpha = TARGET_THROUGHPUT * RTT - cwnd 353 = 50Mbps*60ms -10 MSS 354 = 249MSS 356 Only one RTT is needed to reach to the target throughput. After, 357 alpha will be zero if RTT is not changed. If packet loss occurs, TCP 358 will cut its congestion window in half like Reno, i.e. to 130 MSS, 359 and switches to the congestion avoidance phase. In congestion 360 avoidance phase, the cwnd increases still according to: 362 alpha = TARGET_THROUGHPUT * RTT - cwnd 363 = 50Mbps*60ms -130MSS 364 = 129MSS 366 Still one RTT is needed to come back to the target throughput. 368 CWND/MSS^ . . . 369 | . . . 370 | . . . 371 | . . . 372 | . . . 373 | . . . 374 259- ----------------+ . /-------- 375 | /. . | / 376 | / . . | / . 377 | / . . | / . 378 | / . . | / . 379 | / . . | / . 380 | / . . | / . 381 130- / . . / . 382 | / . . . 383 | / . . . 384 | / . . . 385 | / . . . 386 |/ . . . 387 10- . . . 388 +------------------------------------------------------> 389 1 2 3 RTT/Number 391 Figure 5: Window Curve with Packet Loss using Proposed Method 393 During the slow start phase, the growth of cwnd is not effected by 394 packet loss if the ACK for first packet is received. In the first 395 RTT, cwnd has already increased to the target cwnd when the sender 396 receives the ACK for the first packet. If packet loss occurs in the 397 third RTT, cwnd is reduced to half. Then in the following RTT, the 398 cwnd rapidly increases to the target cwnd. 400 In order to support the alpha function in the sender, the receiver 401 needs to set the receiving window according to the TARGET_THROUGHPUT 402 too; otherwise the sender's cwnd may be limited by the receiving 403 window. 405 5. IANA Considerations 407 This document has no actions for IANA. 409 6. Security considerations 411 This document introduces a new method to configure the congestion 412 window for TCP connections. This method facilitates application 413 developers to tune TCP for their benefits. But it also has the 414 possibility that packet loss may be caused by inappropriate cwnd 415 setting if application overestimates the network capacity. 417 7. Acknowledgement 419 TBD. 421 8. References 423 8.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno 429 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 430 April 2004. 432 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 433 "Increasing TCP's Initial Window", RFC 6928, April 2013. 435 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, 436 September 1981. 438 8.2. Informative References 440 [CubicTCP] 441 Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP Friendly 442 HighSpeed TCP Variant", 2008. 444 Author's Address 446 Jianjie You 447 Huawei 448 101 Software Avenue, Yuhua District 449 Nanjing 210012 450 China 452 Email: youjianjie@huawei.com