Network Working Group Reiner Ludwig INTERNET-DRAFT Michael Meyer Expires: May 2002 Ericsson Research 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. Ludwig & Meyer [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 whether the first new ACK that arrives after a retransmit was sent in response to the original transmit or the retransmit. 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 [Lu01], [LG01]). Ludwig & Meyer [Page 2] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 Also, the DSACK option [RFC2883] may be used to detect spurious retransmits. However, the DSACK option cannot be used to eliminate the retransmission ambiguity. The reason is that the first new ACK for a retransmit will commonly not carry a DSACK option. That is, the DSACK option commonly arrives one or more ACKs later than the first new ACK for a retransmit. This is independent of whether the retransmit was genuine or spurious. 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 retransmits of data segments, SYNs and FINs. The TCP sender SHOULD reset (binary 0) the RXT flag in non-retransmits. Ludwig & Meyer [Page 3] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 Else, if the TCP sender has not received a RXT-Flag-Permitted option in the SYN-ACK, the TCP sender MUST NOT make use the RXT flag of arriving ACKs. 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. 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 after 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 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. This is stressed since the following counter-example has been pointed out to the authors: In case the original transmit was dropped in the network, a new ACK that arrives after a 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 outstanding when the retransmit was sent, 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 outstanding when the retransmit was sent. Note: This example holds independent of whether the loss recovery phase was triggered by the arrival of the third duplicate ACK or by a timeout. Ludwig & Meyer [Page 4] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 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. Nevertheless, the RXT flag would allow the TCP sender to disable Karn's algorithm [RFC1122] as long as the same segment has only been retransmitted once. 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, 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. [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. Ludwig & Meyer [Page 5] INTERNET-DRAFT The TCP Retransmit (RXT) Flag November, 2001 [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. [Lu01] R. Ludwig, The Eifel Algorithm for TCP, work in progress, November 2001. [LG01] R. Ludwig, A. Gurtov, Responding to Spurious Timeouts in TCP, work in progress, November 2001. [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. [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 Michael Meyer Ericsson Research (EED) Ericsson Allee 1 52134 Herzogenrath, Germany Phone: +49 2407 575 654 Fax: +49 2407 575 400 Email: Michael.Meyer@Ericsson.com This Internet-Draft expires in May 2002. Ludwig & Meyer [Page 6]