Internet DRAFT - draft-blanton-dupack-thresh-adjust
draft-blanton-dupack-thresh-adjust
Internet Engineering Task Force Ethan Blanton
INTERNET DRAFT Ohio University
File: draft-blanton-dupack-thresh-adjust-00.txt Mark Allman
BBN/NASA GRC
July, 2001
Expires: January, 2002
Adjusting the Duplicate ACK Threshold to Avoid
Spurious Retransmits
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 to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document outlines steps TCP and SCTP senders can take after the
determine that a spurious retransmission has been sent to revert a
needless change of the congestion control state. In addition, we
present several methods to prevent or mitigate unnecessary TCP and
SCTP fast retransmits in the face of segment reordering.
Terminology
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].
1 Introduction
The TCP or SCTP fast retransmit mechanism can be triggered by the
reordering of packets in the network even in no-loss situations
[BA01a,BPS99]. This document presents several mechanisms to prevent
or mitigate these unnecessary fast retransmits caused by reordering.
This document is not intended to describe every possible approach to
the problem; on the contrary, it aims to outline a few potential
Expires: January 2002 [Page 1]
draft-blanton-dupack-thresh-adjust-00.txt July 2001
algorithms in order to spur further interest and research on the
subject.
The problem of detecting unnecessary retransmissions and
disambiguating reordering from loss is outside the scope of this
document, although some reliable method of doing this is required.
[BA01b] and [Lud00] present such algorithms.
2 Definitions
It is assumed that the reader is familiar with the congestion
control concepts and terminology in [RFC2581] for TCP and/or
[RFC2960] for SCTP.
In addition, the following terms will be used:
``dupthresh'' represents the number of duplicate ACKs (or
SACKs in the case of SCTP) required to trigger a fast
retransmit.
3 Reverting Congestion Control State
[RFC2883,LK00] both mention the possibility of reverting congestion
control state when a sender determines that the congestion window
was reduced unnecessarily due to a spurious retransmission. This
document specifies that a sender that reliably detects a spurious
retransmission MAY ``undo'' the needless congestion control state
changes using the following algorithm:
(1) When retransmitting a segment and before reducing cwnd, save
the value of cwnd as cwnd_prev.
(2) Upon the detection of a spurious retransmit, set ssthresh to
cwnd_prev.
This causes a 1 RTT slow start back to the cwnd state held before
the sender needlessly made changes to the congestion control
state. Furthermore, using the above algorithm causes a smooth
increase of cwnd, whereas simply setting cwnd to cwnd_prev upon
detection of a spurious retransmit would cause the transmission
of a potentially large burst.
If a sender uses the above algorithm, one of the algorithms
specified in the next section MUST be used in an attempt to prevent
further needless retransmissions.
4 Preventing Spurious Retransmits
[Editor's Note: The descriptions of the algorithms in this section
are necessrily terse -- the I-D deadline being near. These
subsections will be filled out more in future revisions of this
document.]
4.1 Increase dupthresh by some constant
Expires: January 2002 [Page 2]
draft-blanton-dupack-thresh-adjust-00.txt July 2001
A very simple approach is to increase dupthresh by some small
constant each time a spurious fast retransmit is detected.
4.2 Increase dupthresh by some factor dependent on the reordering
Taking the length of the reordering event that caused a spurious
fast retransmit into consideration, dupthresh can be increased to
some value large enough to have prevented this spurious
retransmission.
4.3 Delayed fast retransmit
As proposed in [Pax97], the fast retransmit can be delayed by some
small amount of time after dupthresh duplicate ACKs have been
received. When an unnecessary fast retransmit is detected, this
delay can be increased by a small amount that would have been
sufficient to prevent the spurious retransmission.
4.4 Average duplicate ACK count tracking
If the average number of duplicate ACKs received during a
reordering event is tracked, then dupthresh can be set to some
function of this value in order to minimize false retransmits.
5 Future Work
In addition to changing the duplicate ACK treshold this document
will eventually outline mechanisms for adjusting the retransmission
timeout when the RTO is firing prematurly.
6 Security Considerations
Reversion of congestion control state and adjustment of the
duplicate ACK threshold themselves have no obvious security
considerations. Any security considerations pertaining to the
method of determining that a fast retransmit was spurious are
directly applicable to this document. Reversion of congestion
control state depends on an accurate indication that the
retransmission was spurious to prevent the intentional disabling
of congestion control.
Acknowledgments
The authors would like to thank Sally Floyd, Reiner Ludwig, Vern
Paxson and Randall Stewart for spurring this work through their
previous work for providing input during the formative stages of
this draft.
References
[BA01a] E. Blanton, M. Allman. On Making TCP More Robust to Packet
Reordering. In preparation.
Expires: January 2002 [Page 3]
draft-blanton-dupack-thresh-adjust-00.txt July 2001
[BA01b] E. Blanton, M. Allman. Using TCP DSACKs and SCTP Duplicate
TSNs to Detect Spurious Retransmissions. Internet-Draft
draft-blanton-dsack-use-00.txt, July 2001. Work in progress.
[BPS99] J. Bennett, C. Partridge, N. Shectman. Packet Reordering
is Not Pathological Network Behavior. IEEE/ACM Transactions
on Networking, December 1999.
[LK00] R. Ludwig, R. Katz. The Eifel Algorithm: Making TCP Robust
Against Spurious Retransmissions. Computer Communication Review
Volume 30 Number 1, January 2000.
[Lud00] R. Ludwig. The Eifel Algorithm for TCP.
draft-ietf-tsvwg-tcp-eifel-alg-00.txt, February 2001. Work in
progress.
[Pax97] V. Paxson. End-to-End Internet Packet Dynamics.
Presented at ACM SIGCOMM, September 1997.
[RFC2581] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control,
RFC 2581, April 1999.
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.
Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V.
Paxson. Stream Control Transmission Protocol. RFC 2960,
October 2000.
Authors' Addresses:
Ethan Blanton
Ohio University Internetworking Research Lab
Stocker Center
Athens, OH 45701
eblanton@irg.cs.ohiou.edu
Mark Allman
BBN Technologies/NASA Glenn Research Center
Lewis Field
21000 Brookpark Rd. MS 54-5
Cleveland, OH 44135
Phone: 216-433-6586
Fax: 216-433-8705
mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Expires: January 2002 [Page 4]
