TCP Maintenance and Minor P. Hurtig Extensions (tcpm) Karlstad University Internet-Draft A. Petlund Updates: 2988 (if approved) Simula Research Laboratory AS Intended status: Standards Track December 22, 2010 Expires: June 25, 2011 TCP and SCTP RTO Restart draft-hurtig-tcpm-rtorestart-00 Abstract This document proposes to restart the TCP and the SCTP retransmission timer with consideration to the earliest outstanding segment and thus updates the standard algorithm. It discusses the motivation, the required modifications and some experimental results. This document focuses on TCP, but the motivation and required modifications also apply to SCTP as both protocols use the same algorithm for RTO management. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 25, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Hurtig & Petlund Expires June 25, 2011 [Page 1] Internet-Draft TCP and SCTP RTO Restart December 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 1. Introduction The current RTO management algorithm ([RFC2988] for TCP and [RFC4960] for SCTP) recommends that the retransmission timer is restarted when an ACK that acknowledges new data is received and there is still outstanding data. The restart is conducted to guarantee that unacknowledged segments will be retransmitted after RTO seconds. This approach causes retransmissions to occur RTO seconds after the last ACK has been received, not RTO seconds after the transmission of the lost segment(s). This adds approximately one round-trip time (RTT) to the loss recovery time. If the ACK that triggers the restart also is a delayed ACK [RFC1122] then the total loss recovery time can become RTO + RTT + delACK, where delACK corresponds to the receiver's delayed ACK settings. The retransmission timer restart process brings confusion to the loss recovery, as the time required for retransmitting lost segments depends on their position in the data stream. Only the first data segment of a connection, or the first segment after an idle period, is retransmitted after exactly RTO seconds. Remaining segments are retransmitted after RTO + RTT seconds or RTO + RTT + delACK seconds, depending on how many packets that have been sent and if the receiver employs delayed ACKs. This document proposes an alternative restart approach. By resetting the timer to "RTO - T_earliest", where T_earliest is the time elapsed since the earliest outstanding segment was transmitted, retransmissions will always occur after exactly RTO seconds. In addition to improving loss recovery performance, this approach causes Hurtig & Petlund Expires June 25, 2011 [Page 2] Internet-Draft TCP and SCTP RTO Restart December 2010 the semantics of the loss recovery to be clear and unambiguous. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Proposed Modifications The document proposes an update of step 5.3 in Section 5 of [RFC2988] to (and a similar update of step R3 in section 6.3.2 of [RFC4960]): When an ACK is received that acknowledges new data, restart the retransmission timer so that it will expire RTO seconds after the earliest outstanding segment was transmitted (for the current value of RTO). The update requires TCP implementations to track the time elapsed since sending the last unacknowledged segment. In practice, this could be achieved by adding one variable to the transmission control block. 3. Experimental Results The currently standardized algorithm has been shown to add at least one RTT to the loss recovery process in TCP [LS00] and SCTP [HB08][PBP09]. Applications that have timing requirements (e.g. telephony signaling, gaming and web traffic) rather than throughput requirements may want to use a lower RTOmin than the standard of 1 second (see e.g. [RFC4166]). For such applications the proposed restart approach is important as the round-trip time and also the delayed ACK timer of receivers will be important factors in the effective loss recovery time. In [HB08] where a RTOmin of 100 ms was used, is was shown that the total transfer time of a lost segment (including the original transmission time and the loss recovery time) could be reduced with up to 35% using the suggested approach. 4. Security Considerations This document discusses a change in how to set the retransmission timer's value when restarted. This change does not raise any new security issues with TCP. Hurtig & Petlund Expires June 25, 2011 [Page 3] Internet-Draft TCP and SCTP RTO Restart December 2010 5. IANA Considerations This memo includes no request to IANA. 6. References 6.1. Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC4166] Coene, L. and J. Pastor-Balbas, "Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement", RFC 4166, February 2006. [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 6.2. Informative References [HB08] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely message delivery?", Springer Telecommunication Systems, May 2010. [LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), July 2000. [PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, C., and P. Halvorsen, "Improving SCTP Retransmission Delays for Time-Dependent Thin Streams", Springer Multimedia Tools and Applications, 45(1-3), 2009. Hurtig & Petlund Expires June 25, 2011 [Page 4] Internet-Draft TCP and SCTP RTO Restart December 2010 Authors' Addresses Per Hurtig Karlstad University Universitetsgatan 2 Karlstad, 651 88 Sweden Phone: +46 54 700 23 35 Email: per.hurtig@kau.se Andreas Petlund Simula Research Laboratory AS P.O. Box 134 Lysaker, 1325 Norway Phone: +47 67 82 82 00 Email: apetlund@simula.no Hurtig & Petlund Expires June 25, 2011 [Page 5]