Network Working Group Andrei Gurtov INTERNET-DRAFT Sonera Expires: August 2002 Reiner Ludwig Ericsson Research February, 2002 Making TCP Robust Against Delay Spikes Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract We suggest a more conservative management of TCP's retransmit timer, and a more careful response of the TCP sender to duplicate ACKs that arrive after a timeout. The former reduces the risk of triggering spurious timeouts, while the latter eliminates potentially unnecessary retransmits. Although, we believe that these suggestions are permitted (although not explicitly) by RFC2581 and RFC2988, they do not seem to be widely known nor deployed in existing TCP implementations. We therefore want to make implementers aware of these choices. Gurtov & Ludwig [Page 1] INTERNET-DRAFT TCP and Delay Spikes February, 2002 Terminology We use the term 'DupThresh' as the number of DUPACKs that need to arrive at the TCP sender to trigger the fast retransmit algorithm, the default value is three [RFC2581]. 1. Introduction An increasing number of users access the Internet via data links provided by cellular Wide Area Wireless Networks (W-WANs). An end-to- end connection across a path including a W-WANs may often experience delay spikes on the order of seconds [GU01a]. We speak of a delay spike when the round-trip time (RTT) remains stable at a certain level for multiple RTTs, and then suddenly increases sharply. It may then drop again to the previous level. Reasons for delay spikes include handovers, resource preemption due to higher priority traffic (e.g., short messages service, or voice calls), or because the mobile transmitter traverses through a radio coverage hole. Such events may frequently occur in W-WANs over the lifetime of an end-to-end connection. How frequently they occur depends on user mobility, traffic load in a radio coverage cell, and cell sizes. Delay spikes may cause spurious timeouts that often lead to unnecessary (go-back-N) retransmits, and an unnecessary reduction of the TCP sender's send rate [LK00]. In this case, a TCP sender not only loads the network with useless traffic, but also violates the 'packet conservation' principle [Jac88]. On W-WANs links unnecessary retransmits are particularly harmful as they directly translate into a waste of scarce radio resources such as spectrum and transmission (battery) power. One way of making TCP robust against delay spikes is to enhance TCP to detect and respond to spurious timeouts as suggested in [LM02] and [LG02]. Another alternative is to make TCP's retransmit timer more conservative. This can be achieved by using the TCP Timestamps option [RFC1323] since timing every segment allows the TCP sender to gain a more accurate estimate of the RTT. This leads to a more conservative retransmit timer if the RTT varies considerably [GU01c] [Ina02]. Large RTT variations seem to be more common on bandwidth-dominated paths especially if the bottleneck link experiences a low degree of statistical multiplexing. On such paths, the RTT is largely determined by the packet transmission delay across the bottleneck link. Thus, packet sizes and rate changes of the bottleneck link can greatly impact the RTT. Paths across W-WANs fall into this category. Apart from the mentioned delay spikes such links may also be subject to rate changes by an order of magnitude (e.g. from 384 kb/s to 16 kb/s). In this document, we suggest a more conservative management of TCP's retransmit timer, and a more careful response of the TCP sender to Gurtov & Ludwig [Page 2] INTERNET-DRAFT TCP and Delay Spikes February, 2002 duplicate ACKs that arrive after a timeout. The former reduces the risk of triggering spurious timeouts, while the latter eliminates potentially unnecessary retransmits. Although, we believe that these suggestions are permitted (although not explicitly) by RFC2581 [RFC2581] and RFC2988 [RFC2988], they do not seem to be widely known nor deployed in existing TCP implementations. We therefore want to make implementers aware of these choices. In addition, we believe that these suggestions should be explicitly addressed when advancing RFC2581 and RFC2988 further along the standards track. This document is therefore aimed at becoming an informational document. Traces that illustrate the recommendations in this document can be found in [GU01b] and [GU01c]. 2. Restarting the Retransmit Timer on DUPACKs The general motivation for restarting the retransmit timer on DUPACKs is that a TCP sender may not want to timeout as long as it still receives feedback that segments are being delivered by the network. In addition, DUPACKs may carry useful SACK information [RFC2018]. 2.1 Restarting on DUPACKs Before DupThresh The retransmit timer should be restarted for every DUPACK that arrives before DupThresh is reached. The time until DupThresh has been reached can be extensively long when a delay spikes occurs in this phase of the connection. Restarting the timer on DUPACKs before DupThresh increases the TCP sender's chance of receiving the DUPACK that triggers the fast retransmit. This is particularly important if the TCP sender uses the Limited Transmit algorithm [RFC3042]. This is because with that algorithm and a small congestion window, the time until DupThresh has been reached is commonly long even without a delay spike. 2.2 Restarting on Fast Retransmit The retransmit timer should be restarted when the fast retransmit is sent. Although, many TCP implementations already do this (e.g., see [WS95]), it is not explicitly recommended by RFC2988. However, RFC2988 does recommend it for timeout-based retransmits. A fast retransmit should not be treated differently from a timeout-based retransmit in this respect. In both cases the ACK for the retransmit should be given the same amount of time to return as for normal transmits. 2.2 Restarting on DUPACKs After DupThresh See Section 4. Gurtov & Ludwig [Page 3] INTERNET-DRAFT TCP and Delay Spikes February, 2002 3. Ignoring DUPACKs after a Timeout A TCP sender should ignore DUPACKs that arrive after a timeout has occurred. Despite a conservative retransit timer, delay spikes can trigger spurious timeouts to occur during fast recovery. The proper behavior in this case is to follow the timeout recovery procedure described in [RFC2581]. However, a fairly common behavior among TCPs is to use DUPACKs that arrive after a timeout to clock-out retransmits of outstanding segments. This has been observed in the following TCPs: FreeBSD4.1, various versions of Microsoft Windows, and ns2 [GU01b] [GU01c]. In most cases those retransmits were unnecessary. This can result into further misbehavior as the TCP receiver generates further DUPACKs for the arriving duplicate segments. 4. Open Research Issues At the time of writing, we believe that restarting the retransmit timer for every DUPACK that arrives after the DupThresh had been reached is still a research issue. Advanced loss recovery schemes have been proposed that account for the case when the fast retransmit was lost [LK98]. The idea is to count DUPACKs and to retransmit the fast retransmit when the first DUPACK returns that must correspond to a new segment sent during the second half of fast recovery. Clearly, on such multiple fast retransmits the congestion window should be halved again. For such advanced loss recovery schemes, we believe that the retransmit timer should also be restarted for every DUPACK that arrives after the DupThresh had been reached. However, this is still an open issue that we currently study. 5. Security Considerations Security consideration for computing the retransmit timer are given in RFC2988. There are do not seem to be additional security concerns for recommendations given in this document. Acknowledgments Many thanks Mark Allman and Sally Floyd for discussions on the contents of this document. Alexey Kuznetsov, Noritoshi Demizu, Farid Khafizov provided valuable comments that contributed to this document. Gurtov & Ludwig [Page 4] INTERNET-DRAFT TCP and Delay Spikes February, 2002 References [RFC2581] M.Allman, V. Paxson, W. Stevens, TCP Congestion Control, RFC 2581, April 1999. [RFC3042] M. Allman, H. Balakrishnan, S. Floyd, Enhancing TCP's Loss Recovery Using Limited Transmit, RFC 3042, January 2001. [GU01a] A. Gurtov, Effect of Delays on TCP Performance, In Proceedings of IFIP Personal Wireless Communications, August 2001. [GU01b] A. Gurtov, Traces of TCP connections experiencing a delay spike, http://www.cs.helsinki.fi/u/gurtov/tcp/, January 2002. [GU01c] A. Gurtov, Making TCP Robust Against Delay Spikes, University of Helsinki, Department of Computer Science, C-2001-53, http://www.cs.helsinki.fi/u/gurtov/papers/, November 2001. [Ina02] H. Inamura et al., TCP over 2.5G and 3G Wireless Networks, work in progress, February 2002.. [Jac88] V. Jacobson, Congestion Avoidance and Control, In Proceedings of ACM SIGCOMM'88, 1988. [RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High Performance, RFC 1323, May 1992. [LK98] D. Lin, H. T. Kung, TCP Fast Recovery Strategies: Analysis and Improvements, In Proceedings of IEEE INFOCOM 98, March 1998. [LK00] R. Ludwig, R. H. Katz, The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions, ACM Computer Communication Review, Vol. 30, No. 1, January 2000. [LM02] R. Ludwig, M. Meyer, The Eifel Detection Algorithm for TCP, work in progress, February 2002. [LG02] R. Ludwig, A. Gurtov, The Eifel Response Algorithm to Spurious Timeouts in TCP, work in progress, February 2002. [RFC2018] M.Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective Acknowledgement Options, RFC 2018, October 1996. [RFC2988] V. Paxson, M. Allman, Computing TCP's Retransmission Timer, RFC 2988, November 2000. Gurtov & Ludwig [Page 5] INTERNET-DRAFT TCP and Delay Spikes February, 2002 [RFC793] J. Postel, Transmission Control Protocol, RFC 793, September 1981. [WS95] G. R. Wright, W. R. Stevens, TCP/IP Illustrated, Volume 2 (The Implementation), Addison Wesley, January 1995. Author's Address: Andrei Gurtov Sonera Corp. Cellular Systems Development P.O. Box 970, FIN-00051 Helsinki, Finland Fax: +358(0)204064365 Tel: +358(0)20401 Email: andrei.gurtov@sonera.com Homepage: http://www.cs.helsinki.fi/u/gurtov Reiner Ludwig Ericsson Research (EED) Ericsson Allee 1 52134 Herzogenrath, Germany Phone: +49 2407 575 719 Fax: +49 2407 575 400 Reiner.Ludwig@Ericsson.com This Internet-Draft expires in August 2002. Gurtov & Ludwig [Page 6]