Network Working Group Reiner Ludwig INTERNET-DRAFT Ericsson Research Expires: January 2002 July, 2001 TCP Retransmit (RXT) Flag 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 This document proposes a solution to TCPÆs retransmission ambiguity problem that is based on using a single bit, named the Retransmit (RXT) flag, taken from the Reserved field of the TCP header. The TCP sender sets the RXT flag in segments containing retransmitted data while the TCP receiver responds with an immediate pure ACK with the RXT flag set. This solution effectively avoids the unnecessary go- back-N retransmits that typically occur after a spurious timeout. Ludwig [Page 1] INTERNET-DRAFT TCP Retransmit (RXT) Flag July, 2001 1. Introduction The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. TCPÆs retransmission ambiguity problem [KP87] inevitably fools a TCP sender into a mode in which it unnecessarily retransmits all outstanding segments (go-back-N style). This problem can not be fixed with neither the SACK [RFC2018] nor the D-SACK [RFC2883] option since such information would arrive too late at the TCP sender to prevent the go-back-N retransmits. It has been shown how the timestamp option [RFC1323] could be used to solve this problem [LK00]. However, the price for that solution is the extra overhead added by timestamps: 12bytes for every data segment and for every ACK. This document proposes an alternative solution that is based on using a single bit, named the Retransmit (RXT) flag, from the Reserved field of the TCP header. The TCP sender sets the RXT flag in segments containing retransmitted data while the TCP receiver responds with an immediate pure ACK with the RXT flag set. 2. Definition of the RXT Flag We define bit 6 in the Reserved field of the TCP header as the RXT flag. The location of the 6-bit Reserved field in the TCP header is shown in Figure 3 of [RFC793]. Bit 8 and 9 of the Reserved field have been assigned to the Explicit Congestion Notification (ECN) [RFC2481] while bit 7 is under discussion to be assigned to the nonce scheme proposed in [WES01]. 3. Initial Handshake When a TCP sends a SYN segment, it MAY set the RXT flag. For a SYN segment, the setting of the RXT flag is defined as an indication that the TCP sending the SYN segment wishes to participate in the RXT scheme as both a sender and a receiver. When a TCP receives a SYN segment with the RXT flag set, it MAY set the RXT flag when it sends the SYN-ACK segment. For a SYN-ACK segment, the setting of the RXT flag is defined as an indication that the TCP sending the SYN-ACK segment agrees to participate in the RXT scheme as both a sender and a receiver. Setting the RXT flag in either the SYN or the SYN-ACK segment is not an indication that the segment is a retransmit. Ludwig [Page 2] INTERNET-DRAFT TCP Retransmit (RXT) Flag July, 2001 4. TCP Sender If both TCPs have agreed to participate in the RXT scheme, the TCP sender SHOULD set the RXT flag in segments containing retransmitted data. In all other cases, it SHOULD reset the RXT flag in data segments it sends. 5. TCP Receiver If both TCPs have agreed to participate in the RXT scheme, the TCP receiver SHOULD send an immediate pure ACK with the RXT flag set. In all other situations where a pure ACK is sent, the TCP receiver SHOULD reset the RXT flag. 6. Detecting and Responding to Spurious Timeouts By inspecting the RXT flag in the first ACK acknowledging a retransmit that was triggered by a timeout, a TCP sender can unambiguously determine whether the timeout it had taken was spurious or not. If the RXT flag is not set then this ACK could not have been sent in response to the retransmit. Instead, the first-time transmission of the retransmitted segment must have arrived at the TCP receiver, and that ACK was either triggered by that first-time transmission or any other first-time transmission that followed. The latter could happen because of delayed-ACKs or loss of earlier ACKs. When a TCP sender has detected that is had taken a spurious timeout it SHOULD ensure that when it resumes transmission it does so with the next unsent segment. This is unless future ACKs indicate a real loss in the potentially remaining flight of outstanding segments. This will prevent further unnecessary (go-back-N style) retransmission that the returning original ACKs would otherwise trigger (see [LK00] for detail). I.e., when the ACK arrives that indicates that the TCP sender had taken a spurious timeout, the TCP sender should set snd.nxt to snd.max instead of leaving snd.nxt set to snd.una, borrowing the definition of snd.nxt, snd.una, and snd.max from [WS95]. Note, that when the ACK arrives that indicates that the TCP sender had taken a spurious timeout, the TCP sender has entered the slow start phase [RFC2581]. LetÆs assume that the TCP receiver acknowledges every segment (or the TCP sender implements byte- counting), and that none of the first-time transmissions of the outstanding flight of segments nor any of the corresponding ACKs got lost. Then the first half of those ACKs will not clock out any data when arriving at the TCP sender. That is, the TCP sender will resume transmission only when the second half of those ACKs arrive. This Ludwig [Page 3] INTERNET-DRAFT TCP Retransmit (RXT) Flag July, 2001 might be considered as an appropriate penalty for underestimating the retransmission timeout value. Note also, that no other response by the TCP sender, e.g., as proposed in [LK00], is defined in this document. 5. Security Considerations The RXT scheme does not alter TCPÆs congestion control behavior [RFC2581], and there is no obvious benefit for neither the TCP sender nor the TCP receiver to lie about the RXT flag. Hence, there seem to be no security concerns. Acknowledgments Many thanks to Keith Sklower for helping to develop the tools that allowed the study of spurious timeouts. Many thanks to Randy Katz, Michael Meyer, Stephan Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, and Andrei Gurtov for discussions around the Eifel algorithm. References [RFC2581] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, RFC 2581, April 1999. [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997. [RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High Performance, RFC 1323, May 1992. [RFC2018] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective Acknowledgement Options, RFC 2018, October 1996. [RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky, A. Romanow, An Extension to the Selective Acknowledgement (SACK) Option for TCP, RFC 2883, July 2000. [KP87] P. Karn, C. Partridge, Improving Round-Trip Time Estimates in Reliable Transport Protocols, In Proceedings of ACM SIGCOMM 87. [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, available at http://www.acm.org/sigcomm/ccr/archive/2000/ jan00/ccr-200001-ludwig.html (easier studied when viewed/printed in color). Ludwig [Page 4] INTERNET-DRAFT TCP Retransmit (RXT) Flag July, 2001 [RFC793] J. Postel, Transmission Control Protocol, RFC793, September 1981. [WES01] D. Wetherall, D. Ely, N. Spring, Robust ECN Signaling with Nonces, work in progress, July 2001. [WS95] G. R. Wright, W. R. Stevens, TCP/IP Illustrated, Volume 2 (The Implementation), Addison Wesley, January 1995. Author's Address 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 January 2002. Ludwig [Page 5]