Browse Prior Art Database

The NewReno Modification to TCP's Fast Recovery Algorithm (RFC2582)

IP.com Disclosure Number: IPCOM000003169D
Original Publication Date: 1999-Apr-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 12 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Floyd: AUTHOR [+1]

Related Documents

10.17487/RFC2582: DOI

Abstract

This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This memo defines an Experimental Protocol for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 12% of the total text.

Network Working Group S. Floyd Request for Comments: 2582 ACIRI Category: Experimental T. Henderson U.C. Berkeley April 1999

The NewReno Modification to TCP’s Fast Recovery Algorithm

Status of this Memo

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95].

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 Reno Fast Retransmit algorithm leads to the retransmission of only a single data packet.

Floyd & Henderson Experimental [Page 1]

RFC 2582 NewReno Modification to TCP’s Fast Recovery April 1999

Problems can arise, therefore, when multiple packets have been 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.

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...

Processing...
Loading...