draft-ietf-tcpimpl-newreno-00.txt   draft-ietf-tcpimpl-newreno-01.txt 
Internet Engineering Task Force Sally Floyd Internet Engineering Task Force Sally Floyd
INTERNET DRAFT LBNL INTERNET DRAFT LBNL
draft-ietf-tcpimpl-newreno-00.txt Tom Henderson draft-ietf-tcpimpl-newreno-01.txt Tom Henderson
U.C. Berkeley U.C. Berkeley
November 1998 December 1998
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. 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
skipping to change at page 3, line 6 skipping to change at page 3, line 6
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 Reno's Fast Recovery algorithm, called NewReno, that incorporates
a response to partial acknowledgements received during Fast Recovery. a response to partial acknowledgements received during Fast Recovery.
This document does not discuss the other suggestions in [Hoe95] and 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. acknowledgements during Fast Recovery. The version of NewReno in
this document also draws on other discussions of NewReno in the
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
simulator [NS], we believe that this modification improves the simulator [NS], we believe that this modification improves the
performance of the Fast Retransmit and Fast Recovery algorithms in a performance of the Fast Retransmit and Fast Recovery algorithms in a
wide variety of scenarios, and we are simply documenting it for the wide variety of scenarios, and we are simply documenting it for the
benefit of the IETF community. We encourage the use of this benefit of the IETF community. We encourage the use of this
modification to Fast Recovery, and we further encourage feedback modification to Fast Recovery, and we further encourage feedback
skipping to change at page 4, line 20 skipping to change at page 4, line 22
receiver's advertised window. receiver's advertised window.
5. When an ACK arrives that acknowledges new data, this ACK could be 5. When an ACK arrives that acknowledges new data, this ACK could be
the acknowledgment elicited by the retransmission from step 2, or the acknowledgment elicited by the retransmission from step 2, or
elicited by a later retransmission. elicited by a later retransmission.
If this ACK acknowledges all of the data up to and including If this ACK acknowledges all of the data up to and including
"recover", then the ACK acknowledges all the intermediate "recover", then the ACK acknowledges all the intermediate
segments sent between the original transmission of the lost segments sent between the original transmission of the lost
segment and the receipt of the third duplicate ACK. Set cwnd to segment and the receipt of the third duplicate ACK. Set cwnd to
either (1) min (ssthresh, FlightSize + 1); or (2) ssthresh, where either (1) min (ssthresh, FlightSize + MSS); or (2) ssthresh,
ssthresh is the value set in step 1; this is termed "deflating" where ssthresh is the value set in step 1; this is termed
the window. (We note that "FlightSize" in step 1 referred to the "deflating" the window. (We note that "FlightSize" in step 1
amount of data outstanding in step 1, when Fast Recovery was referred to the amount of data outstanding in step 1, when Fast
entered, while "FlightSize" in step 5 refers to the amount of Recovery was entered, while "FlightSize" in step 5 refers to the
data outstanding in step 5, when Fast Recovery is exited.) If the amount of data outstanding in step 5, when Fast Recovery is
second option is selected, the implementation should take exited.) If the second option is selected, the implementation
measures to avoid a possible burst of data, in case the amount of should take measures to avoid a possible burst of data, in case
data outstanding in the network was much less than the new the amount of data outstanding in the network was much less than
congestion window allows [HTH98]. Clear the counter recording the new congestion window allows [HTH98]. Clear the counter
the number of duplicate acknowledgements, exiting the Fast recording the number of duplicate acknowledgements, exiting the
Recovery procedure. Fast Recovery procedure.
If this ACK does *not* acknowledge all of the data up to and If this ACK does *not* acknowledge all of the data up to and
including "recover", then this is a partial ACK. In this case, including "recover", then this is a partial ACK. In this case,
retransmit the first unacknowledged segment. Deflate the retransmit the first unacknowledged segment. Deflate the
congestion window by the amount of new data acknowledged, then congestion window by the amount of new data acknowledged, then
add back one MSS and send a new segment if permitted by the new add back one MSS and send a new segment if permitted by the new
value of cwnd. This "partial window deflation" attempts to value of cwnd. This "partial window deflation" attempts to
ensure that, when Fast Recovery eventually ends, approximately ensure that, when Fast Recovery eventually ends, approximately
ssthresh amount of data will be outstanding in the network. Do ssthresh amount of data will be outstanding in the network. Do
not clear the counter recording the number of duplicate not clear the counter recording the number of duplicate
skipping to change at page 9, line 35 skipping to change at page 9, line 37
NewReno algorithm, we have not explored all of these possible NewReno algorithm, we have not explored all of these possible
variations, and therefore are unable to make recommendations about variations, and therefore are unable to make recommendations about
some of them. Our belief is that the differences between any two some of them. Our belief is that the differences between any two
variants of NewReno are small compared to the differences between variants of NewReno are small compared to the differences between
Reno and NewReno. That is, the important thing is to implement Reno and NewReno. That is, the important thing is to implement
NewReno instead of Reno, for a TCP invocation without SACK; it is NewReno instead of Reno, for a TCP invocation without SACK; it is
less important exactly *which* variant of NewReno is implemented. less important exactly *which* variant of NewReno is implemented.
9. Acknowledgements 9. Acknowledgements
Many thanks to Mark Allman, Vern Paxson, and Kacheong Poon for Many thanks to Mark Allman, Vern Paxson, Kacheong Poon, and Bernie
detailed feedback on this document. Volz for detailed feedback on this document.
10. References 10. References
[C98] Neal Cardwell, "delayed ACKs for retransmitted packets: ouch!". [C98] Neal Cardwell, "delayed ACKs for retransmitted packets: ouch!".
November 1998. Email to the tcpimpl mailing list, Message-ID November 1998. Email to the tcpimpl mailing list, Message-ID
"Pine.LNX.4.02A.9811021421340.26785-100000@sake.cs.washington.edu", "Pine.LNX.4.02A.9811021421340.26785-100000@sake.cs.washington.edu",
archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl". archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl".
[F98] Sally Floyd. Revisions to RFC 2001. Presentation to the [F98] Sally Floyd. Revisions to RFC 2001. Presentation to the
TCPIMPL Working Group, August 1998. URLs TCPIMPL Working Group, August 1998. URLs
skipping to change at page 10, line 31 skipping to change at page 10, line 31
[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical [Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical
report, October 1994. URL report, October 1994. URL
"ftp://ftp.ee.lbl.gov/papers/fastretrans.ps". "ftp://ftp.ee.lbl.gov/papers/fastretrans.ps".
[Hen98] Tom Henderson, Re: NewReno and the 2001 Revision. September [Hen98] Tom Henderson, Re: NewReno and the 2001 Revision. September
1998. Email to the tcpimpl mailing list, Message ID 1998. Email to the tcpimpl mailing list, Message ID
"Pine.BSI.3.95.980923224136.26134A-100000@raptor.CS.Berkeley.EDU", "Pine.BSI.3.95.980923224136.26134A-100000@raptor.CS.Berkeley.EDU",
archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl". archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl".
[Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and [Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and
Avoidance Schemes. Master's Thesis, MIT, 1995. Avoidance Schemes. Master's Thesis, MIT, 1995. URL "http://ana-
www.lcs.mit.edu/anaweb/ps-papers/hoe-thesis.ps".
[Hoe96] J. Hoe, Improving the Start-up Behavior of a Congestion [Hoe96] J. Hoe, Improving the Start-up Behavior of a Congestion
Control Scheme for TCP. In ACM SIGCOMM, August 1996. Control Scheme for TCP. In ACM SIGCOMM, August 1996. URL
"http://www.acm.org/sigcomm/sigcomm96/program.html".
[HTH98] A. Hughes, J. Touch, J. Heidemann, Issues in TCP Slow-Start [HTH98] A. Hughes, J. Touch, J. Heidemann, Issues in TCP Slow-Start
Restart After Idle, Internet Draft draft-ietf-tcpimpl-restart-00.txt, Restart After Idle, Work in progress, March 1998.
March 1998.
[LM97] Dong Lin and Robert Morris, "Dynamics of Random Early
Detection", SIGCOMM 97, September 1997. URL
"http://www.acm.org/sigcomm/sigcomm97/program.html".
[MMFR96] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective [MMFR96] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective
Acknowledgement Options", RFC 2018, October 1996. Acknowledgement Options", RFC 2018, October 1996.
[NS] The UCB/LBNL/VINT Network Simulator (NS). URL "http://www- [NS] The UCB/LBNL/VINT Network Simulator (NS). URL "http://www-
mash.cs.berkeley.edu/ns/". mash.cs.berkeley.edu/ns/".
[RFC2001] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast [RFC2001] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997.
skipping to change at page 11, line 28 skipping to change at page 11, line 31
Phone: +1 (510) 486-7518 Phone: +1 (510) 486-7518
Email: floyd@ee.lbl.gov Email: floyd@ee.lbl.gov
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 November 1998. This draft was created in December 1998.
It expires June 1999. It expires June 1999.
 End of changes. 9 change blocks. 
22 lines changed or deleted 29 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/