idnits 2.17.1 draft-ietf-tcpm-rto-consider-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- == The document has an IETF Trust Provisions of 28 Dec 2009, Section 6.c(i) Publication Limitation clause. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 2, 2016) is 2977 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5681' is mentioned on line 221, but not defined -- Obsolete informational reference (is this intentional?): RFC 3940 (Obsoleted by RFC 5740) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force M. Allman 2 INTERNET-DRAFT ICSI 3 File: draft-ietf-tcpm-rto-consider-00.txt February 2, 2016 4 Intended Status: Best Current Practice 5 Expires: August 2, 2016 7 Retransmission Timeout Considerations 9 Status of this Memo 11 This document may not be modified, and derivative works of it may 12 not be created, except to format it for publication as an RFC or to 13 translate it into languages other than English. 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on May 2, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 46 Section 4.e of the Trust Legal Provisions and are provided without 47 warranty as described in the Simplified BSD License. 49 Abstract 51 Each implementation of a retransmission timeout mechanism must 52 balance correctness and timeliness and therefore no implementation 53 suits all situations. This document provides high-level guidance 54 for retransmission timeout schemes appropriate for general use in 55 the Internet. Within the guidelines, implementations have latitude 56 to define particulars that best address each situation. 58 Terminology 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in BCP 14, RFC 2119 63 [RFC2119]. 65 1 Introduction 67 Despite our best intentions and most robust mechanisms, reliability 68 in networking ultimately requires a timeout and re-try mechanism. 69 Often there are more timely and precise mechanisms than a timeout 70 for repairing loss (e.g., TCP's fast retransmit [RFC5681], NewReno 71 [RFC6582] or selective acknowledgment scheme [RFC2018,RFC6675]) 72 which require information exchange between components in the system. 73 Such communication cannot be guaranteed. Alternatively, information 74 coding---e.g., FEC---can allow the recipient to recover from some 75 amount of lost information without use of a retransmission. This 76 latter provides probabilistic reliability. Finally, negative 77 acknowledgment schemes exist that do not depend on continuous 78 feedback to trigger retransmissions (e.g., [RFC3940]). However, 79 regardless of these useful alternatives, the only thing we can truly 80 depend on is the passage of time and therefore our ultimate backstop 81 to ensuring reliability is a timeout. (Note: There is a case when 82 we cannot count on the passage of time, but in this case we believe 83 repairing loss will be a moot point and hence we do not further 84 consider this case in this document.) 86 Various protocols have defined their own timeout mechanisms (e.g., 87 TCP [RFC6298], SCTP [RFC4960]). Ideally, if we know a segment will 88 be lost before reaching the destination, a second copy of it would 89 be sent immediately after the first transmission. However, in 90 reality the specifics of retransmission 91 timeouts often represent a particular tradeoff between correctness 92 and responsiveness [AP99]. In other words we want to 93 simultaneously: 95 - Wait long enough to ensure the decision to retransmit is 96 correct. 98 - Bound the delay we impose on applications before 99 retransmitting. 101 However, serving both of these goals is difficult as they pull us in 102 opposite directions. I.e., towards either (a) withholding needed 103 retransmissions too long or (b) not waiting long enough and sending 104 spurious retransmissions. Given this fundamental tradeoff [AP99], 105 we have found that even though the retransmission timeout (RTO) 106 procedures are standardized, implementations also often add their 107 own subtle imprint on the specifics of the process to tilt the 108 tradeoff between correctness and responsiveness in some particular 109 way. 111 At this point we recognize that often these specific tweaks are not 112 crucial for network safety. Hence, in this document we outline the 113 high-level principles that are crucial for any retransmission 114 timeout scheme to follow. The intent is to then allow 115 implementations of protocols and applications to instantiate 116 mechanisms that best realize their specific goals within this 117 framework. These specific mechanisms could be standardized or 118 ad-hoc, but as long as they adhere to the guidelines given in this 119 document they would be considered consistent with the standards. 121 A non-goal of this document is to in any way specify individual 122 deviations from standard RTO specifications that any particular 123 implementation may exhibit. Rather, we provide a set of 124 over-arching guidelines that all RTO mechanisms should follow. 126 Finally, we note the guidelines in this document are applicable to 127 any protocol that uses an RTO mechanism. The examples and 128 discussion are framed in terms of TCP, however, that is an artifact 129 of where much of our experience with RTOs comes from and should not 130 be read as narrowing the scope of the guidelines. 132 2 Guidelines 134 We now list the four guidelines that apply when utilizing a 135 retransmission timeout (RTO). 137 (1) In the absence of any knowledge about the latency of a path, the 138 RTO MUST be conservatively set to no less than 1 second, per 139 TCP's current default RTO [RFC6298]. 141 This guideline ensures two important aspects of the RTO. First, 142 when transmitting into an unknown network, retransmissions will 143 not be sent before an ACK would reasonably be expected to arrive 144 and hence possibly waste scarce network resources. Second, as 145 noted below, sometimes retransmissions can lead to ambiguities 146 in assessing the latency of a network path. Therefore, it is 147 especially important for the first latency sample to be free of 148 ambiguities such that there is a baseline for the remainder of 149 the communication. 151 (2) We specify three guidelines that pertain to the sampling of the 152 latency across a path. 154 Often measuring the latency is framed as assessing the 155 round-trip time (RTT)---e.g., in TCP's RTO computation 156 specification [RFC6298]. This is somewhat mis-leading as the 157 latency is better framed as the "feedback time" (FT). In other 158 words, it is not simply a network property, but the length of 159 time before we expect an acknowledgment for a given segment. 160 For instance, this includes any time an ACK is delayed by the 161 recipient [RFC5681]. 163 (a) In steady state the RTO MUST be set based on recent 164 observations of both the FT and the variance of the FT. 166 In other words, the RTO should be based on a reasonable 167 amount of time that the sender should wait for an 168 acknowledgment of the data before retransmitting the given 169 data. 171 (b) FT observations MUST be taken regularly. 173 The exact definition of "regularly" is deliberately left 174 vague. TCP takes a FT sample roughly once per RTT, or if 175 using the timestamp option [RFC7323] on each acknowledgment 176 arrival. [AP99] shows that both these approaches result in 177 roughly equivalent performance for the RTO estimator. 178 Additionally, [AP99] shows that taking only a single FT 179 sample per TCP connection is suboptimal. Therefore, for the 180 purpose of this guideline we state that FT samples SHOULD be 181 taken at least once per RTT or as frequently as data is 182 exchanged and ACKed if that happens less frequently than 183 every RTT. However, we also recognize that it may not 184 always be practical to take a FT sample this often in all 185 cases and hence this requirement is explicitly a "SHOULD" 186 and not a "MUST". 188 (c) FT samples used in the computation of the RTO MUST NOT be 189 ambiguous. 191 Assume two copies of some segment X are transmitted at times 192 t0 and t1 and then segment X is acknowledged at time t2. In 193 some cases, it is not clear which copy of X triggered the 194 ACK and hence the actual FT is either t2-t1 or t2-t0, but 195 which is a mystery. Therefore, in this situation an 196 implementation MUST use Karn's algorithm [KP87,RFC6298] and 197 use neither version of the FT sample and hence not update 198 the RTO. 200 There are cases where two copies of some data are 201 transmitted in a way whereby the sender can tell which is 202 being acknowledged by an incoming ACK. E.g., TCP's 203 timestamp option [RFC7323] allows for segments to be 204 uniquely identified and hence avoid the ambiguity. In such 205 cases there is no ambiguity and the resulting samples can 206 update the RTO. 208 (3) Each time the RTO fires and causes a retransmission the value of 209 the RTO MUST be exponentially backed off such that the next 210 firing requires a longer interval. The backoff may be removed 211 after the successful transmission of non-retransmitted data. 213 A maximum value MAY be placed on the RTO provided it is at least 214 60 seconds (a la [RFC6298]). 216 This ensures network safety. 218 (4) Retransmission timeouts MUST be taken as indications of 219 congestion in the network and the sending rate adapted using a 220 standard mechanism (e.g., TCP collapses the congestion window to 221 one segment [RFC5681]). 223 This ensures network safety. 225 An exception is made to this rule if a standard mechanism is 226 used to determine that a particular loss is due to a 227 non-congestion event (e.g., bit errors or packet reordering). 228 In such a case a congestion control action is not required. 230 3 Discussion 232 We note that research has shown the tension between responsiveness 233 and correctness of TCP's RTO seems to be a fundamental tradeoff 234 [AP99]. That is, making TCP's RTO more aggressive (via the EWMA 235 gains, lowering the minimum RTO, etc.) can reduce the time spent 236 waiting on needed retransmissions. However, at the same time such 237 aggressiveness leads to more needless retransmissions, as well. 238 Therefore, being as aggressive as the guidelines sketched in the 239 last section allow in any particular situation may not be the best 240 course of action (e.g., because an RTO expiration carries a 241 requirement to slow down). 243 While the tradeoff between responsiveness and correctness seems 244 fundamental, the tradeoff can be made less relevant if the sender 245 can detect and recover from spurious RTOs. Several mechanisms have 246 been proposed for this purpose, such as Eifel [RFC3522], F-RTO 247 [RFC5682] and DSACK [RFC2883,RFC3708]. Using such mechanisms may 248 allow a data originator to tip towards being more responsive without 249 incurring (as much of) the attendant costs of needless retransmits. 251 Also, note, that in addition to the experiments discussed in [AP99], 252 the Linux TCP implementation has been using various non-standard RTO 253 mechanisms for many years seemingly without large scale problems 254 (e.g., using different EWMA gains). Also, a number of 255 implementations use minimum RTOs that are less than the 1 second 256 specified in [RFC6298]. While the precise implications of this may 257 show more spurious retransmits (per [AP99]) we are aware of no large 258 scale problems caused by this change to the minimum RTO. 260 Finally, we note that while allowing implementations to be more 261 aggressive may in fact increase the number of needless 262 retransmissions the above guidelines fail safe in that they insist 263 on exponential backoff of the RTO and a transmission rate reduction. 264 Therefore, allowing implementers latitude in their instantiations of 265 an RTO mechanism does not somehow open the flood gates to aggressive 266 behavior. Since there is a downside to being aggressive the 267 incentives for proper behavior are retained in the mechanism. 269 4 Security Considerations 270 This document does not alter the security properties of 271 retransmission timeout mechanisms. See [RFC6298] for a discussion 272 of these within the context of TCP. 274 Acknowledgments 276 This document benefits from years of discussions with Ethan Blanton, 277 Sally Floyd, Shawn Ostermann, Vern Paxson and the members of the 278 TCPM and TCP-IMPL working groups. Ran Atkinson, Yuchung Cheng, 279 Jonathan Looney and Michael Scharf provided useful comments on a 280 previous version of this draft. 282 Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 Informative References 289 [AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path 290 Properties", Proceedings of the ACM SIGCOMM Technical Symposium, 291 September 1999. 293 [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 294 Estimates in Reliable Transport Protocols", SIGCOMM 87. 296 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 297 Selective Acknowledgment Options", RFC 2018, October 1996. 299 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 300 Extension to the Selective Acknowledgement (SACK) Option for 301 TCP", RFC 2883, July 2000. 303 [RFC3522] Ludwig, R., M. Meyer, "The Eifel Detection Algorithm for 304 TCP", RFC 3522, april 2003. 306 [RFC3708] Blanton, E., M. Allman, "Using TCP Duplicate Selective 307 Acknowledgement (DSACKs) and Stream Control Transmission 308 Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) 309 to Detect Spurious Retransmissions", RFC 3708, February 2004. 311 [RFC3940] Adamson, B., C. Bormann, M. Handley, J. Macker, 312 "Negative-acknowledgment (NACK)-Oriented Reliable Multicast 313 (NORM) Protocol", November 2004, RFC 3940. 315 [RFC4960] Stweart, R., "Stream Control Transmission Protocol", RFC 316 4960, September 2007. 318 [RFC5682] Sarolahti, P., M. Kojo, K. Yamamoto, M. Hata, "Forward 319 RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious 320 Retransmission Timeouts with TCP", RFC 5682, September 2009. 322 [RFC6298] Paxson, V., M. Allman, H.K. Chu, M. Sargent, "Computing 323 TCP's Retransmission Timer", June 2011, RFC 6298. 325 [RFC6582] Henderson, T., S. Floyd, A. Gurtov, Y. Nishida, "The 326 NewReno Modification to TCP's Fast Recovery Algorithm", April 327 2012, RFC 6582. 329 [RFC6675] Blanton, E., M. Allman, L. Wang, I. Jarvinen, M. Kojo, 330 Y. Nishida, "A Conservative Loss Recovery Algorithm Based on 331 Selective Acknowledgment (SACK) for TCP", August 2012, RFC 6675. 333 [RFC7323] Borman D., B. Braden, V. Jacobson, R. Scheffenegger, "TCP 334 Extensions for High Performance", September 2014, RFC 7323. 336 Authors' Addresses 338 Mark Allman 339 International Computer Science Institute 340 1947 Center St. Suite 600 341 Berkeley, CA 94704 343 EMail: mallman@icir.org 344 http://www.icir.org/mallman