Internet DRAFT - draft-gurtov-tsvwg-tcp-delay-spikes
draft-gurtov-tsvwg-tcp-delay-spikes
Network Working Group Andrei Gurtov
INTERNET-DRAFT Sonera
Expires: August 2002 Reiner Ludwig
Ericsson Research
February, 2002
Making TCP Robust Against Delay Spikes
<draft-gurtov-tsvwg-tcp-delay-spikes-00.txt>
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
We suggest a more conservative management of TCP's retransmit timer,
and a more careful response of the TCP sender to duplicate ACKs that
arrive after a timeout. The former reduces the risk of triggering
spurious timeouts, while the latter eliminates potentially
unnecessary retransmits. Although, we believe that these suggestions
are permitted (although not explicitly) by RFC2581 and RFC2988, they
do not seem to be widely known nor deployed in existing TCP
implementations. We therefore want to make implementers aware of
these choices.
Gurtov & Ludwig [Page 1]
INTERNET-DRAFT TCP and Delay Spikes February, 2002
Terminology
We use the term 'DupThresh' as the number of DUPACKs that need to
arrive at the TCP sender to trigger the fast retransmit algorithm,
the default value is three [RFC2581].
1. Introduction
An increasing number of users access the Internet via data links
provided by cellular Wide Area Wireless Networks (W-WANs). An end-to-
end connection across a path including a W-WANs may often experience
delay spikes on the order of seconds [GU01a]. We speak of a delay
spike when the round-trip time (RTT) remains stable at a certain
level for multiple RTTs, and then suddenly increases sharply. It may
then drop again to the previous level. Reasons for delay spikes
include handovers, resource preemption due to higher priority traffic
(e.g., short messages service, or voice calls), or because the mobile
transmitter traverses through a radio coverage hole. Such events may
frequently occur in W-WANs over the lifetime of an end-to-end
connection. How frequently they occur depends on user mobility,
traffic load in a radio coverage cell, and cell sizes.
Delay spikes may cause spurious timeouts that often lead to
unnecessary (go-back-N) retransmits, and an unnecessary reduction of
the TCP sender's send rate [LK00]. In this case, a TCP sender not
only loads the network with useless traffic, but also violates the
'packet conservation' principle [Jac88]. On W-WANs links unnecessary
retransmits are particularly harmful as they directly translate into
a waste of scarce radio resources such as spectrum and transmission
(battery) power.
One way of making TCP robust against delay spikes is to enhance TCP
to detect and respond to spurious timeouts as suggested in [LM02] and
[LG02]. Another alternative is to make TCP's retransmit timer more
conservative. This can be achieved by using the TCP Timestamps option
[RFC1323] since timing every segment allows the TCP sender to gain a
more accurate estimate of the RTT. This leads to a more conservative
retransmit timer if the RTT varies considerably [GU01c] [Ina02].
Large RTT variations seem to be more common on bandwidth-dominated
paths especially if the bottleneck link experiences a low degree of
statistical multiplexing. On such paths, the RTT is largely
determined by the packet transmission delay across the bottleneck
link. Thus, packet sizes and rate changes of the bottleneck link can
greatly impact the RTT. Paths across W-WANs fall into this category.
Apart from the mentioned delay spikes such links may also be subject
to rate changes by an order of magnitude (e.g. from 384 kb/s to 16
kb/s).
In this document, we suggest a more conservative management of TCP's
retransmit timer, and a more careful response of the TCP sender to
Gurtov & Ludwig [Page 2]
INTERNET-DRAFT TCP and Delay Spikes February, 2002
duplicate ACKs that arrive after a timeout. The former reduces the
risk of triggering spurious timeouts, while the latter eliminates
potentially unnecessary retransmits. Although, we believe that these
suggestions are permitted (although not explicitly) by RFC2581
[RFC2581] and RFC2988 [RFC2988], they do not seem to be widely known
nor deployed in existing TCP implementations. We therefore want to
make implementers aware of these choices. In addition, we believe
that these suggestions should be explicitly addressed when advancing
RFC2581 and RFC2988 further along the standards track. This document
is therefore aimed at becoming an informational document. Traces that
illustrate the recommendations in this document can be found in
[GU01b] and [GU01c].
2. Restarting the Retransmit Timer on DUPACKs
The general motivation for restarting the retransmit timer on DUPACKs
is that a TCP sender may not want to timeout as long as it still
receives feedback that segments are being delivered by the network.
In addition, DUPACKs may carry useful SACK information [RFC2018].
2.1 Restarting on DUPACKs Before DupThresh
The retransmit timer should be restarted for every DUPACK that
arrives before DupThresh is reached. The time until DupThresh has
been reached can be extensively long when a delay spikes occurs in
this phase of the connection. Restarting the timer on DUPACKs before
DupThresh increases the TCP sender's chance of receiving the DUPACK
that triggers the fast retransmit. This is particularly important if
the TCP sender uses the Limited Transmit algorithm [RFC3042]. This is
because with that algorithm and a small congestion window, the time
until DupThresh has been reached is commonly long even without a
delay spike.
2.2 Restarting on Fast Retransmit
The retransmit timer should be restarted when the fast retransmit is
sent. Although, many TCP implementations already do this (e.g., see
[WS95]), it is not explicitly recommended by RFC2988. However,
RFC2988 does recommend it for timeout-based retransmits. A fast
retransmit should not be treated differently from a timeout-based
retransmit in this respect. In both cases the ACK for the retransmit
should be given the same amount of time to return as for normal
transmits.
2.2 Restarting on DUPACKs After DupThresh
See Section 4.
Gurtov & Ludwig [Page 3]
INTERNET-DRAFT TCP and Delay Spikes February, 2002
3. Ignoring DUPACKs after a Timeout
A TCP sender should ignore DUPACKs that arrive after a timeout has
occurred. Despite a conservative retransit timer, delay spikes can
trigger spurious timeouts to occur during fast recovery. The proper
behavior in this case is to follow the timeout recovery procedure
described in [RFC2581]. However, a fairly common behavior among TCPs
is to use DUPACKs that arrive after a timeout to clock-out
retransmits of outstanding segments. This has been observed in the
following TCPs: FreeBSD4.1, various versions of Microsoft Windows,
and ns2 [GU01b] [GU01c]. In most cases those retransmits were
unnecessary. This can result into further misbehavior as the TCP
receiver generates further DUPACKs for the arriving duplicate
segments.
4. Open Research Issues
At the time of writing, we believe that restarting the retransmit
timer for every DUPACK that arrives after the DupThresh had been
reached is still a research issue. Advanced loss recovery schemes
have been proposed that account for the case when the fast retransmit
was lost [LK98]. The idea is to count DUPACKs and to retransmit the
fast retransmit when the first DUPACK returns that must correspond to
a new segment sent during the second half of fast recovery. Clearly,
on such multiple fast retransmits the congestion window should be
halved again. For such advanced loss recovery schemes, we believe
that the retransmit timer should also be restarted for every DUPACK
that arrives after the DupThresh had been reached. However, this is
still an open issue that we currently study.
5. Security Considerations
Security consideration for computing the retransmit timer are given
in RFC2988. There are do not seem to be additional security concerns
for recommendations given in this document.
Acknowledgments
Many thanks Mark Allman and Sally Floyd for discussions on the
contents of this document. Alexey Kuznetsov, Noritoshi Demizu, Farid
Khafizov provided valuable comments that contributed to this
document.
Gurtov & Ludwig [Page 4]
INTERNET-DRAFT TCP and Delay Spikes February, 2002
References
[RFC2581] M.Allman, V. Paxson, W. Stevens, TCP Congestion Control,
RFC 2581, April 1999.
[RFC3042] M. Allman, H. Balakrishnan, S. Floyd, Enhancing TCP's
Loss Recovery Using Limited Transmit, RFC 3042,
January 2001.
[GU01a] A. Gurtov, Effect of Delays on TCP Performance, In
Proceedings of IFIP Personal Wireless Communications,
August 2001.
[GU01b] A. Gurtov, Traces of TCP connections experiencing a delay
spike, http://www.cs.helsinki.fi/u/gurtov/tcp/,
January 2002.
[GU01c] A. Gurtov, Making TCP Robust Against Delay Spikes,
University of Helsinki, Department of Computer Science,
C-2001-53, http://www.cs.helsinki.fi/u/gurtov/papers/,
November 2001.
[Ina02] H. Inamura et al., TCP over 2.5G and 3G Wireless Networks,
work in progress, February 2002..
[Jac88] V. Jacobson, Congestion Avoidance and Control, In
Proceedings of ACM SIGCOMM'88, 1988.
[RFC1323] V. Jacobson, R. Braden, D. Borman, TCP Extensions for High
Performance, RFC 1323, May 1992.
[LK98] D. Lin, H. T. Kung, TCP Fast Recovery Strategies: Analysis
and Improvements, In Proceedings of IEEE INFOCOM 98,
March 1998.
[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.
[LM02] R. Ludwig, M. Meyer, The Eifel Detection Algorithm for TCP,
work in progress, February 2002.
[LG02] R. Ludwig, A. Gurtov, The Eifel Response Algorithm to
Spurious Timeouts in TCP, work in progress, February 2002.
[RFC2018] M.Mathis, J. Mahdavi, S. Floyd, A. Romanow, TCP Selective
Acknowledgement Options, RFC 2018, October 1996.
[RFC2988] V. Paxson, M. Allman, Computing TCP's Retransmission Timer,
RFC 2988, November 2000.
Gurtov & Ludwig [Page 5]
INTERNET-DRAFT TCP and Delay Spikes February, 2002
[RFC793] J. Postel, Transmission Control Protocol, RFC 793,
September 1981.
[WS95] G. R. Wright, W. R. Stevens, TCP/IP Illustrated, Volume 2
(The Implementation), Addison Wesley, January 1995.
Author's Address:
Andrei Gurtov
Sonera Corp.
Cellular Systems Development
P.O. Box 970, FIN-00051
Helsinki, Finland
Fax: +358(0)204064365
Tel: +358(0)20401
Email: andrei.gurtov@sonera.com
Homepage: http://www.cs.helsinki.fi/u/gurtov
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 August 2002.
Gurtov & Ludwig [Page 6]
