idnits 2.17.1 draft-allman-tcpm-rto-consider-01.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 'Intended status' indicated for this document; assuming Proposed Standard 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 24, 2012) is 4327 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: 'RFC5681' is mentioned on line 165, but not defined == Missing Reference: 'RFC1323' is mentioned on line 150, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 3517 (Obsoleted by RFC 6675) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 3 errors (**), 0 flaws (~~), 5 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 draft-allman-tcpm-rto-consider-01.txt May 24, 2012 5 Retransmission Timeout Considerations 7 Status of this Memo 9 This Internet-Draft is submitted to IETF in full conformance with 10 the provisions of BCP 78 and BCP 79. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on November 24, 2012. 30 Copyright Notice 32 Copyright (c) 2012 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with 40 respect to this document. Code Components extracted from this 41 document must include Simplified BSD License text as described in 42 Section 4.e of the Trust Legal Provisions and are provided without 43 warranty as described in the Simplified BSD License. 45 Abstract 47 This document provides for high-level guidance for retransmission 48 timeout schemes appropriate for general use in the Internet. 50 Terminology 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in BCP 14, RFC 2119 56 [RFC2119]. 58 1 Introduction 60 Despite our best intentions and most robust mechanisms, reliability 61 in networking ultimately requires a timeout and re-try mechanism. 62 Often there are more timely and precise mechanisms for repairing 63 loss (e.g., TCP's fast retransmit [RFC5681], NewReno [RFC6582] or 64 selective acknowledgment scheme [RFC2018,RFC3517]) which require 65 information exchange between components in the system. Such 66 communication cannot be guaranteed. To the contrary, we can always 67 depend on the passage of time and therefore our ultimate backstop to 68 ensuring reliability is a timeout. (Note: There is a case when we 69 cannot count on the passage of time, but in this case we believe 70 repairing loss will be a moot point and hence we do not further 71 consider this case in this document.) 73 Various protocols have defined their own timeout mechanisms (e.g., 74 TCP [RFC6298], SCTP [RFC4960]). The specifics of retransmission 75 timeouts often represent a particular tradeoff between correctness 76 and responsiveness. Therefore, we have found that even though the 77 procedures are standardized, implementations also often add their 78 own subtle imprint on the specifics of the process to tilt the 79 tradeoff between correctness and responsiveness in some way. At 80 this point we recognize that often the specifics are not crucial for 81 network safety. Hence, in this document we outline the high-level 82 principles that are crucial for any retransmission timeout scheme to 83 leverage. The intent is to then allow implementations of protocols 84 and applications to instantiate mechanisms that best realize their 85 specific goals within this framework. These specific mechanisms 86 could be standardized or ad-hoc, but as long as they adhere to the 87 guidelines given in this document they would be considered 88 consistent with the standards. 90 2 Guidelines 92 We now list the four guidelines that apply when utilizing a 93 retransmission timeout (RTO). 95 (1) In the absence of any knowledge about the round-trip time (RTT) 96 of a path the RTO MUST be conservatively set to no less than 1 97 second, per TCP's current default RTO [RFC6298]. 99 This guideline ensures two important aspects of the RTO. First, 100 when transmitting into an unknown network, retransmissions will 101 not be sent before an ACK would reasonably be expected to arrive 102 and hence possibly waste scarce network resources. Second, as 103 noted below, sometimes retransmissions can lead to ambiguities 104 in assessing the RTT of a network path. Therefore, it is 105 especially important for the first RTT sample to be free of 106 ambiguities such that there is a baseline for the remainder of 107 the communication. 109 (2) We specify three guidelines that pertain to the sampling of the 110 RTT. 112 (a) In steady state the RTO MUST be set based on recent 113 observations of both the RTT and the variance of the RTT. 115 In other words, the RTO should be based on a reasonable 116 amount of time the sender should wait for an acknowledgment 117 of the data before retransmitting the given data. 119 (b) RTT observations MUST be taken regularly. 121 The exact definition of "regularly" is deliberately left 122 vague. TCP takes an RTT sample once per RTT, or if using 123 the timestamp option [RFC1323] on each acknowledgment 124 arrival. [AP99] shows that both these approaches result in 125 roughly equivalent performance for the RTO estimator. 126 Additionally, [AP99] shows that taking only a single RTT 127 sample per TCP connection is also suboptimal. Therefore, 128 for the purpose of this guideline we state that RTT samples 129 SHOULD be taken at least every RTT or as frequently as data 130 is exchanged and ACKed if that happens less frequently than 131 every RTT. However, we also recognize that it may not 132 always be practical to take an RTT sample this often in all 133 cases and hence this requirement is explicitly a "SHOULD" 134 and not a "MUST". 136 (c) RTT samples used in the computation of the RTO MUST NOT be 137 ambiguous. 139 Assume two copies of some segment X are transmitted at times 140 t0 and t1 and then segment X is acknowledged at time t2. It 141 is not clear which copy of X triggered the ACK and hence the 142 actual RTT is either t2-t1 or t2-t0, but which could be a 143 mystery. Therefore, in this situation we use Karn's 144 algorithm [KP87,RFC6298] to use neither version of the RTT 145 sample and hence not update the RTO. 147 There are cases where two copies of some data are 148 transmitted in a way whereby the sender can tell which is 149 being acknowledged by an incoming ACK. E.g., TCP's 150 timestamp option [RFC1323] allows for segments to be 151 uniquely identified and hence avoid the ambiguity. In such 152 cases there is no ambiguity and the resulting samples can 153 update the RTO. 155 (3) Each time the RTO fires and causes a retransmission the value of 156 the RTO MUST be exponentially backed off such that the next 157 firing requires a longer interval. The backoff may be removed 158 after the successful transmission of non-retransmitted data. 160 This ensures network safety. 162 (4) Retransmission timeouts MUST be taken as indications of 163 congestion in the network and the sending rate adapted using a 164 standard mechanism (e.g., TCP collapses the congestion window to 165 one segment [RFC5681]). 167 This ensures network safety. 169 An exception is made to this rule if a standard mechanism is 170 used to determine that a particular loss is due to a 171 non-congestion event (e.g., bit errors). In such a case a 172 congestion control action is not required. 174 3 Discussion 176 We note that research has shown the tension between responsiveness 177 and correctness of TCP's RTO seems to be a fundamental tradeoff 178 [AP99]. That is, making TCP's RTO more aggressive (via the EWMA 179 gains, lowering the minimum RTO, etc.) can reduce the time spent 180 waiting on needed RTOs. However, at the same time such 181 aggressiveness leads to more needless RTOs, as well. Therefore, 182 being as aggressive as the guidelines sketched in the last section 183 allow in any particular situation may not be the best course of 184 action (e.g., because an RTO expiration carries a requirement to 185 slow down). 187 While the tradeoff between responsiveness and correctness seems 188 fundamental, the tradeoff can be made less relevant if the sender 189 can detect and recover from spurious RTOs. Several mechanisms have 190 been proposed for this purpose, such as Eifel [RFC3522], F-RTO 191 [RFC5682] and DSACK [RFC2883,RFC3708]. Using such mechanisms may 192 allow a data originator to tip towards being more responsive without 193 incurring (as much of) the attendant costs of needless retransmits. 195 Also, note, that in addition to the experiments discussed in [AP99], 196 the Linux TCP implementation has been using various non-standard RTO 197 mechanisms for many years seemingly without large scale problems 198 (e.g., using different EWMA gains). Also, a number of 199 implementations use minimum RTOs that are less than the 1 second 200 specified in [RFC6298]. While the precise implications of this may 201 show more spurious retransmits (per [AP99]) we are aware of no large 202 scale problems caused by this change to the minimum RTO. 204 Finally, we note that while allowing implementations to be more 205 aggressive may in fact increase the number of needless 206 retransmissions the above guidelines fail safe in that they insist 207 on exponential backoff of the RTO and a transmission rate reduction. 208 Therefore, allowing implementers latitude in their instantiations of 209 an RTO mechanism does not somehow open the flood gates to aggressive 210 behavior. Since there is a downside to being aggressive the 211 incentives for proper behavior are retained in the mechanism. 213 4 Security Considerations 215 This document does not alter the security properties of 216 retransmission timeout mechanisms. See [RFC6298] for a discussion 217 of these within the context of TCP. 219 Acknowledgments 221 This document benefits from years of discussions with Sally Floyd, 222 Shawn Ostermann, Vern Paxson and the members of the TCPM and 223 TCP-IMPL working groups. 225 Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 Informative References 232 [AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path 233 Properties", Proceedings of the ACM SIGCOMM Technical Symposium, 234 September 1999. 236 [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 237 Estimates in Reliable Transport Protocols", SIGCOMM 87. 239 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 240 Selective Acknowledgment Options", RFC 2018, October 1996. 242 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 243 Extension to the Selective Acknowledgement (SACK) Option for 244 TCP", RFC 2883, July 2000. 246 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 247 Conservative Selective Acknowledgment (SACK)-based Loss Recovery 248 Algorithm for TCP", RFC 3517, April 2003. 250 [RFC3522] Ludwig, R., M. Meyer, "The Eifel Detection Algorithm for 251 TCP", RFC 3522, april 2003. 253 [RFC3708] Blanton, E., M. Allman, "Using TCP Duplicate Selective 254 Acknowledgement (DSACKs) and Stream Control Transmission 255 Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) 256 to Detect Spurious Retransmissions", RFC 3708, February 2004. 258 [RFC4960] Stweart, R., "Stream Control Transmission Protocol", RFC 259 4960, September 2007. 261 [RFC5682] Sarolahti, P., M. Kojo, K. Yamamoto, M. Hata, "Forward 262 RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious 263 Retransmission Timeouts with TCP", RFC 5682, September 2009. 265 [RFC6298] Paxson, V., M. Allman, H.K. Chu, M. Sargent, "Computing 266 TCP's Retransmission Timer", June 2011, RFC 6298. 268 [RFC6582] Henderson, T.,, S. Floyd, A. Gurtov, Y. Nishida, "The 269 NewReno Modification to TCP's Fast Recovery Algorithm", April 270 2012, RFC 6582. 272 Authors' Addresses 274 Mark Allman 275 International Computer Science Institute 276 1947 Center St. Suite 600 277 Berkeley, CA 94704 279 Phone: 440-235-1792 280 EMail: mallman@icir.org 281 http://www.icir.org/mallman