A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
RFC 3517
| Document | Type |
RFC - Proposed Standard
(April 2003; No errata)
Obsoleted by RFC 6675
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3517 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Scott Bradner | ||
| Send notices to | <mankin@psg.com>, <jon.peterson@neustar.biz> | ||
Network Working Group E. Blanton
Request for Comments: 3517 Purdue University
Category: Standards Track M. Allman
BBN/NASA GRC
K. Fall
Intel Research
L. Wang
University of Kentucky
April 2003
A Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document presents a conservative loss recovery algorithm for TCP
that is based on the use of the selective acknowledgment (SACK) TCP
option. The algorithm presented in this document conforms to the
spirit of the current congestion control specification (RFC 2581),
but allows TCP senders to recover more effectively when multiple
segments are lost from a single flight of data.
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 BCP 14, RFC 2119
[RFC2119].
Blanton, et al. Standards Track [Page 1]
RFC 3517 SACK-based Loss Recovery for TCP April 2003
1 Introduction
This document presents a conservative loss recovery algorithm for TCP
that is based on the use of the selective acknowledgment (SACK) TCP
option. While the TCP SACK [RFC2018] is being steadily deployed in
the Internet [All00], there is evidence that hosts are not using the
SACK information when making retransmission and congestion control
decisions [PF01]. The goal of this document is to outline one
straightforward method for TCP implementations to use SACK
information to increase performance.
[RFC2581] allows advanced loss recovery algorithms to be used by TCP
[RFC793] provided that they follow the spirit of TCP's congestion
control algorithms [RFC2581, RFC2914]. [RFC2582] outlines one such
advanced recovery algorithm called NewReno. This document outlines a
loss recovery algorithm that uses the SACK [RFC2018] TCP option to
enhance TCP's loss recovery. The algorithm outlined in this
document, heavily based on the algorithm detailed in [FF96], is a
conservative replacement of the fast recovery algorithm [Jac90,
RFC2581]. The algorithm specified in this document is a
straightforward SACK-based loss recovery strategy that follows the
guidelines set in [RFC2581] and can safely be used in TCP
implementations. Alternate SACK-based loss recovery methods can be
used in TCP as implementers see fit (as long as the alternate
algorithms follow the guidelines provided in [RFC2581]). Please
note, however, that the SACK-based decisions in this document (such
as what segments are to be sent at what time) are largely decoupled
from the congestion control algorithms, and as such can be treated as
separate issues if so desired.
2 Definitions
The reader is expected to be familiar with the definitions given in
[RFC2581].
The reader is assumed to be familiar with selective acknowledgments
as specified in [RFC2018].
For the purposes of explaining the SACK-based loss recovery algorithm
we define four variables that a TCP sender stores:
"HighACK" is the sequence number of the highest byte of data that
has been cumulatively ACKed at a given point.
"HighData" is the highest sequence number transmitted at a given
point.
Blanton, et al. Standards Track [Page 2]
RFC 3517 SACK-based Loss Recovery for TCP April 2003
"HighRxt" is the highest sequence number which has been
retransmitted during the current loss recovery phase.
"Pipe" is a sender's estimate of the number of bytes outstanding
Show full document text