draft-ietf-tcpimpl-newreno-01.txt   draft-ietf-tcpimpl-newreno-02.txt 
Internet Engineering Task Force Sally Floyd Internet Engineering Task Force Sally Floyd
INTERNET DRAFT LBNL INTERNET DRAFT ACIRI
draft-ietf-tcpimpl-newreno-01.txt Tom Henderson draft-ietf-tcpimpl-newreno-02.txt Tom Henderson
U.C. Berkeley U.C. Berkeley
December 1998 February 1999
Expires: August 1999
The NewReno Modification to TCP's Fast Recovery Algorithm The NewReno Modification to TCP's Fast Recovery Algorithm
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
skipping to change at page 2, line 8 skipping to change at page 2, line 8
option [MMFR96], and modifications that respond to ``partial option [MMFR96], and modifications that respond to ``partial
acknowledgments'' (ACKs which cover new data, but not all the data acknowledgments'' (ACKs which cover new data, but not all the data
outstanding when loss was detected) in the absence of SACK. This outstanding when loss was detected) in the absence of SACK. This
document describes a specific algorithm for responding to partial document describes a specific algorithm for responding to partial
acknowledgments, referred to as NewReno. This response to partial acknowledgments, referred to as NewReno. This response to partial
acknowledgments was first proposed by Janey Hoe in [Hoe95]. acknowledgments was first proposed by Janey Hoe in [Hoe95].
1. Introduction 1. Introduction
For the typical implementation of the TCP Fast Recovery algorithm For the typical implementation of the TCP Fast Recovery algorithm
described in [RFC2001-bis] (and illustrated as the Reno described in [RFC2001-bis] (first implemented in the 1990 BSD Reno
implementation in [FF96]), the TCP data sender only retransmits a release, and referred to as the Reno algorithm in [FF96]), the TCP
packet after a retransmit timeout has occurred, or after three data sender only retransmits a packet after a retransmit timeout has
duplicate acknowledgements have arrived triggering the Fast occurred, or after three duplicate acknowledgements have arrived
Retransmit algorithm. A single retransmit timeout might result in triggering the Fast Retransmit algorithm. A single retransmit
the retransmission of several data packets, but each invocation of timeout might result in the retransmission of several data packets,
the Reno Fast Retransmit algorithm leads to the retransmission of but each invocation of the Reno Fast Retransmit algorithm leads to
only a single data packet. the retransmission of only a single data packet.
Problems can arise, therefore, when multiple packets have been Problems can arise, therefore, when multiple packets have been
dropped from a single window of data and the Fast Retransmit and Fast 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 Recovery algorithms are invoked. In this case, if the SACK option is
available, the TCP sender has the information to make intelligent available, the TCP sender has the information to make intelligent
decisions about which packets to retransmit and which packets not to decisions about which packets to retransmit and which packets not to
retransmit during Fast Recovery. This document applies only for TCP retransmit during Fast Recovery. This document applies only for TCP
connections that are unable to use the TCP Selective Acknowledgement connections that are unable to use the TCP Selective Acknowledgement
(SACK) option. (SACK) option.
skipping to change at page 2, line 50 skipping to change at page 2, line 50
Fast Retransmit was entered (in the absence of reordering). However, Fast Retransmit was entered (in the absence of reordering). However,
when there were multiple packet drops, then the acknowledgement for when there were multiple packet drops, then the acknowledgement for
the retransmitted packet will acknowledge some but not all of the the retransmitted packet will acknowledge some but not all of the
packets transmitted before the Fast Retransmit. We call this packet packets transmitted before the Fast Retransmit. We call this packet
a partial acknowledgment. a partial acknowledgment.
Along with several other suggestions, [Hoe95] suggested that during Along with several other suggestions, [Hoe95] suggested that during
Fast Recovery the TCP data sender respond to a partial acknowledgment Fast Recovery the TCP data sender respond to a partial acknowledgment
by inferring that the indicated packet has been lost, and by inferring that the indicated packet has been lost, and
retransmitting that packet. This document describes a modification retransmitting that packet. This document describes a modification
to Reno's Fast Recovery algorithm, called NewReno, that incorporates to the Fast Recovery algorithm in Reno TCP that incorporates a
a response to partial acknowledgements received during Fast Recovery. response to partial acknowledgements received during Fast Recovery.
This document does not discuss the other suggestions in [Hoe95] and We call this modified Fast Recovery algorithm NewReno, because it is
a slight but significant variation of the basic Reno algorithm. This
document does not discuss the other suggestions in [Hoe95] and
[Hoe96], such as a change to the ssthresh parameter during Slow- [Hoe96], such as a change to the ssthresh parameter during Slow-
Start, or the proposal to send a new packet for every two duplicate Start, or the proposal to send a new packet for every two duplicate
acknowledgements during Fast Recovery. The version of NewReno in acknowledgements during Fast Recovery. The version of NewReno in
this document also draws on other discussions of NewReno in the this document also draws on other discussions of NewReno in the
literature [LM97]. literature [LM97].
We do not claim that the NewReno version of Fast Recovery described We do not claim that the NewReno version of Fast Recovery described
here is an optimal modification of Fast Recovery for responding to here is an optimal modification of Fast Recovery for responding to
partial acknowledgements, for TCPs that are unable to use SACK. partial acknowledgements, for TCPs that are unable to use SACK.
Based on our experiences with the NewReno modification in the NS Based on our experiences with the NewReno modification in the NS
skipping to change at page 8, line 32 skipping to change at page 8, line 34
of SACK, the TCP sender in unable to distinguish between these two of SACK, the TCP sender in unable to distinguish between these two
scenarios. scenarios.
For the Careful variant of Fast Retransmit, the data sender would For the Careful variant of Fast Retransmit, the data sender would
have to wait for a retransmit timeout in the first scenario, but have to wait for a retransmit timeout in the first scenario, but
would not have an unnecessary Fast Retransmit in the second scenario. would not have an unnecessary Fast Retransmit in the second scenario.
For the Less Careful variant to Fast Retransmit, the data sender For the Less Careful variant to Fast Retransmit, the data sender
would Fast Retransmit as desired in the first scenario, and would would Fast Retransmit as desired in the first scenario, and would
unnecessarily Fast Retransmit in the second scenario. The NS unnecessarily Fast Retransmit in the second scenario. The NS
simulator has implemented the Less Careful variant of NewReno, and simulator has implemented the Less Careful variant of NewReno, and
the TCP implementation in Solaris 7 implements the Careful variant. the TCP implementation in Sun's Solaris 7 implements the Careful
The document recommends the Careful variant given in Step 1A above. variant. This document recommends the Careful variant given in Step
1A above.
6. Implementation issues for the data receiver. 6. Implementation issues for the data receiver.
[RFC2001] specifies that "Out-of-order data segments SHOULD be [RFC2001] specifies that "Out-of-order data segments SHOULD be
acknowledged immediately, in order to trigger the fast retransmit acknowledged immediately, in order to trigger the fast retransmit
algorithm." Neal Cardwell has noted [C98] that some data receivers do algorithm." Neal Cardwell has noted [C98] that some data receivers do
not send an immediate acknowledgement when they send a partial not send an immediate acknowledgement when they send a partial
acknowledgment, but instead wait first for their delayed acknowledgment, but instead wait first for their delayed
acknowledgement timer to expire. As [C98] notes, this severely acknowledgement timer to expire. As [C98] notes, this severely
limits the potential benefit from NewReno by delaying the receipt of limits the potential benefit from NewReno by delaying the receipt of
skipping to change at page 11, line 20 skipping to change at page 11, line 20
RFC 2001-bis discusses general security considerations concerning TCP RFC 2001-bis discusses general security considerations concerning TCP
congestion control. This document describes a specific algorithm congestion control. This document describes a specific algorithm
that conforms with the congestion control requirements of RFC that conforms with the congestion control requirements of RFC
2001-bis, and so those considerations apply to this algorithm, too. 2001-bis, and so those considerations apply to this algorithm, too.
There are no known additional security concerns for this specific There are no known additional security concerns for this specific
algorithm. algorithm.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Sally Floyd Sally Floyd
Lawrence Berkeley National Laboratory AT&T Center for Internet Research at ICSI (ACIRI)
Phone: +1 (510) 486-7518 Phone: +1 (510) 642-4274 x189
Email: floyd@ee.lbl.gov Email: floyd@acm.org
URL: http://www-nrg.ee.lbl.gov/floyd/ URL: http://www-nrg.ee.lbl.gov/floyd/
Tom Henderson Tom Henderson
University of California at Berkeley University of California at Berkeley
Phone: +1 (510) 642-8919 Phone: +1 (510) 642-8919
Email: tomh@cs.berkeley.edu Email: tomh@cs.berkeley.edu
URL: http://www.cs.berkeley.edu/~tomh/ URL: http://www.cs.berkeley.edu/~tomh/
This draft was created in December 1998. This draft was created in February 1999.
It expires June 1999. It expires August 1999.
 End of changes. 8 change blocks. 
20 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/