idnits 2.17.1 draft-allman-tcpm-rto-consider-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 '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 date (March 4, 2011) is 4773 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 104, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-02) exists of draft-paxson-tcpm-rfc2988bis-01 -- 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 (~~), 4 warnings (==), 4 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-00.txt March 4, 2011 5 Retransmission Timeout Considerations 7 Status of this Memo 9 This Internet-Draft is submitted in full conformance with the 10 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/1id-abstracts.html 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html 28 Copyright Notice 30 Copyright (c) 2011 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with 38 respect to this document. Code Components extracted from this 39 document must include Simplified BSD License text as described in 40 Section 4.e of the Trust Legal Provisions and are provided without 41 warranty as described in the Simplified BSD License." 43 Abstract 45 This document provides for high-level guidance for retransmission 46 timeout schemes appropriate for general use in the Internet. 48 Terminology 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in BCP 14, RFC 2119 53 [RFC2119]. 55 1 Introduction 57 Despite our best intentions and most robust mechanisms, reliability 58 in networking ultimately requires a timeout and re-try mechanism. 59 Often there are more timely and precise mechanisms (e.g., TCP's 60 selective acknowledgment scheme [RFC2018,RFC3517]), but these 61 require information exchange between components in the system, which 62 cannot be guaranteed. To the contrary, we can always depend on the 63 passage of time and therefore our ultimate backstop to ensuring 64 reliability is a timeout. 66 Various protocols have defined their own timeout mechanisms (e.g., 67 TCP [RFC2988], SCTP [RFC4960], etc.). Further, while standardized, 68 implementations also add their own subtle tweaks to the process. At 69 this point we recognize that often the specifics are not crucial for 70 network safety. In this document we outline the high-level 71 principles that are crucial for any retransmission timeout scheme to 72 leverage. The intent is to then allow implementations of protocols 73 and applications instantiate mechanisms that best realize their 74 specific goals within this framework. These specific mechanisms 75 could be standardized or ad-hoc, but as long as they adhere to the 76 guidelines given in this document they would be consistent with the 77 standards. 79 2 Guidelines 81 We now list the four guidelines that apply when utilizing a 82 retransmission timeout (RTO). 84 (1) In the absence of any knowledge about the round-trip time (RTT) 85 of a path the RTO MUST be conservatively set to no less than 1 86 second, per TCP's current default RTO [RFC2988bis]. 88 [Note: The above assumes [RFC2988bis] becomes the TCP standard 89 as it seems to the author is likely to happen given that the 90 document is in WGLC and has seen no objections thus far. If 91 it ultimately does not pass the above would be revised to 3 92 seconds, per RFC 2988.] 94 (2) In steady state the RTO MUST be set based on recent observations 95 of both the RTT and the variance of the RTT. Also, RTT 96 observations MUST be taken regularly. Finally, RTT samples MUST 97 NOT be ambiguous (i.e., using Karn's algorithm [KP87,RFC2988] 98 retransmitted segments produce ambiguous RTT samples unless they 99 explicitly carry a timestamp). 101 The exact definition of "regularly" is deliberately left vague. 103 TCP takes an RTT sample once per RTT, or if using the timestamp 104 option [RFC1323] on each acknowledgment arrival. [AP99] shows 105 that taking an RTT sample from each segment transmitted does not 106 improve the performance of TCP's RTO estimator. However, we are 107 aware of no empirical evidence that explores sampling less 108 frequently than once per RTT. 110 Therefore, for the purpose of this guideline we state that RTT 111 samples SHOULD be taken at least every RTT or as frequently as 112 data is exchanged and ACKed if that happens less frequently than 113 every RTT. However, we also recognize that it may not always be 114 practical to take an RTT sample this often and so state that RTT 115 samples MUST be taken no more than 1 second apart (assuming the 116 data rate allows). 118 (3) Each time the RTO fires and causes a retransmission the value of 119 the RTO MUST be exponentially backed off such that the next 120 firing requires a longer interval. The backoff may be removed 121 after a successful transmission. 123 (4) Retransmission timeouts MUST be taken as indications of 124 congestion in the network and the sending rate adapted using a 125 standard mechanism (e.g., TCP collapses the congestion window to 126 one segment). 128 3 Discussion 130 We note that research has shown the tension between responsiveness 131 and correctness of TCP's RTO seems to be a fundamental tradeoff 132 [AP99]. That is, making the RTO more aggressive (via the EWMA 133 gains, lowering the minimum RTO, etc.) can reduce the time spent 134 waiting on needed RTOs. However, at the same time such 135 aggressiveness leads to more needless RTOs, as well. Therefore, 136 being as aggressive as the guidelines sketched in the last section 137 allow in any particular situation may not be the best course of 138 action (e.g., because an RTO carries a requirement to slow down). 140 While the tradeoff between responsiveness and correctness seems 141 fundamental, the tradeoff can be made less relevant if the sender 142 can detect and recover from spurious RTOs. Several mechanisms have 143 been proposed for this purpose, such as Eifel [RFC3522], F-RTO 144 [RFC5682] and DSACK [RFC2883,RFC3708]. Using such mechanisms may 145 allow a data originator to tip towards being more responsive without 146 incurring the attendant costs of needless retransmits. 148 Also, note, that in addition to the experiments discussed in [AP99], 149 the Linux TCP implementation has been using various non-standard RTO 150 mechanisms for many years seemingly without large scale problems 151 (e.g., using different EWMA gains). Also, a number of 152 implementations use minimum RTOs that are less than the 1 second 153 specified in [RFC2988]. While the precise implications of this may 154 show more spurious retransmits (per [AP99]) we are aware of no large 155 scale problems caused by this change to the minimum RTO. 157 4 Security Considerations 159 Feh! 161 Acknowledgments 162 This document benefits from years of discussions with Sally Floyd, 163 Shawn Ostermann, Vern Paxson and the members of the TCPM and 164 TCP-IMPL working groups. 166 Normative References 168 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 169 Requirement Levels", BCP 14, RFC 2119, March 1997. 171 Informative References 173 [AP99] Allman, M., V. Paxson, "On Estimating End-to-End Network Path 174 Properties", Proceedings of the ACM SIGCOMM Technical Symposium, 175 September 1999. 177 [KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time 178 Estimates in Reliable Transport Protocols", SIGCOMM 87. 180 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 181 Selective Acknowledgment Options", RFC 2018, October 1996. 183 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 184 Extension to the Selective Acknowledgement (SACK) Option for 185 TCP", RFC 2883, July 2000. 187 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 188 Timer", RFC 2988, November 2000. 190 [RFC2988bis] Paxson, V., M. Allman, H.K. Chu, M. Sargent, "Computing 191 TCP's Retransmission Timer", Internet-Draft 192 draft-paxson-tcpm-rfc2988bis-01.txt (work in progress), December 193 2010. 195 [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A 196 Conservative Selective Acknowledgment (SACK)-based Loss Recovery 197 Algorithm for TCP", RFC 3517, April 2003. 199 [RFC3522] Ludwig, R., M. Meyer, "The Eifel Detection Algorithm for 200 TCP", RFC 3522, april 2003. 202 [RFC3708] Blanton, E., M. Allman, "Using TCP Duplicate Selective 203 Acknowledgement (DSACKs) and Stream Control Transmission 204 Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) 205 to Detect Spurious Retransmissions", RFC 3708, February 2004. 207 [RFC4960] Stweart, R., "Stream Control Transmission Protocol", RFC 208 4960, September 2007. 210 [RFC5682] Sarolahti, P., M. Kojo, K. Yamamoto, M. Hata, "Forward 211 RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious 212 Retransmission Timeouts with TCP", RFC 5682, September 2009. 214 Authors' Addresses 215 Mark Allman 216 International Computer Science Institute 217 1947 Center St. Suite 600 218 Berkeley, CA 94704 220 Phone: 440-235-1792 221 EMail: mallman@icir.org 222 http://www.icir.org/mallman