Internet Engineering Task Force Mark Allman INTERNET DRAFT ICIR/ICSI draft-allman-rto-backoff-00.txt Ethan Blanton Expires: February 2006 Purdue University Josh Blanton Ohio University August 2005 Using Spurious Retransmissions to Adapt the Retransmission Timeout draft-allman-rto-backoff-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes a method for using spurious retransmission timeouts as the trigger for slightly changing the way TCP's retransmission time is computed in an effort to avoid subsequent unnecessary retransmissions. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The reader is expected to be familiar with the algorithm and terminology from [RFC2988]. Expires: February 2006 [Page 1]
draft-allman-rto-backoff-00.txt August 2005 1. Introduction Various studies have shown that the retransmission timeout (RTO) estimator in [RFC2988] can trigger spurious retransmissions. [AP99] shows that such unnecessary retransmissions are generally fairly rare. However, [LK00] shows that in some networks (e.g., wireless networks) spurious retransmissions are more problematic due to occasional delay spikes that are not well predicted by TCP's RTO estimator. In this document we outline one possible approach to mitigate the impact of pre-mature RTO firings by altering the RTO estimator specified in [RFC2988]. Several methods for detecting spurious timeouts have been developed [RFC3522,RFC3708,RFC4138]. Additionally, [RFC4015] outlines one possible response to detecting spurious timeouts. This document outlines an alternative to [RFC4015]. In general terms, [RFC4015] specifies two actions upon the detection of an unnecessary RTO-based retransmission. First, the sending rate prior to the spurious retransmission is restored. Furthermore, the RTO is adapted by re-initializing the RTO estimator with the long round-trip time (RTT) measurement that caused the spurious RTO. The approach given in [RFC4015] is reasonable if the underlying cause of the problem is a shift in the path RTT. For instance, if the route a TCP connection is traversing changes and the new path's RTT is significantly longer than the previous path's RTT then simply re-initializing the RTO is a reasonable action. As specified in the next section this document takes a slightly different approach than [RFC4015]. Generally, this document uses the failure of the RTO to wait long enough before triggering a retransmit as an indication that the RTO estimator itself is not properly capturing the variance present in the RTTs experienced by the TCP connection. Therefore, this document calls for an increase in the contribution of the variance component in the RTO estimator upon the detection of retransmission timeouts in an effort to cope. This change represents a preference to try to avoid future spurious timeouts rather than simply reacting to each spurious retransmission. We note that TCP implementations using the RTTM mechanism [RFC1323] to assess the RTT multiple times per RTT with the standard exponentially-weighted moving average (EWMA) gains from [RFC2988] use less RTT history than when taking one RTT measurement per RTT. [AP99] shows that "fast" EWMAs yield more spurious retransmissions than when using the standard gains with one RTT sample per RTT. Therefore, an orthogonal change to TCP implementations that use RTTM that may prevent spurious RTOs is to set the EWMA gains based on the number of RTT samples taken per RTT such that the amount of history kept, in terms of time, is the same regardless of the number RTT samples taken []. 2. Parameter Changes Expires: February 2006 [Page 2]
draft-allman-rto-backoff-00.txt August 2005 As the basis for the changes proposed below, a TCP MUST support an IETF-specified spurious timeout detection method. Currently, [RFC3522], [RFC3708] and [RFC4138] are such detection methods. We note that the research literature includes alternate methods for detecting spurious retransmissions, e.g., the "retransmit bit" [LK00], but these schemes MUST NOT be used as part of the changes specified in this document until such time that the IETF approves a specification of these schemes. We also note that [RFC2988] explicitly allows for an RTO estimator that is more conservative than that given in [RFC2988]. Upon detection of a spurious RTO-based retransmission a TCP MAY alter the RTO estimator given in [RFC2988] in any way to be more conservative. The RECOMMENDED method for changing the RTO estimator given in [RFC2988] upon detection of a spurious timeout is to increase "K", the multiplier applied to RTTVAR in the RTO calculation given in step (2.3) of [RFC2988]. Specifically, before altering SRTT and RTTVAR based on the measured RTT R' (from step (2.3) in [RFC2988]) K should be adjusted to what would have prevented the unneeded RTO-based retransmit: K = ceil ((R' - SRTT) / RTTVAR) (1) This will increase K to the point where it would have prevented the spurious retransmission. After calculating K the R' RTT sample MUST be used to adjust SRTT and RTTVAR and therefore the RTO, per [RFC2988]. Note: This specification explicitly offers no way to reduce K after it has been inflated. K is never reduced because the standard estimator has been proven inadequate for accurately estimating the variance of the RTT across the network path and therefore reducing K would increase the chances of further spurious retransmissions. 3. Advantages The advantage of tuning the RTO calculation to be more conservative after detecting spurious RTO-based retransmissions is in preventing further spurious RTOs. In addition, spurious RTOs can cause go-back-N behavior which can also be avoided by adapting the RTO to be more conservative. 4. Disadvantages The disadvantage of tuning the RTO calculation to be more conservative is that legitimate RTO firings takes longer and could hurt performance. However, an important note is that the RTO should not be TCP's primary loss recovery strategy. [RFC3782] and [RFC3517] provide methods for TCP to effectively repair multiple lost segments from a single window of data without falling back to using the RTO. Further, research shows that these changes are Expires: February 2006 [Page 3]
draft-allman-rto-backoff-00.txt August 2005 widely implemented [MAF05]. Therefore, making TCP's RTO calculation more conservative should not hinder performance under normal circumstance. Put differently, when using advanced loss recovery techniques the firing of the RTO should be an indication that the congestion situation in the network is fairly bad. In this case, it may well be that making the RTO estimator more conservative is the right general approach. 5. Summary This document specifies a small change that makes the RTO calculation given in [RFC2988] more conservative upon the detection of spurious RTO-based retransmissions. The root cause of spurious retransmits is an inaccurate assessment of the network conditions (in this case, of the RTT). Therefore, we tackle this by making the RTO calculation take into account RTT variance to a larger degree. While this does lengthen the time required for legitimate retransmissions to fire, the RTO should not be TCP's primary means for retransmitting data and therefore this lengthened interval should only minimally impact overall performance and should only come into play when conditions along the network path have deteriorated significantly. Finally, we note that this document makes the estimator given in [RFC2988] strictly more conservative and is therefore allowed via [RFC2988]. 6. Security Considerations This document calls for a simple parameter tweak and does not change the security considerations given in [RFC2988]. 7. IANA Considerations None. Acknowledgments This document has benefited from discussions with Ted Faber, Aaron Falk, Sally Floyd and Joe Touch. Normative References [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels, March 1997. BCP 14, RFC 2119. [RFC2988] V. Paxson, M. Allman. Computing TCP's Retransmission Timer, November 2000. RFC 2988. [RFC3522] R. Ludwig, M. Meyer. The Eifel Detection Algorithm for TCP, April 2003. RFC 3522. [RFC3708] E. Blanton, M. Allman. Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions, February 2004. RFC 3708. Expires: February 2006 [Page 4]
draft-allman-rto-backoff-00.txt August 2005 [RFC4138] P. Sarolahti, M. Kojo. Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP), August 2005. RFC 4138. Informative References [AP99] Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. ACM SIGCOMM, September 1999. [LK00] R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. ACM Computer Communication Review, 30(1), January 2000. [MAF05] A. Medina, M. Allman, S. Floyd. Measuring the Evolution of Transport Protocols in the Internet. ACM Computer Communication Review, 35(2), April 2005. [RFC3517] E. Blanton, M. Allman, K. Fall, L. Wang. A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP, April 2003. RFC 3517. [RFC3782] S. Floyd, T. Henderson, A. Gurtov. The NewReno Modification to TCP's Fast Recovery Algorithm, April 2004. RFC 3782. [RFC4015] R. Ludwig, A. Gurtov. The Eifel Response Algorithm for TCP, February 2005. RFC 4015. Author's Addresses Mark Allman ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704-1198 Phone: (440) 235-1792 Email: mallman@icir.org URL: http://www.icir.org/mallman/ Ethan Blanton Purdue University Computer Sciences 250 North University Street West Lafayette, IN 47907 Email: eblanton@cs.purdue.edu URL: http://www.cs.purdue.edu/homes/eblanton/ Josh Blanton Ohio University Internetworking Research Group 301 Stocker Center Athens, OH 45701 Email: jblanton@cs.ohiou.edu URL: http://irg.cs.ohiou.edu/~jblanton/ Expires: February 2006 [Page 5]
draft-allman-rto-backoff-00.txt August 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Expires: February 2006 [Page 6]