Internet DRAFT - draft-blanton-dsack-use
draft-blanton-dsack-use
Internet Engineering Task Force Ethan Blanton
INTERNET DRAFT Ohio University
File: draft-blanton-dsack-use-01.txt Mark Allman
BBN/NASA GRC
August, 2001
Expires: February, 2002
Using TCP DSACKs and SCTP Duplicate TSNs
to Detect Spurious Retransmissions
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
TCP and SCTP provide notification of duplicate segment receipt
through DSACK and Duplicate TSN notification, respectively. This
document presents a conservative method of using this information
to identify unnecessary retransmissions.
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
TCP [RFC793] and SCTP [RFC2960] provide notification of duplicate
segment receipt through DSACK [RFC2883] and Duplicate TSN
notifications, respectively. Using this information, a TCP or SCTP
sender can generally determine when a retransmission was sent in
error. This document presents a conservative algorithm to
disambiguate unnecessary retransmissions from loss events.
While DSACKs and duplicate TSN notifications can be caused by
segments being duplicated by the network, [Pax97] shows this is
Expires: February 2002 [Page 1]
draft-blanton-dsack-use-01.txt August 2001
exceedingly rare. Some network paths may exhibit this problem
more than others, but we do not believe it to be a general
problem. Therefore the algorithm presented in this document is
disabled when duplication of segments by the network is detected.
This document is intended to outline a reasonable and safe
algorithm for detecting spurious retransmissions and discuss some
of the considerations involved. It is not intended to describe
the only possible method for achieving this goal, although some of
the guidelines in this document should be taken into consideration
when designing an alternate algorithm. Additionally, this
document does not outline what a TCP or SCTP sender may do after
a spurious retransmission is detected. Some possibilities are
mentioned in [RFC2883], such as reverting changes made to the
congestion control state. Discussion of this topic is left
to a companion document that makes no assumptions about the manner
in which spurious retransmissions are detected [BA01b].
2 The Algorithm
The complexity of the algorithm used for detecting spurious
retransmits depends on the purpose in determining this information.
For instance, if a sender is only interested in keeping a count of
the number of spurious retransmits the information can be derived
directly from the returning DSACK or duplicate TSN notifications.
However, if the purpose of detecting spurious retransmissions is to
``undo'' unnecessary changes made to the congestion control state,
as suggested in [RFC2883], the data sender needs to ensure that all
retransmissions in a particular window of data were spurious before
reverting the congestion control state. In other words, we must
ensure that DSACKs (or duplicate TSN notifications) do not mask real
loss.
For example, say segments N and N+1 are retransmitted. Assume that
segment N was dropped by the network and segment N+1 was needlessly
retransmitted. When the sender receives the notification that
segment N+1 arrived more than once it can conclude that segment N+1
was needlessly resent. However, it cannot conclude that it is
appropriate to revert the congestion control state because the
window of data contained at least one real congestion indication
(i.e., segment N was lost).
The following algorithm ensures that all retransmissions sent in a
particular window were, in fact, needless. The following steps MUST
be taken upon the receipt of each DSACK or duplicate TSN
notification:
(A) Check the corresponding sequence range or TSN to determine
if it has been retransmitted.
(A.1) If it was retransmitted, mark it as a duplicate.
(A.2) If not, this DSACK indicates that the network duplicated
Expires: February 2002 [Page 2]
draft-blanton-dsack-use-01.txt August 2001
the segment in question. Processing of this DSACK MUST be
terminated. In addition, the algorithm specified in this
document MUST NOT be used for the remainder of the
connection, as future DSACK reports may be indicating
network duplication rather than unnecessary retransmission.
Note that some techniques to further disambiguate network
duplication from unnecessary retransmission (e.g., the TCP
timestamp option [RFC1323]) may be used to refine the
algorithm in this document further. Using such a technique
in conjunction with an algorithm similar to the one
presented herein may allow for the continued use of the
algorithm in the face of duplicated segments. We do not
delve into such an algorithm in this document due the
current rarity of network duplication. However, future work
should include tackling this problem.
(B) Check all retransmitted segments in the previous window of
data.
(B.1) If all segments or chunks marked as retransmitted have
also been marked as duplicate, we conclude that all
retransmissions in the previous window of data were spurious
and no loss occurred.
(B.2) If any segment or chunk is still marked as retransmitted
but not marked as duplicate, there are outstanding
retransmissions that could indicate loss within this window
of data. We can make no conclusions based on this
particular DSACK/duplicate TSN notification.
In addition to keeping the state mentioned in [BA01a] (for TCP) and
[RFC2960] (for SCTP), an implementation of this algorithm must track
all sequence numbers or TSNs that have been acknowledged as
duplicates.
3 Security Considerations
It is possible for the receiver to falsely indicate spurious
retransmissions in the case of actual loss, potentially causing a
TCP or SCTP sender to inaccurately conclude that no loss took place
(and cause inappropriate changes to the senders congestion control
state). Consider the following scenario:
A receiver watches every segment or chunk that arrives and
acknowledges any segment that arrives out of order by more than
some threshold amount as a duplicate, assuming that it is a
retransmission. A sender using the above algorithm will assume
that the retransmission was spurious.
As a more trivial example, a receiver could simply acknowledge
every segment or chunk received as a duplicate as they arrive.
This approach is more easily defeated by heuristics, but would
nonetheless cause the algorithm in this document to come to
an incorrect conclusion.
Expires: February 2002 [Page 3]
draft-blanton-dsack-use-01.txt August 2001
The ECN nonce sum proposal [WES01] would help mitigate the ability
of the receiver to hide real losses from the sender.
References
[BA01a] E. Blanton, M. Allman. A Conservative SACK-based Loss
Recovery Algorithm for TCP. Internet-Draft
draft-allman-tcp-sack-06.txt, July 2001. Work in progress.
[BA01b] E. Blanton, M. Allman. Adjusting the Duplicate ACK
fThreshold to Avoid Spurious Retransmits. Internet-Draft
draft-blanton-tcp-dupack-thresh-adjust-00.txt, July 2001.
Work in progress.
[FF99] S. Floyd, K. Fall. Promoting the Use of End-to-End
Congestion Control on the Internet. IEEE/ACM Transactions
on Networking, August 1999.
[Pax97] V. Paxson. End-to-End Internet Packet Dynamics. In ACM
SIGCOMM, September 1997.
[RFC793] Jon Postel. Transmission Control Protocol. Std 7, RFC
793. September 1981.
[RFC1323] Van Jacobson, Robert Braden, David Borman. TCP Extensions
for High Performance. RFC 1323. May 1992.
[RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. An
Extension to the Selective Acknowledgement (SACK) Option for
TCP. RFC 2883, July 2000.
[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. October 2000.
[WES00] D. Wetherall, D. Ely, N. Spring. Robust ECN Signaling with
Nonces. Internet-Draft draft-ietf-tsvwg-tcp-nonce-00.txt,
January 2001. Work in progress.
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
Expires: February 2002 [Page 4]
draft-blanton-dsack-use-01.txt August 2001
Fax: 216-433-8705
mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Expires: February 2002 [Page 5]
