idnits 2.17.1 draft-fairhurst-tcpm-newcwv-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 date (March 07, 2011) is 4800 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: 'RFC 2861' is mentioned on line 98, but not defined ** Obsolete undefined reference: RFC 2861 (Obsoleted by RFC 7661) == Missing Reference: 'RFC 3517' is mentioned on line 190, but not defined ** Obsolete undefined reference: RFC 3517 (Obsoleted by RFC 6675) == Unused Reference: 'RFC2861' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'RFC3517' is defined on line 351, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2861 (Obsoleted by RFC 7661) ** Obsolete normative reference: RFC 3517 (Obsoleted by RFC 6675) Summary: 4 errors (**), 0 flaws (~~), 5 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: September 8, 2011 March 07, 2011 7 Updating TCP to support Variable-Rate Traffic 8 draft-fairhurst-tcpm-newcwv-00 10 Abstract 12 This document addresses issues that arise when TCP is used to support 13 variable-rate traffic that includes periods where the transmission 14 rate is limited by the application. It evaluates TCP Congestion 15 Window Validation (TCP-CWV), an IETF experimental specification 16 defined in RFC 2581, and concludes that TCP-CWV sought to address 17 important issues, but failed to deliver a widely used solution. 19 The document recommends that the IETF should consider moving RFC 2861 20 from Experimental to Historic status, and replacing this with the 21 current specification, which updates TCP to allow a TCP sender to 22 restart quickly following either an idle or data-limited period. The 23 method is expected to benefit variable-rate TCP applications, while 24 also providing an appropriate response if congestion is experienced. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 8, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Reviewing experience with TCP-CWV . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. An updated TCP response to idle and application-limited 64 periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. A method for preserving cwnd in idle and 66 application-limited periods. . . . . . . . . . . . . . . . 5 67 4.2. The nonvalidated phase . . . . . . . . . . . . . . . . . . 5 68 4.3. TCP congestion control during the nonvalidated phase . . . 5 69 4.3.1. Adjustment at the end of the nonvalidated phase . . . . 6 70 4.3.2. Response to congestion in the nonvalidated phase . . . 7 71 4.4. Determining a safe period to preserve cwnd . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 TCP's congestion window (cwnd) controls the number of packets a TCP 83 flow may have in the network at any time. A bulk application that 84 always sends as fast as possible, will continue to grow the cwnd, and 85 increase its transmission rate until it reaches the maximum 86 permitted. In contrast, a variable-rate application may experience 87 long periods when the sender is either idle or application-limited. 89 Standard TCP requires the cwnd to be reset to the restart window (rw) 90 when an application becomes idle. RFC 2861 noted that this behaviour 91 was not always observed in current implementations. Recent 92 experiments [Bis08] confirm this to still be the case. Standard TCP 93 does not control growth of the cwnd when an application is data- 94 limited. A data-limited application may therefore grow a cwnd that 95 does not reflect any current information about the state of the 96 network. Use of an invalid cwnd may result in reduced application 97 performance or could significantly contribute to network congestion. 98 These issues were noted in [RFC 2861]. 100 TCP-CWV proposed a solution to help reduce the cases where TCP 101 experienced an invalid cwnd. The use of TCP-CWV is discussed in 102 Section 2. 104 Section 4 discusses an alternative to TCP-CWV that seeks to address 105 the same issues, but does so in a way that is expected to mitigate 106 the impact on an application that varies its transmission rate. The 107 proposal described applies to both a data limited and an idle 108 condition. . 110 2. Reviewing experience with TCP-CWV 112 RFC 2861 described a simple modification to the TCP congestion 113 control algorithms that decayed the cwnd after the transition from a 114 "sufficiently-long" application-limited period, while using the slow- 115 start threshold ssthresh to save information about the previous value 116 of the congestion window. This approach relaxed the standard TCP 117 behaviour [RFC5681] for an idle session, intended to improve 118 application performance. It did not modify the behaviour for an 119 application-limited session where a sender continues to transmit at a 120 rate less than allowed by cwnd. 122 RFC 2861 has been implemented in some mainstream operating systems as 123 the default behaviour [Bis08]. Experience from using applications 124 with TCP-CWV suggests that this mechanism does not offer the 125 desirable increase in application performance for "bursty" 126 applications and it is unclear that applications actually use the 127 mechanism. Analysis (e.g. [Bis10]) has shown that TCP-CWV is able 128 to use the available capacity after an idle period over a shared path 129 and that this can have benefit, especially over long delay paths, 130 when compared to slow-start restart specified by standard TCP, but 131 this behaviour can be too conservative to be attractive to many 132 common variable-rate applications. 134 TCP-CWV offer a benefit, compared to standard TCP, for an application 135 that exhibits regular idleness. However TCP-CWV would only benefit 136 the application if the idle period was greater than several RTOs, 137 since the behaviour would be the same as for standard TCP. Although 138 TCP-CWV benefits the network in an application-limited scenario, the 139 conservative approach of TCP-CWV does not provide an incentive to 140 application to use this. It is therefore suggested that TCP-CWV is 141 often a poor solution for many variable rate applications. In 142 summary, TCP-CWV has the correct motivation, but has the wrong 143 approach to solving this problem 145 3. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 The document also assumes familiarity with the terminology of TCP 152 congestion control [RFC5681]. 154 4. An updated TCP response to idle and application-limited periods 156 This section proposes an update to the TCP congestion control 157 behaviour during an idle or data limited period. The new method 158 allows a TCP sender to preserve the cwnd when an application becomes 159 idle for a period of time (set in this specification to 6 minutes). 160 This period where actual usage is less than allowed by cwnd is called 161 the nonvalidation phase. This allows an application to resume 162 transmission at a previous rate without incurring the delay of slow- 163 start. However, if the TCP sender experiences congestion using the 164 preserved cwnd, it is required to immediately reset the cwnd to an 165 appropriate value. If a sender does not take advantage of the 166 preserved cwnd within 6 minutes, the value of cwnd is updated, 167 ensuring the value then reflects the capacity was recently used. 169 The new method does not differentiate between times when the sender 170 has become idle or application-limited. It recognises that 171 applications can result in variable-rate transmission. This 172 therefore reduces the incentive for an application to send data, 173 simply to keep transport congestion state. The method requires SACK 174 to be enabled. This allows a sender to select a cwnd following a 175 congestion event that is based on the measured path capacity path, 176 better reflecting the fair-share. A similar approach was proposed by 177 TCP Jump Start [Liu07], as a congestion response after more rapid 178 opening of a connection. 180 It is expected that the proposed TCP modification will satisfy the 181 requirements of many variable rate applications and at the same time 182 provide an appropriate method for use in the Internet. This change 183 may also serve to encourage application 185 4.1. A method for preserving cwnd in idle and application-limited 186 periods. 188 The method described in this document updates RFC 5681. Use of the 189 method REQUIRES a TCP sender and the corresponding receiver to enable 190 the SACK option [RFC 3517]. 192 RFC 5681 define a variable FlightSize, that indicates the amount of 193 outstanding data in the network. In RFC 5681 this is used during 194 loss recovery, whereas in this method it is also used in normal data 195 transfer. A sender is not required to accurately record this value, 196 but must be able to measure the volume of data in the network at 197 least each RTT period. 199 4.2. The nonvalidated phase 201 The updated method creates a new TCP phase that captures where the 202 cwnd reflects a valid or nonvalidated value. The phases are defined 203 as: 205 o Valid phase: FlightSize >=(2/3)*cwnd - In this phase the sender is 206 in the normal phase, where cwnd is an approximate indication of 207 available capacity currently available along the network path. 209 o Nonvalidated phase: FlightSize <(2/3)*cwnd - In this phase the 210 sender is in the nonvalidated phase, where the cwnd was based on a 211 previous approximation of the available capacity, and the usage of 212 this capacity has not been validated in the previous RTT. That 213 is, the transmission rate is not being constrained by the cwnd. 215 4.3. TCP congestion control during the nonvalidated phase 217 A TCP sender that enters the non-validated phase preserves the cwnd 218 (i.e., this neither grows nor reduces). The phase is concluded after 219 a fixed period of time (6 minutes, as explained in section 4.4) or 220 when the sender transmits using the full cwnd (i.e. it is no longer 221 data-limited). 223 The behaviour in the non-validated phase is specified as: 225 o If the sender consumes all the available space within the cwnd 226 (i.e. the remaining cwnd is less than one SMSS), then the sender 227 MUST exit the nonvalidated phase. (The conditions for entering 228 and leaving this phase are intentionally different to introduce 229 hysteresis, although the change between phases is not impacted to 230 impact the application.) If the Retransmission Time Out (RTO) 231 expires during the nonvalidated phase, the sender MUST exit the 232 nonvalidated phase. It then uses the Standard TCP mechanism (in 233 this case the path history is considered unreliable). 235 4.3.1. Adjustment at the end of the nonvalidated phase 237 An application that remains in the nonvalidated phase for a period 238 greater than six minutes is required to adjust its congestion control 239 state. 241 During the non-validated phase, an application may produce bursts of 242 data at up to the cwnd in size. This is no different to normal TCP, 243 however it is desirable to control the maximum burst size, e.g. by 244 setting a burst size limit, using a pacing algorithm, or some other 245 method. 247 At the end of the nonvalidated phase, the sender MUST update cwnd: 249 cwnd = max(FlightSize*2, IW). 251 Where IW is the TCP initial window. 253 The sender also MUST reset the ssthresh: 255 ssthresh = max(ssthresh, 3*cwnd/4). 257 The adjustment of ssthresh ensures that the sender records that it 258 has safely sustained the present rate. This change is beneficial to 259 applications-limited flows that encounter occasional congestion, and 260 could otherwise suffer an unwanted additional delay in recovering the 261 transmission rate. 263 The sender MAY re-enter the nonvalidated phase if required (see 264 section 4.2). 266 4.3.2. Response to congestion in the nonvalidated phase 268 If the sender receives congestion feedback while in the nonvalidated 269 phase, i.e. it detects a packet-drop or receives an Explicit 270 Congestion Notification (ECN), this indicates that it was unsafe to 271 start with the preserved cwnd, and TCP is required to quickly reduce 272 the rate to avoid further congestion. 274 When loss is detected, the sender MUST calculate a safe cwnd: 276 cwnd = FlightSize- R. 278 Where, R is the volume of data reported as unacknowledged by the SACK 279 information. Following the method proposed for JumpStart {Liu07]. 281 At the end of the recovery phase, the TCP sender MUST reset the cwnd: 283 cwnd = (FlightSize/2). 285 4.4. Determining a safe period to preserve cwnd 287 Setting a limit to the period that cwnd is preserved avoids the 288 undesirable side effects that would result if cwnd were preserved for 289 an arbitrary long period, which was a part of the problem that TCP- 290 CWV originally attempted to address. The period a sender may safely 291 preserve the cwnd, is a function of the period that a network path is 292 expected to sustain capacity reflected by cwnd. There is no perfect 293 choice for this time. The period of 6 minutes was chosen as a 294 compromise that was larger than the idle intervals of common 295 applications, but not sufficiently larger than the period for which 296 an Internet path may commonly be regarded as stable. 298 The capacity of wired networks is usually relatively stable for 299 periods of several minutes and that load stability increases with the 300 capacity. This suggests that cwnd may be preserved for at least a 301 few minutes. 303 There are cases where the TCP throughput exhibits significant 304 variability over a time less than 6 minutes. Examples could include 305 many wireless topologies, where TCP rate variations may fluctuate on 306 the order of a few seconds as a consequence of medium access protocol 307 instabilities. Mobility changes may also impact TCP performance over 308 short time scales. Senders that observe such rapid changes in the 309 path characteristic may also experience increased congestion with the 310 new method, however such variation would likely also impact TCP's 311 behaviour when supporting interactive and bulk applications. 313 Routing algorithms may modify the network path, disrupting the RTT 314 measurement and changing the capacity available to a TCP connection, 315 however such changes do not often occur within a time frame of a few 316 minutes. 318 The value of 6 minutes is expected to be sufficient for most current 319 applications. Simulation studies also suggest that for most 320 practical applications, the performance using this value will not be 321 significantly different to that observed using a non-standard method 322 that does not reset cwnd after idle. 324 5. Security Considerations 326 General security considerations concerning TCP congestion control are 327 discussed in RFC 5681. This document describes a algorithm for one 328 aspect of those congestion control procedures, and so the 329 considerations described in RFC 5681 apply to this algorithm also. 331 6. IANA Considerations 333 None. 335 7. Acknowledgments 337 The authors acknowledge the contributions of Dr A Sathiaseelan and Dr 338 R Secchi in supporting the evaluation of TCP-CWV and for their help 339 in developing the protocol proposed in this draft. 341 8. References 343 8.1. Normative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion 349 Window Validation", RFC 2861, June 2000. 351 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 352 Conservative Selective Acknowledgment (SACK)-based Loss 353 Recovery Algorithm for TCP", RFC 3517, April 2003. 355 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 356 Control", RFC 5681, September 2009. 358 8.2. Informative References 360 [Bis08] Biswas and Fairhurst, "A Practical Evaluation of 361 Congestion Window Validation Behaviour, 9th Annual 362 Postgraduate Symposium in the Convergence of 363 Telecommunications, Networking and Broadcasting (PGNet), 364 Liverpool, UK, Jun. 2008.". 366 [Bis10] Biswas, Sathiaseelan, Secchi, and Fairhurst, "Analysing 367 TCP for Bursty Traffic, Int'l J. of Communications, 368 Network and System Sciences, 7(3), July 2010.". 370 [Liu07] Liu, Allman, Jiny, and Wang, "Congestion Control without a 371 Startup Phase, 5th International Workshop on Protocols for 372 Fast Long-Distance Networks (PFLDnet), Los Angeles, 373 California, USA, Feb. 2007.". 375 Authors' Addresses 377 Godred Fairhurst 378 University of Aberdeen 379 School of Engineering 380 Fraser Noble Building 381 Aberdeen, Scotland AB24 3UE 382 UK 384 Email: gorry@erg.abdn.ac.uk 385 URI: http://www.erg.abdn.ac.uk 387 Israfil Biswas 388 University of Aberdeen 389 School of Engineering 390 Fraser Noble Building 391 Aberdeen, Scotland AB24 3UE 392 UK 394 Email: israfil@erg.abdn.ac.uk 395 URI: http://www.erg.abdn.ac.uk