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]