idnits 2.17.1 draft-fairhurst-tcpm-newcwv-02.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 (December 24, 2011) is 4478 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) == Missing Reference: 'RFC5861' is mentioned on line 225, but not defined == Missing Reference: 'RFC 5861' is mentioned on line 258, but not defined ** Obsolete normative reference: RFC 2861 (Obsoleted by RFC 7661) ** Obsolete normative reference: RFC 3517 (Obsoleted by RFC 6675) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM Working Group G. Fairhurst 3 Internet-Draft I. Biswas 4 Intended status: Standards Track University of Aberdeen 5 Expires: June 26, 2012 December 24, 2011 7 Updating TCP to support Variable-Rate Traffic 8 draft-fairhurst-tcpm-newcwv-02 10 Abstract 12 This document addresses issues that arise when TCP is used to support 13 variable-rate traffic that exhibts periods where the transmission 14 rate is limited by the application rather than the congestion window. 15 It updates TCP to allow a TCP sender to restart quickly following 16 either an idle or applications-limited interval. The method is 17 expected to benefit variable-rate TCP applications, while also 18 providing an appropriate response if congestion is experienced. 20 The document also evaluates TCP Congestion Window Validation (CWV), 21 an IETF experimental specification defined in RFC 2861, and concludes 22 that CWV sought to address important issues, but failed to deliver a 23 widely used solution. This document recommends that the IETF should 24 consider moving RFC 2861 from Experimental to Historic status, and 25 that this is replaced by the current specification. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 26, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. An updated TCP response to idle and application-limited 65 periods . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. A method for preserving cwnd in idle and 67 application-limited periods. . . . . . . . . . . . . . . . 5 68 4.2. The nonvalidated phase . . . . . . . . . . . . . . . . . . 5 69 4.3. TCP congestion control during the nonvalidated phase . . . 6 70 4.3.1. Adjustment at the end of the nonvalidated phase . . . 7 71 4.3.2. Response to congestion in the nonvalidated phase . . . 7 72 4.4. Determining a safe period to preserve cwnd . . . . . . . . 8 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 The TCP congestion window (cwnd) controls the number of packets/bytes 84 that a TCP flow may have in the network at any time. A bulk 85 application will always have data available to transmit. The rate it 86 sends is therefore limited by the maximum permitted by the receiver 87 and congestion windows. In contrast, a variable-rate application may 88 experience periods when the sender is either idle or is unable to 89 send at the maximum permitted rate. This latter case is called 90 application-limited. The focus of this document is on the operation 91 of TCP with such an idle or application-limited case. 93 Standard TCP [RFC5681] requires the cwnd to be reset to the restart 94 window (RW) when an application becomes idle. RFC 2861 noted that 95 this behaviour was not always observed in current implementations. 96 Recent experiments [Bis08] confirm this to still be the case. 97 However, standard TCP does not control growth of the cwnd when the 98 TCP sender is application-limited. An application-limited sender may 99 therefore grow a cwnd beyond that corresponding to the current 100 transmit rate, resulting in a value that does not reflect current 101 information about the state of the network path. Use of such an 102 invalid cwnd may result in reduced application performance and/or 103 could significantly contribute to network congestion. 105 These issues were noted in [RFC2861], which proposed a solution, 106 known as Congestion Window Validation (CWV). CWV was intended to 107 help reduce the cases where TCP accumulated an invalid cwnd. The use 108 and drawbacks of CWV are discussed in Section 2. 110 Section 4 specifies an alternative to CWV that seeks to address the 111 same issues, but does this in a way that is expected to mitigate the 112 impact on an application that varies its transmission rate. The 113 method described applies to both an application-limited and an idle 114 condition. 116 2. Reviewing experience with TCP-CWV 118 RFC 2861 described a simple modification to the TCP congestion 119 control algorithm that decayed the cwnd after the transition from a 120 "sufficiently-long" idle period. It used the slow-start threshold 121 (ssthresh) to save information about the previous value of the 122 congestion window. This approach relaxed the standard TCP behaviour 123 [RFC5681] for an idle session, intended to improve application 124 performance. CWV also modified the behaviour for an application- 125 limited session where a sender transmits at a rate less than allowed 126 by cwnd. 128 RFC 2861 has been implemented in some mainstream operating systems as 129 the default behaviour [Bis08]. Analysis (e.g. [Bis10]) has shown 130 that a TCP sender using CWV is able to use available capacity on a 131 shared path after an idle period. This can have benefit, especially 132 over long delay paths, when compared to slow-start restart specified 133 by standard TCP. CWV offers a benefit compared to standard TCP for 134 an application that has periods of idleness. However, CWV would only 135 benefit the application if the idle period were less than several 136 RTOs, since the behaviour would otherwise be the same as for standard 137 TCP, which resets the cwnd to the RW after this period. 139 Experience with CWV suggests that although CWV benefits the network 140 in an application-limited scenario (reducing the probability of 141 network congestion), the behaviour can be too conservative for many 142 common variable-rate applications. This mechanism does not therefore 143 offer the desirable increase in application performance for variable 144 rate applications and it is unclear whether applications actually use 145 this mechanism in the general Internet. 147 It is therefore concluded that CWV is often a poor solution for many 148 variable rate applications. In summary, CWV has the correct 149 motivation, but has the wrong approach to solving this problem. 151 3. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 The document assumes familiarity with the terminology of TCP 158 congestion control [RFC5681]. 160 4. An updated TCP response to idle and application-limited periods 162 This section proposes an update to the TCP congestion control 163 behaviour during an idle or application-limited period. The new 164 method permits a TCP sender to preserve the cwnd when an application 165 becomes idle for a period of time (set in this specification to 6 166 minutes). This period, where actual usage is less than allowed by 167 cwnd, is named the non-validated phase. The method allows an 168 application to resume transmission at a previous rate without 169 incurring the delay of slow-start. However, if the TCP sender 170 experiences congestion using the preserved cwnd, it is required to 171 immediately reset the cwnd to an appropriate value specified by the 172 method. If a sender does not take advantage of the preserved cwnd 173 within 6 minutes, the value of cwnd is reduced, ensuring the value 174 then reflects the capacity that was recently actually used. 176 The new method does not differentiate between times when the sender 177 has become idle or application-limited. This is partly a response to 178 recognition that some applications wish to transmit at a variable- 179 rate, and that it can be hard to make a distinction between 180 application-limited and idle behaviour. 182 The method requires that the TCP SACK option is enabled. This allows 183 the sender to select a cwnd following a congestion event that is 184 based on the measured path capacity path, better reflecting the fair- 185 share. A similar approach was proposed by TCP Jump Start [Liu07], as 186 a congestion response after more rapid opening of a TCP connection. 188 It is expected that the update will satisfy the requirements of many 189 variable-rate applications and at the same time provide an 190 appropriate method for use in the Internet. The method reduces the 191 incentive for an application to send data simply to keep transport 192 congestion state. (This is sometimes known as padding). It does not 193 differentiate between times when the sender has become idle or 194 application-limited. This is partly a response to recognition that 195 some applications wish to transmit at a variable-rate, and that it 196 can be hard to make a distinction between application-limited and 197 idle behaviour. This update is expected to encourage applications 198 and TCP stacks to use standards-based congestion control methods. It 199 may also encourage the use of long-lived connections where this 200 offers benefit (such as persistent http). 202 4.1. A method for preserving cwnd in idle and application-limited 203 periods. 205 The method described in this document updates RFC 5681. Use of the 206 method REQUIRES a TCP sender and the corresponding receiver to enable 207 the TCP SACK option [RFC3517]. 209 RFC 5681 defines a variable FlightSize, that indicates the amount of 210 outstanding data in the network. In RFC 5681 this is used during 211 loss recovery, whereas in this method it is also used during normal 212 data transfer. A sender is not required to continuously track this 213 value, but SHOULD measure the volume of data in the network with a 214 sampling period of not less than one RTT period. 216 4.2. The nonvalidated phase 218 The updated method creates a new TCP phase that captures whether the 219 cwnd reflects a validated or non-validated value. The phases are 220 defined as: 222 o Validated phase: FlightSize >=(2/3)*cwnd. This is the normal 223 phase, where cwnd is an approximate indication of available 224 capacity currently available along the network path, and standard 225 mechanisms are used [RFC5861]. 227 o Non-validated phase: FlightSize <(2/3)*cwnd. This is the phase 228 where the cwnd has a value based on a previous measurement of the 229 available capacity, and the usage of this capacity has not been 230 validated in the previous RTT. That is, the transmission rate was 231 not being constrained by the cwnd. The methods to be used in this 232 phase seek to determine whether any resumed rate remains safe for 233 the Internet path, i.e., it quickly reduces the rate if the flow 234 induces congestion. The mechanisms are specified in the following 235 sections. 237 4.3. TCP congestion control during the nonvalidated phase 239 A TCP sender that enters the non-validated phase MUST preserve the 240 cwnd (i.e., this neither grows nor reduces while the sender remains 241 in this phase). The phase is concluded after a fixed period of time 242 (6 minutes, as explained in section 4.4) or when the sender transmits 243 using the full cwnd (i.e. it is no longer application-limited). 245 The behaviour in the non-validated phase is specified as: 247 o If the sender consumes all the available space within the cwnd 248 (i.e., the remaining unused cwnd in bytes is less than one SMSS), 249 then the sender MUST exit the non-validated phase. 251 o If the sender receives an indication of congestion while in the 252 non-validated phase (i.e. detects loss, or an Explicit Congestion 253 Notification (ECN) mark), the sender MUST exit the non-validated 254 phase (reducing the cwnd). 256 o If the Retransmission Time Out (RTO) expires while in the non- 257 validated phase, the sender MUST exit the non-validated phase. It 258 then resumes using the Standard TCP RTO mechanism [RFC 5861]. 259 (The resulting reduction of cwnd is appropriate, since any 260 accumulated path history is considered unreliable). 262 The threshold value of cwnd required for the sender to enter the non- 263 validated phase is intentionally different to that required to leave 264 the phase. This introduces hysteresis to avoid rapid oscillation 265 between the phases. Note that the change between phases does not 266 significantly impact an application-limited sender. 268 4.3.1. Adjustment at the end of the nonvalidated phase 270 During the non-validated phase, an application may produce bursts of 271 data of up to the cwnd in size. This is no different to normal TCP, 272 however, as for TCP, it is desirable to control the maximum burst 273 size, e.g. by setting a burst size limit, using a pacing algorithm, 274 or some other method. 276 An application that remains in the non-validated phase for a period 277 greater than six minutes is required to adjust its congestion control 278 state. 280 At the end of the non-validated phase, the sender MUST update cwnd: 281 cwnd = max(FlightSize*2, IW). 283 Where IW is the TCP initial window [RFC5681]. 285 (The value for cwnd was chosen to allow an application to continue to 286 send at the currently utilised rate, and not incur delay should it 287 increase to twice the utilised rate.) 289 The sender also MUST reset the ssthresh: 290 ssthresh = max(ssthresh, 3*cwnd/4). 292 This adjustment of ssthresh ensures that the sender records that it 293 has safely sustained the present rate. The change is beneficial to 294 application-limited flows that encounter occasional congestion, and 295 could otherwise suffer an unwanted additional delay in recovering the 296 transmission rate. 298 The sender MAY re-enter the non-validated phase, if required (see 299 section 4.2). 301 4.3.2. Response to congestion in the nonvalidated phase 303 Reception of congestion feedback while in the non-validated phase, 304 i.e., a sender that detects a packet-drop or receives an Explicit 305 Congestion Notification (ECN), indicating it was inappropriate for 306 the sender to use the preserved cwnd. The sender is therefore 307 required to quickly reduce the rate to avoid further congestion. 308 Since the cwnd does not have a validated value, a new cwnd value must 309 be selected based on the utilised rate. 311 When congestion is detected, the sender MUST therefore calculate a 312 safe cwnd, based on the volume of acknowledged data: 313 cwnd = FlightSize - R. 315 Where, R is the volume of data that was reported as unacknowledged by 316 the SACK information. This follows the method proposed for Jump 317 Start [Liu07]. 319 At the end of the recovery phase, the TCP sender MUST reset the cwnd 320 using the method below: 321 cwnd = (FlightSize/2). 323 4.4. Determining a safe period to preserve cwnd 325 Setting a limit to the period that cwnd is preserved avoids 326 undesirable side effects that would result if the cwnd were to be 327 preserved for an arbitrary long period, which was a part of the 328 problem that CWV originally attempted to address. 330 The period a sender may safely preserve the cwnd, is a function of 331 the period that a network path is expected to sustain the capacity 332 reflected by cwnd. There is no perfect choice for this time. The 333 period of six minutes was chosen as a compromise that was larger than 334 the idle intervals of common applications, but not sufficiently 335 larger than the period for which the capacity of an Internet path may 336 commonly be regarded as stable. The capacity of wired networks is 337 usually relatively stable for periods of several minutes and that 338 load stability increases with the capacity. This suggests that cwnd 339 may be preserved for at least a few minutes. 341 There are cases where the TCP throughput exhibits significant 342 variability over a time less than six minutes. Examples could 343 include wireless topologies, where TCP rate variations may fluctuate 344 on the order of a few seconds as a consequence of medium access 345 protocol instabilities. Mobility changes may also impact TCP 346 performance over short time scales. Senders that observe such rapid 347 changes in the path characteristic may also experience increased 348 congestion with the new method, however such variation would likely 349 also impact TCP's behaviour when supporting interactive and bulk 350 applications. 352 Routing algorithms may modify the network path, disrupting the RTT 353 measurement and changing the capacity available to a TCP connection, 354 however such changes do not often occur within a time frame of a few 355 minutes. 357 The value of six minutes is therefore expected to be sufficient for 358 most current applications. Simulation studies also suggest that for 359 many practical applications, the performance using this value will 360 not be significantly different to that observed using a non-standard 361 method that does not reset the cwnd after idle. 363 5. Security Considerations 365 General security considerations concerning TCP congestion control are 366 discussed in RFC 5681. This document describes an algorithm that 367 updates one aspect of the congestion control procedures, and so the 368 considerations described in RFC 5681 apply to this algorithm also. 370 6. IANA Considerations 372 None. 374 7. Acknowledgments 376 The authors acknowledge the contributions of Dr A Sathiaseelan and Dr 377 R Secchi in supporting the evaluation of CWV and for their help in 378 developing the mechanisms proposed in this draft. 380 Israfil Biswas was partially supported by the School of Engineering, 381 University of Aberdeen, Scotland, UK. 383 8. References 385 8.1. Normative References 387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 388 Requirement Levels", BCP 14, RFC 2119, March 1997. 390 [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion 391 Window Validation", RFC 2861, June 2000. 393 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 394 Conservative Selective Acknowledgment (SACK)-based Loss 395 Recovery Algorithm for TCP", RFC 3517, April 2003. 397 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 398 Control", RFC 5681, September 2009. 400 8.2. Informative References 402 [Bis08] Biswas and Fairhurst, "A Practical Evaluation of 403 Congestion Window Validation Behaviour, 9th Annual 404 Postgraduate Symposium in the Convergence of 405 Telecommunications, Networking and Broadcasting (PGNet), 406 Liverpool, UK, Jun. 2008.". 408 [Bis10] Biswas, Sathiaseelan, Secchi, and Fairhurst, "Analysing 409 TCP for Bursty Traffic, Int'l J. of Communications, 410 Network and System Sciences, 7(3), July 2010.". 412 [Liu07] Liu, Allman, Jiny, and Wang, "Congestion Control without a 413 Startup Phase, 5th International Workshop on Protocols for 414 Fast Long-Distance Networks (PFLDnet), Los Angeles, 415 California, USA, Feb. 2007.". 417 Authors' Addresses 419 Godred Fairhurst 420 University of Aberdeen 421 School of Engineering 422 Fraser Noble Building 423 Aberdeen, Scotland AB24 3UE 424 UK 426 Email: gorry@erg.abdn.ac.uk 427 URI: http://www.erg.abdn.ac.uk 429 Israfil Biswas 430 University of Aberdeen 431 School of Engineering 432 Fraser Noble Building 433 Aberdeen, Scotland AB24 3UE 434 UK 436 Email: israfil@erg.abdn.ac.uk 437 URI: http://www.erg.abdn.ac.uk