idnits 2.17.1 draft-allman-rto-backoff-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 357. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2119], [RFC2988]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2006) is 6313 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: 'RFC1323' is mentioned on line 95, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) ** Downref: Normative reference to an Experimental RFC: RFC 3522 ** Downref: Normative reference to an Experimental RFC: RFC 3708 ** Downref: Normative reference to an Experimental RFC: RFC 4138 -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. 'Flo98') (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 3517 (Obsoleted by RFC 6675) -- Obsolete informational reference (is this intentional?): RFC 3782 (Obsoleted by RFC 6582) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Josh Blanton 2 INTERNET DRAFT Ohio University 3 draft-allman-rto-backoff-04.txt Ethan Blanton 4 Expires: June 2007 Purdue University 5 Mark Allman 6 ICIR/ICSI 7 December 2006 9 Using Spurious Retransmissions to Adapt the Retransmission Timeout 10 draft-allman-rto-backoff-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document describes a method for using spurious retransmission 42 timeouts as the trigger for slightly changing the way TCP's 43 retransmission timeout is computed in an effort to avoid subsequent 44 unnecessary retransmissions. 46 Terminology 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 49 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 50 "OPTIONAL" in this document are to be interpreted as described 51 in [RFC2119]. 53 The reader is expected to be familiar with the algorithm and 54 terminology from [RFC2988]. 56 1. Introduction 58 Various studies have shown that the retransmission timeout (RTO) 59 estimator in [RFC2988] can trigger spurious retransmissions. [AP99] 60 shows that such unnecessary retransmissions are generally fairly 61 rare. However, [LK00] shows that in some networks (e.g., wireless 62 networks) spurious retransmissions are more problematic due to 63 occasional delay spikes that are not well predicted by TCP's RTO 64 estimator. In this document we outline one possible approach to 65 mitigate the impact of pre-mature RTO firings by altering the RTO 66 estimator specified in [RFC2988]. 68 Several methods for detecting spurious timeouts have been developed 69 [RFC3522,RFC3708,RFC4138]. Additionally, [RFC4015] outlines one 70 possible response to detecting spurious timeouts. This document 71 outlines an alternative to [RFC4015]. In general terms, [RFC4015] 72 specifies two actions upon the detection of an unnecessary RTO-based 73 retransmission. First, the sending rate prior to the spurious 74 retransmission is restored. Furthermore, the RTO is adapted by 75 re-initializing the RTO estimator with the long round-trip time 76 (RTT) measurement that caused the spurious RTO. The approach given 77 in [RFC4015] is reasonable if the underlying cause of the problem is 78 a shift in the path RTT. For instance, if the route a TCP 79 connection is traversing changes and the new path's RTT is 80 significantly longer than the previous path's RTT then simply 81 re-initializing the RTO is a reasonable action. 83 As specified in the next section this document takes a slightly 84 different approach than [RFC4015]. Generally, this document uses 85 the failure of the RTO to wait long enough before triggering a 86 retransmit as an indication that the RTO estimator itself is not 87 properly capturing the variance present in the RTTs experienced by 88 the TCP connection. Therefore, this document calls for an increase 89 in the contribution of the variance component in the RTO estimator 90 upon the detection of retransmission timeouts in an effort to cope. 91 This change represents a preference to try to avoid future spurious 92 timeouts rather than simply reacting to each spurious 93 retransmission. 95 We note that TCP implementations using the RTTM mechanism [RFC1323] 96 to assess the RTT multiple times per RTT with the standard 97 exponentially-weighted moving average (EWMA) gains from [RFC2988] 98 retain less RTT history than when taking one RTT measurement per RTT. 99 [AP99] shows that "fast" EWMAs yield more spurious retransmissions 100 than when using the standard gains with one RTT sample per RTT. 101 Therefore, an orthogonal change to TCP implementations that use RTTM 102 that may prevent spurious RTOs is to set the EWMA gains based on the 103 number of RTT samples taken per RTT such that the amount of history 104 kept, in terms of time, is the same regardless of the number RTT 105 samples taken [Flo98,LS00]. 107 2. Parameter Changes 108 As the basis for the changes proposed below, a TCP MUST support an 109 IETF-specified spurious timeout detection method. Currently, 110 [RFC3522], [RFC3708] and [RFC4138] are such detection methods. We 111 note that the research literature includes alternate methods for 112 detecting spurious retransmissions, e.g., the "retransmit bit" 113 [LK00], but these schemes MUST NOT be used as part of the changes 114 specified in this document until such time that the IETF approves a 115 specification of these schemes. 117 We also note that [RFC2988] explicitly allows for an RTO estimator 118 that is more conservative than that given in [RFC2988] (which this 119 document specifies). 121 Also we note that, given that the TCP is savvy enough to untangle 122 needed and uneeded retransmission timeouts, the TCP does not need to 123 use Karn's algorithm [KP87,RFC2988] and can accurately determine the 124 RTT that causes spurious retransmissions. 126 This document specifies that a TCP MAY change the RTO estimator 127 given in [RFC2988] upon detection of a spurious timeout, as follows. 129 The general idea behind the mechanism is to increase "K", the 130 multiplier applied to RTTVAR in the RTO calculation given in step 131 (2.3) of [RFC2988] to allow for additional variance in the path's 132 RTT. The specific mechanism for TCPs using this change is: 134 (A) Upon the first expiration of the retransmission timer for a 135 given sequence number, the values of SRTT and RTTVAR MUST be 136 saved as SRTT_prev and RTTVAR_prev, respectively. 138 (B) Upon detecting that a previous RTO-based retransmission was 139 spurious, a TCP MUST calculate a K' using the RTT sample 140 R', which is the time between when the original transmission of 141 the given segment was sent and when the that original 142 transmission is acknowledged, as follows: 144 K' = ceil ((R' - SRTT_prev) / RTTVAR_prev) (1) 146 K' then becomes the multiplier that would have prevented the 147 unneeded RTO-based retransmit. 149 In the event that RTTVAR is zero, K' MUST remain at its previous 150 value (or be set to 4, in the event that K' had not been 151 previously calculated). 153 The value of K' MUST NOT be reduced for the remainder of the 154 connection (as discussed in more detail below). 156 (C) The values of SRTT and RTTVAR in use when the spurious 157 retransmit occured MUST replace the current values: 159 SRTT = SRTT_prev (2) 160 RTTVAR = RTTVAR_prev (3) 162 (D) The R' RTT sample MUST be used to adjust SRTT and RTTVAR and 163 therefore the RTO, per [RFC2988]. 165 The actual K that is used in the RTO calculation is determined by 166 the size of the congestion window. When a TCP has only a small 167 number of outstanding segments, advanced loss recovery that relies 168 on the receipt of three duplicate acknowledgments as a recovery 169 trigger is not as effective as when the congestion window is larger. 170 Therefore, TCP relies more heavily on the RTO in this regime. 171 Furthermore, the impact caused by spurious timeouts in this 172 situation---in terms of congestion window reduction and resource 173 wastage by go-back-N transmission---is small. Hence, when the 174 congestion window is less than or equal to 4*SMSS bytes then the 175 standard K of 4 SHOULD be used when calculating the RTO via step 176 (2.3) from [RFC2988]. Once the congestion window size grows beyond 177 4*SMSS bytes, the value of K' SHOULD be used in the calculation of 178 the RTO. 180 This specification explicitly offers no way to reduce K' after it 181 has been inflated. K' is never reduced because the presence of 182 spurious timeouts which inflated K' indicates that the standard 183 estimator is inadequate for accurately estimating the variance of 184 the RTT across the network path and therefore reducing K' would 185 increase the chances of further spurious retransmissions. 187 Finally, we note that bounding K' is not advisable. Say K' would be 188 set to 20 via equation (1). If K' were, instead, bound to 10 then 189 legitimate RTOs would be forced to wait longer without offering 190 solid protection against delay spikes (given that delay spikes that 191 a K' of 10 will not handle have been observed). 193 3. Advantages 195 The advantage of tuning the RTO calculation to be more conservative 196 after detecting spurious RTO-based retransmissions is in preventing 197 further spurious RTOs. In addition, spurious RTOs can cause 198 go-back-N behavior [LK00] which can also be avoided by adapting the 199 RTO to be more conservative. 201 4. Disadvantages 203 The disadvantage of tuning the RTO calculation to be more 204 conservative is that legitimate RTO firings takes longer and could 205 hurt performance. However, an important note is that the RTO should 206 not be TCP's primary loss recovery strategy. [RFC3782] and 207 [RFC3517] provide methods for TCP to effectively repair multiple 208 lost segments from a single window of data without falling back to 209 using the RTO. Further, research shows that these changes are 210 widely implemented [MAF05]. Therefore, making TCP's RTO calculation 211 more conservative should not hinder performance under normal 212 circumstance. Put differently, when using advanced loss recovery 213 techniques the firing of the RTO should be an indication that the 214 congestion situation in the network is fairly bad. In this case, it 215 may well be that making the RTO estimator more conservative is the 216 right general approach. 218 The common exception to the above argument is when the congestion 219 window is small, such that these advanced loss recovery algorithms 220 do not work effectively. The mechanism in this document explicitly 221 takes this case into account by not using the more conservative RTO 222 estimate when the congestion window is small. 224 5. Summary 226 This document specifies a small change that makes the RTO 227 calculation given in [RFC2988] more conservative upon the detection 228 of spurious RTO-based retransmissions. The root cause of spurious 229 retransmits is an inaccurate assessment of the network conditions 230 (in this case, of the RTT). Therefore, we tackle this by making the 231 RTO calculation take into account RTT variance to a larger degree. 232 While this does lengthen the time required for legitimate 233 retransmissions to fire, the RTO should not be TCP's primary means 234 for retransmitting data and therefore this lengthened interval 235 should only minimally impact overall performance and should only 236 come into play when conditions along the network path have 237 deteriorated significantly. Finally, we note that this document 238 makes the estimator given in [RFC2988] strictly more conservative 239 and is therefore allowed via [RFC2988]. 241 6. Security Considerations 243 This document calls for a simple parameter tweak and does not change 244 the security considerations given in [RFC2988]. 246 7. IANA Considerations 248 None. 250 Acknowledgments 252 This document has benefited from discussions with Ted Faber, Aaron 253 Falk, Joseph Ishac, Janardhan Iyengar, Sally Floyd, Vern Paxson and 254 Joe Touch. 256 Normative References 258 [RFC2119] S. Bradner. Key words for use in RFCs to Indicate 259 Requirement Levels, March 1997. BCP 14, RFC 2119. 261 [RFC2988] V. Paxson, M. Allman. Computing TCP's Retransmission 262 Timer, November 2000. RFC 2988. 264 [RFC3522] R. Ludwig, M. Meyer. The Eifel Detection Algorithm for 265 TCP, April 2003. RFC 3522. 267 [RFC3708] E. Blanton, M. Allman. Using TCP Duplicate Selective 268 Acknowledgement (DSACKs) and Stream Control Transmission 269 Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) 270 to Detect Spurious Retransmissions, February 2004. RFC 3708. 272 [RFC4138] P. Sarolahti, M. Kojo. Forward RTO-Recovery (F-RTO): An 273 Algorithm for Detecting Spurious Retransmission Timeouts with 274 TCP and the Stream Control Transmission Protocol (SCTP), August 275 2005. RFC 4138. 277 Informative References 279 [AP99] Mark Allman, Vern Paxson. On Estimating End-to-End Network 280 Path Properties. ACM SIGCOMM, September 1999. 282 [Flo98] Sally Floyd. Comments on RFC1323.bis, TCP-LW mailing list, 283 May 1998. 285 [KP87] Phil Karn, Craig Partridge. Improving Round-Trip Time 286 Estimates in Reliable Transport Protocols. ACM SIGCOMM, August 287 1997. 289 [LK00] R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP 290 Robust Against Spurious Retransmissions. ACM Computer 291 Communication Review, 30(1), January 2000. 293 [LS00] R. Ludwig, K. Sklower, The Eifel Retransmission Timer, ACM 294 Computer Communication Review, Vol. 30, No. 3, July 2000. 296 [MAF05] A. Medina, M. Allman, S. Floyd. Measuring the Evolution of 297 Transport Protocols in the Internet. ACM Computer Communication 298 Review, 35(2), April 2005. 300 [RFC3517] E. Blanton, M. Allman, K. Fall, L. Wang. A Conservative 301 Selective Acknowledgment (SACK)-based Loss Recovery Algorithm 302 for TCP, April 2003. RFC 3517. 304 [RFC3782] S. Floyd, T. Henderson, A. Gurtov. The NewReno 305 Modification to TCP's Fast Recovery Algorithm, April 2004. RFC 306 3782. 308 [RFC4015] R. Ludwig, A. Gurtov. The Eifel Response Algorithm for 309 TCP, February 2005. RFC 4015. 311 Author's Addresses 313 Josh Blanton 314 Ohio University Internetworking Research Group 315 301 Stocker Center 316 Athens, OH 45701 317 Email: jblanton@cs.ohiou.edu 318 URL: http://irg.cs.ohiou.edu/~jblanton/ 320 Ethan Blanton 321 Purdue University Computer Sciences 322 250 North University Street 323 West Lafayette, IN 47907 324 Email: eblanton@cs.purdue.edu 325 URL: http://www.cs.purdue.edu/homes/eblanton/ 327 Mark Allman 328 ICSI Center for Internet Research 329 1947 Center Street, Suite 600 330 Berkeley, CA 94704-1198 331 Phone: (440) 235-1792 332 Email: mallman@icir.org 333 URL: http://www.icir.org/mallman/ 335 Intellectual Property Statement 337 The IETF takes no position regarding the validity or scope of any 338 Intellectual Property Rights or other rights that might be claimed 339 to pertain to the implementation or use of the technology described 340 in this document or the extent to which any license under such 341 rights might or might not be available; nor does it represent that 342 it has made any independent effort to identify any such rights. 343 Information on the procedures with respect to rights in RFC 344 documents can be found in BCP 78 and BCP 79. 346 Copies of IPR disclosures made to the IETF Secretariat and any 347 assurances of licenses to be made available, or the result of an 348 attempt made to obtain a general license or permission for the use 349 of such proprietary rights by implementers or users of this 350 specification can be obtained from the IETF on-line IPR repository 351 at http://www.ietf.org/ipr. 353 The IETF invites any interested party to bring to its attention any 354 copyrights, patents or patent applications, or other proprietary 355 rights that may cover technology that may be required to implement 356 this standard. Please address the information to the IETF at 357 ietf-ipr@ietf.org. 359 Disclaimer of Validity 361 This document and the information contained herein are provided on 362 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 363 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 364 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 365 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 366 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 367 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Copyright Statement 371 Copyright (C) The Internet Society (2006). This document is subject 372 to the rights, licenses and restrictions contained in BCP 78, and 373 except as set forth therein, the authors retain all their rights. 375 Acknowledgment 377 Funding for the RFC Editor function is currently provided by the 378 Internet Society.