datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
RFC 3517

Document type: RFC - Proposed Standard (April 2003)
Obsoleted by RFC 6675
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3517 (Proposed Standard)
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

[include full document text]