datatracker.ietf.org
Sign in
Version 5.8.1, 2014-12-18
Report a bug

The NewReno Modification to TCP's Fast Recovery Algorithm
RFC 3782

Document type: RFC - Proposed Standard (April 2004; Errata)
Obsoleted by RFC 6582
Obsoletes RFC 2582
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 3782 (Proposed Standard)
Responsible AD: Jon Peterson
Send notices to: No addresses provided

Network Working Group                                           S. Floyd
Request for Comments: 3782                                          ICSI
Obsoletes: 2582                                             T. Henderson
Category: Standards Track                                         Boeing
                                                               A. Gurtov
                                                             TeliaSonera
                                                              April 2004

       The NewReno Modification to TCP's Fast Recovery Algorithm

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 (2004).  All Rights Reserved.

Abstract

   The purpose of this document is to advance NewReno TCP's  Fast
   Retransmit and Fast Recovery algorithms in RFC 2582 from Experimental
   to Standards Track status.

   The main change in this document relative to RFC 2582 is to specify
   the Careful variant of NewReno's Fast Retransmit and Fast Recovery
   algorithms.  The base algorithm described in RFC 2582 did not attempt
   to avoid unnecessary multiple Fast Retransmits that can occur after a
   timeout.  However, RFC 2582 also defined "Careful" and "Less Careful"
   variants that avoid these unnecessary Fast Retransmits, and
   recommended the Careful variant.  This document specifies the
   previously-named "Careful" variant as the basic version of NewReno
   TCP.

Floyd, et al.               Standards Track                     [Page 1]
RFC 3782    NewReno Modification to Fast Recovery Algorithm   April 2004

1.  Introduction

   For the typical implementation of the TCP Fast Recovery algorithm
   described in [RFC2581] (first implemented in the 1990 BSD Reno
   release, and referred to as the Reno algorithm in [FF96]), the TCP
   data sender only retransmits a packet after a retransmit timeout has
   occurred, or after three duplicate acknowledgements have arrived
   triggering the Fast Retransmit algorithm.  A single retransmit
   timeout might result in the retransmission of several data packets,
   but each invocation of the Fast Retransmit algorithm in RFC 2581
   leads to the retransmission of only a single data packet.

   Problems can arise, therefore, when multiple packets are dropped from
   a single window of data and the Fast Retransmit and Fast Recovery
   algorithms are invoked.  In this case, if the SACK option is
   available, the TCP sender has the information to make intelligent
   decisions about which packets to retransmit and which packets not to
   retransmit during Fast Recovery.  This document applies only for TCP
   connections that are unable to use the TCP Selective Acknowledgement
   (SACK) option, either because the option is not locally supported or
   because the TCP peer did not indicate a willingness to use SACK.

   In the absence of SACK, there is little information available to the
   TCP sender in making retransmission decisions during Fast Recovery.
   From the three duplicate acknowledgements, the sender infers a packet
   loss, and retransmits the indicated packet.  After this, the data
   sender could receive additional duplicate acknowledgements, as the
   data receiver acknowledges additional data packets that were already
   in flight when the sender entered Fast Retransmit.

   In the case of multiple packets dropped from a single window of data,
   the first new information available to the sender comes when the
   sender receives an acknowledgement for the retransmitted packet (that
   is, the packet retransmitted when Fast Retransmit was first entered).
   If there is a single packet drop and no reordering, then the
   acknowledgement for this packet will acknowledge all of the packets
   transmitted before Fast Retransmit was entered.  However, if there
   are multiple packet drops, then the acknowledgement for the
   retransmitted packet will acknowledge some but not all of the packets
   transmitted before the Fast Retransmit.  We call this acknowledgement
   a partial acknowledgment.

   Along with several other suggestions, [Hoe95] suggested that during
   Fast Recovery the TCP data sender responds to a partial
   acknowledgment by inferring that the next in-sequence packet has been
   lost, and retransmitting that packet.  This document describes a
   modification to the Fast Recovery algorithm in RFC 2581 that
   incorporates a response to partial acknowledgements received during

[include full document text]