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
|
|
---|---|---|---|
Authors | Lili Wang , Mark Allman , Ethan Blanton , Kevin Fall | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3517 (Proposed Standard) | |
Action Holders |
(None)
|
||
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 in the network. This is used during recovery for limiting the sender's sending rate. The pipe variable allows TCP to use a fundamentally different congestion control than specified in [RFC2581]. The algorithm is often referred to as the "pipe algorithm". For the purposes of this specification we define a "duplicateShow full document text