Network Working Group Reiner Ludwig INTERNET-DRAFT Ericsson Research Expires: May 2002 November, 2001 The 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. It 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. In response to such a segment, the TCP receiver sends an immediate pure ACK with the RXT flag set. By inspecting the RXT flag of the ACKs that arrive after a retransmit the TCP sender can then resolve the retransmission ambiguity. This protocol feature provides a basis for future TCP enhancements such as schemes to detect and respond to spurious timeouts and packet re-orderings. R. Ludwig [Page 1] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 Terminology 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]. We use the term æpure ACKÆ to refer to an ACK that is not piggy backed onto a data segment. We use the term æimmediate ACKÆ to refer to an ACK that the TCP receiver sends immediately in response to the arrival of a data segment. That is, without waiting for the delayed- ACK timer [RFC1122] to expire. We use the term ænew ACKÆ to refer to an ACK that acknowledges outstanding data. Furthermore, we refer to the first-time transmission of a data segment as the æoriginal transmitÆ. 1. Introduction The retransmission ambiguity problem [KP87] is the TCP senderÆs inability to distinguish an ACK that was triggered by the original transmit from the ACK that was triggered by the retransmit of the same data. This leads to additional problems such as spurious retransmits and unnecessary load reductions that occur after spurious timeouts or packet re-orderings [LK00]. Another consequence is that the RTT estimators cannot be updated when the segment that is timed has been retransmitted [KP87]. One way of eliminating the retransmission ambiguity in TCP is the use of the Timestamps option field [RFC1323]. A segmentÆs timestamp can be viewed as its serial number that is echoed in the corresponding ACK. Some BSD-derived TCP implementations make use of this in that the RTT estimators are updated even for retransmitted segments. However, the Timestamps option field adds considerable overhead: 12 bytes that are added to every data segment and to every ACK. Moreover, the Timestamps option field is not compressed by current TCP/IP header compression schemes [RFC2507], and even effectively disables other widely deployed TCP/IP header compression schemes [RFC1144]. This document defines a more efficient solution, named the RXT scheme, to resolve the retransmission ambiguity in TCP. It 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. In response to such a segment, the TCP receiver sends an immediate pure ACK with the RXT flag set. By inspecting the RXT flag of the ACKs that arrive after a retransmit the TCP sender can then resolve the retransmission ambiguity. This protocol feature provides a basis for future TCP enhancements such as schemes to detect and respond to spurious timeouts and packet re-orderings (e.g., see [LK00]). R. Ludwig [Page 2] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 2. RXT-Flag-Permitted Option and Initial Handshake Definition of the two-byte TCP RXT-Flag-Permitted option: +---------+---------+ | Kind=6 | Length=2| +---------+---------+ When a TCP sends a SYN segment, it MAY include the RXT-Flag-Permitted option in the SYN. This 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 that includes the RXT-Flag- Permitted option, it MAY also include the RXT-Flag-Permitted option in the SYN-ACK. This 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. The RXT-Flag-Permitted option MUST NOT be sent in a segment that is not a SYN or SYN-ACK. 3. 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) [RFC3168] while bit 7 is under discussion to be assigned to the nonce scheme proposed in [SWE01]. 4. TCP Sender If both TCPs have agreed to participate in the RXT scheme, the TCP sender SHOULD set (binary 1) the RXT flag in retransmits. This includes data segments, SYNs and FINs. In all other cases, it SHOULD reset (binary 0) the RXT flag in segments it sends. 5. TCP Receiver If both TCPs have agreed to participate in the RXT scheme, the TCP receiver MUST send an immediate pure ACK with the RXT flag set (binary 1) in response to a segment that arrived with the RXT flag set. In particular, the RXT flag is set in a SYN-ACK (FIN-ACK) when sent in response to a SYN (FIN) that arrived with the RXT flag set. R. Ludwig [Page 3] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 Note, that the immediate pure ACK might also return to the TCP sender as a duplicate ACK. This will typically occur after a spurious retransmit. In all other situations where a pure ACK is sent, the TCP receiver MUST reset (binary 0) the RXT flag. 6. Interpreting the RXT Flag When using the RXT scheme it should be carefully considered what information exactly the RXT flag conveys. Whether or not the RXT flag is set in a data segment or an ACK, allows to reliably draw certain conclusions. In some situations, however, it only indicates with some certainty that a particular event has occurred. This is discussed in the following assuming that the RXT scheme is correctly implemented in both TCPs. When a new ACK with the RXT flag not set (binary 0) arrives that acknowledges a retransmit, the TCP sender can reliably conclude that that ACK was not triggered by a retransmit. Furthermore, the TCP sender may take that ACK as a strong indication that the retransmit being acknowledged was spurious, i.e., that the original transmit arrived at the TCP receiver. This is only a strong indication and cannot be concluded with absolute certainty since it is possible to construct a counter-example: In case the original transmit was dropped in the network, a new ACK acknowledging the retransmit would also not have the RXT flag set (binary 0) if (1) the retransmit arrived at the TCP receiver in sequence, i.e., if it had jumped ahead of all data segments that were sent between the original transmit and the retransmit, and if (2) the ACK for the retransmit with the RXT flag set (binary 1) got lost. In that case the mentioned new ACK would correspond to one of the data segments that were sent between the original transmit and the retransmit. However, this counter-example might be regarded as a rather pathological case. In addition, it seems to be the only conceivable counter-example. Hence, it might be regarded as safe to assume that the mentioned new ACK indicates that the retransmit was spurious. The RXT flag is useful to distinguish between an ACK for an original transmit and an ACK for a retransmit. However, the single bit does not help in deciding to which retransmit an ACK corresponds in case multiple retransmits of the same data have been sent. A ôRXT counterö allocating at least two bits would be required to allow for that. For situations where this becomes an issue, e.g., round-trip time estimation in environments with high packet loss rates, the use of the Timestamps option [RFC1323] is a suitable alternative. R. Ludwig [Page 4] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 7. Security Considerations There do not seem to be any security considerations associated with the RXT scheme itself. This is because the RXT scheme is only a signaling scheme that is not tied to any specific action that might alter protocol state at the TCP sender or receiver. However, security considerations might exist for schemes that use the RXT scheme as a basis. In particular, it needs to be considered that the TCP receiver might by lying about the RXT flag. Acknowledgments Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, and Andrei Gurtov for very useful discussions that contributed to this work. References [RFC1122] R. Braden, Requirements for Internet Hosts - Communication Layers, RFC 1122, October 1989. [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997. [RFC2507] M. Degermark, B. Nordgren, S. Pink, IP Header Compression, RFC 2507, February 1999. [RFC1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links, RFC 1144, February 1990. [RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High Performance, RFC 1323, May 1992. [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. [RFC793] J. Postel, Transmission Control Protocol, RFC 793, September 1981. [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of Explicit Congestion Notification (ECN) to IP, RFC 3168, September 2001. R. Ludwig [Page 5] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 [SWE01] N. Spring, D. Wetherall, D. Ely, Robust ECN Signaling with Nonces, work in progress, October 2001. Author's Address Reiner Ludwig Ericsson Research (EED) Ericsson Allee 1 52134 Herzogenrath, Germany Phone: +49 2407 575 719 Fax: +49 2407 575 400 Email: Reiner.Ludwig@Ericsson.com This Internet-Draft expires in May 2002. R. Ludwig [Page 6]