draft-ietf-tcpimpl-newreno-02.txt   rfc2582.txt 
Internet Engineering Task Force Sally Floyd Network Working Group S. Floyd
INTERNET DRAFT ACIRI Request for Comments: 2582 ACIRI
draft-ietf-tcpimpl-newreno-02.txt Tom Henderson Category: Experimental T. Henderson
U.C. Berkeley U.C. Berkeley
February 1999 April 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 and is in full conformance with This memo defines an Experimental Protocol for the Internet
all provisions of Section 10 of RFC2026. Internet-Drafts are working community. It does not specify an Internet standard of any kind.
documents of the Internet Engineering Task Force (IETF), its areas, Discussion and suggestions for improvement are requested.
and its working groups. Note that other groups may also distribute Distribution of this memo is unlimited.
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the Copyright (C) The Internet Society (1999). All Rights Reserved.
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
RFC 2001 [RFC2001] documents the following four intertwined TCP RFC 2001 [RFC2001] documents the following four intertwined TCP
congestion control algorithms: Slow Start, Congestion Avoidance, Fast congestion control algorithms: Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery. RFC 2001-bis [RFC2001-bis] explicitly Retransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows
allows certain modifications of these algorithms, including certain modifications of these algorithms, including modifications
modifications that use the TCP Selective Acknowledgement (SACK) that use the TCP Selective Acknowledgement (SACK) option [MMFR96],
option [MMFR96], and modifications that respond to ``partial and modifications that respond to "partial acknowledgments" (ACKs
acknowledgments'' (ACKs which cover new data, but not all the data which cover new data, but not all the data outstanding when loss was
outstanding when loss was detected) in the absence of SACK. This detected) in the absence of SACK. This document describes a specific
document describes a specific algorithm for responding to partial algorithm for responding to partial acknowledgments, referred to as
acknowledgments, referred to as NewReno. This response to partial NewReno. This response to partial acknowledgments was first proposed
acknowledgments was first proposed by Janey Hoe in [Hoe95]. 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] (first implemented in the 1990 BSD Reno described in [RFC2581] (first implemented in the 1990 BSD Reno
release, and referred to as the Reno algorithm in [FF96]), the TCP release, and referred to as the Reno algorithm in [FF96]), the TCP
data sender only retransmits a packet after a retransmit timeout has data sender only retransmits a packet after a retransmit timeout has
occurred, or after three duplicate acknowledgements have arrived occurred, or after three duplicate acknowledgements have arrived
triggering the Fast Retransmit algorithm. A single retransmit triggering the Fast Retransmit algorithm. A single retransmit
timeout might result in the retransmission of several data packets, timeout might result in the retransmission of several data packets,
but each invocation of the Reno Fast Retransmit algorithm leads to but each invocation of the Reno Fast Retransmit algorithm leads to
the retransmission of 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
skipping to change at page 3, line 27 skipping to change at page 3, line 15
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
about operational experiences with this or related modifications. about operational experiences with this or related modifications.
2. Definitions 2. Definitions
This document assumes that the reader is familiar with the terms This document assumes that the reader is familiar with the terms
MAXIMUM SEGMENT SIZE (MSS), CONGESTION WINDOW (cwnd), and FLIGHT SIZE MAXIMUM SEGMENT SIZE (MSS), CONGESTION WINDOW (cwnd), and FLIGHT SIZE
(FlightSize) defined in [RFC2001-bis]. FLIGHT SIZE is defined as in (FlightSize) defined in [RFC2581]. FLIGHT SIZE is defined as in
[RFC2001-bis] as follows: [RFC2581] as follows:
FLIGHT SIZE: FLIGHT SIZE:
The amount of data that has been sent but not yet The amount of data that has been sent but not yet acknowledged.
acknowledged.
3. The Fast Retransmit and Fast Recovery algorithms in NewReno 3. The Fast Retransmit and Fast Recovery algorithms in NewReno
The standard implementation of the Fast Retransmit and Fast Recovery The standard implementation of the Fast Retransmit and Fast Recovery
algorithms is given in [RFC2001-bis]. The NewReno modification of algorithms is given in [RFC2581]. The NewReno modification of these
these algorithms is given below. This NewReno modification differs algorithms is given below. This NewReno modification differs from
from the implementation in [RFC2001-bis] only in the introduction of the implementation in [RFC2581] only in the introduction of the
the variable "recover" in step 1, and in the response to a partial or variable "recover" in step 1, and in the response to a partial or new
new acknowledgement in step 5. acknowledgement in step 5. The modification defines a "Fast Recovery
procedure" that begins when three duplicate ACKs are received and
ends when either a retransmission timeout occurs or an ACK arrives
that acknowledges all of the data up to and including the data that
was outstanding when the Fast Recovery procedure began.
1. When the third duplicate ACK is received, set ssthresh to no 1. When the third duplicate ACK is received and the sender is not
more than the value given in equation 1 below. (This is already in the Fast Recovery procedure, set ssthresh to no more
equation 3 from [RFC2001-bis]). than the value given in equation 1 below. (This is equation 3
from [RFC2581]).
ssthresh = max (FlightSize / 2, 2*MSS) (1) ssthresh = max (FlightSize / 2, 2*MSS) (1)
Record the highest sequence number transmitted in the Record the highest sequence number transmitted in the variable
variable "recover". "recover".
2. Retransmit the lost segment and set cwnd to ssthresh plus 3*MSS. 2. Retransmit the lost segment and set cwnd to ssthresh plus 3*MSS.
This artificially "inflates" the congestion window by the number This artificially "inflates" the congestion window by the number
of segments (three) that have left the network and which the of segments (three) that have left the network and which the
receiver has buffered. receiver has buffered.
3. For each additional duplicate ACK received, increment cwnd by 3. For each additional duplicate ACK received, increment cwnd by
MSS. This artificially inflates the congestion window in order MSS. This artificially inflates the congestion window in order
to reflect the additional segment that has left the network. to reflect the additional segment that has left the network.
skipping to change at page 4, line 34 skipping to change at page 4, line 25
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 + MSS); or (2) ssthresh, either (1) min (ssthresh, FlightSize + MSS); or (2) ssthresh,
where ssthresh is the value set in step 1; this is termed where ssthresh is the value set in step 1; this is termed
"deflating" the window. (We note that "FlightSize" in step 1 "deflating" the window. (We note that "FlightSize" in step 1
referred to the amount of data outstanding in step 1, when Fast referred to the amount of data outstanding in step 1, when Fast
Recovery was entered, while "FlightSize" in step 5 refers to the Recovery was entered, while "FlightSize" in step 5 refers to the
amount of data outstanding in step 5, when Fast Recovery is amount of data outstanding in step 5, when Fast Recovery is
exited.) If the second option is selected, the implementation exited.) If the second option is selected, the implementation
should take measures to avoid a possible burst of data, in case should take measures to avoid a possible burst of data, in case
the amount of data outstanding in the network was much less than the amount of data outstanding in the network was much less than
the new congestion window allows [HTH98]. Clear the counter the new congestion window allows [HTH98]. Exit the Fast Recovery
recording the number of duplicate acknowledgements, exiting the 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 exit the Fast Recovery procedure (i.e., if any duplicate ACKs
acknowledgements (i.e., do not exit the Fast Recovery procedure). subsequently arrive, execute Steps 3 and 4 above).
For the first partial ACK that arrives during Fast Recovery, also For the first partial ACK that arrives during Fast Recovery, also
reset the retransmit timer. reset the retransmit timer.
Note that in Step 5, the congestion window is deflated when a partial Note that in Step 5, the congestion window is deflated when a partial
acknowledgement is received. The congestion window was likely to acknowledgement is received. The congestion window was likely to
have been inflated considerably when the partial acknowledgement was have been inflated considerably when the partial acknowledgement was
received. In addition, depending on the original pattern of packet received. In addition, depending on the original pattern of packet
losses, the partial acknowledgement might acknowledge nearly a window losses, the partial acknowledgement might acknowledge nearly a window
of data. In this case, if the congestion window was not deflated, of data. In this case, if the congestion window was not deflated,
skipping to change at page 6, line 45 skipping to change at page 6, line 36
TCP data receiver that triggered that duplicate acknowledgement. The TCP data receiver that triggered that duplicate acknowledgement. The
TCP data sender is unable to distinguish between a duplicate TCP data sender is unable to distinguish between a duplicate
acknowledgement that results from a lost or delayed data packet, and acknowledgement that results from a lost or delayed data packet, and
a duplicate acknowledgement that results from the sender's a duplicate acknowledgement that results from the sender's
retransmission of a data packet that had already been received at the retransmission of a data packet that had already been received at the
TCP data receiver. Because of this, multiple segment losses from a TCP data receiver. Because of this, multiple segment losses from a
single window of data can sometimes result in unnecessary multiple single window of data can sometimes result in unnecessary multiple
Fast Retransmits (and multiple reductions of the congestion window) Fast Retransmits (and multiple reductions of the congestion window)
[Flo94]. [Flo94].
With the Reno or NewReno Fast Retransmit and Fast Recovery With the Fast Retransmit and Fast Recovery algorithms in Reno or
algorithms, the performance problems caused by multiple Fast NewReno TCP, the performance problems caused by multiple Fast
Retransmits are relatively minor (compared to the potential problems Retransmits are relatively minor (compared to the potential problems
with Tahoe TCP, which does not implement Fast Recovery). with Tahoe TCP, which does not implement Fast Recovery).
Nevertheless, these unnecessary Fast Retransmits can occur with Reno Nevertheless, unnecessary Fast Retransmits can occur with Reno or
or NewReno TCP, particularly if a Retransmit Timeout occurs during NewReno TCP, particularly if a Retransmit Timeout occurs during Fast
Fast Recovery. (This is illustrated for Reno on page 6 of [F98], and Recovery. (This is illustrated for Reno on page 6 of [F98], and for
for NewReno on page 8 of [F98].) With NewReno, the data sender NewReno on page 8 of [F98].) With NewReno, the data sender remains
remains in Fast Recovery until either a Retransmit Timeout, or until in Fast Recovery until either a Retransmit Timeout, or until all of
all of the data outstanding when Fast Retransmit was entered has been the data outstanding when Fast Retransmit was entered has been
acknowledged. Thus with NewReno, the problem of multiple Fast acknowledged. Thus with NewReno, the problem of multiple Fast
Retransmits from a single window of data can only occur after a Retransmits from a single window of data can only occur after a
Retransmit Timeout. Retransmit Timeout.
The following modification to the algorithms in Section 3 eliminates The following modification to the algorithms in Section 3 eliminates
the problem of multiple Fast Retransmits. (This modification is the problem of multiple Fast Retransmits. (This modification is
called "bugfix" in [F98], and is illustrated on pages 7 and 9.) This called "bugfix" in [F98], and is illustrated on pages 7 and 9.) This
modification uses a new variable "send_high", whose initial value is modification uses a new variable "send_high", whose initial value is
zero. After each retransmit timeout, the highest sequence number the initial send sequence number. After each retransmit timeout, the
transmitted so far is recorded in the variable "send_high". highest sequence numbers transmitted so far is recorded in the
variable "send_high".
If, after a retransmit timeout, the TCP data sender retransmits three If, after a retransmit timeout, the TCP data sender retransmits three
consecutive packets that have already been received by the data consecutive packets that have already been received by the data
receiver, then the TCP data sender will receive three duplicate receiver, then the TCP data sender will receive three duplicate
acknowledgements that do not acknowledge "send_high". In this case, acknowledgements that do not acknowledge "send_high". In this case,
the duplicate acknowledgements are not an indication of a new the duplicate acknowledgements are not an indication of a new
instance of congestion. They are simply an indication that the instance of congestion. They are simply an indication that the
sender has unnecessarily retransmitted at least three packets. sender has unnecessarily retransmitted at least three packets.
We note that if the TCP data sender receives three duplicate We note that if the TCP data sender receives three duplicate
skipping to change at page 7, line 39 skipping to change at page 7, line 31
packet drop or not. For a TCP that implements the bugfix described packet drop or not. For a TCP that implements the bugfix described
in this section for avoiding multiple fast retransmits, the sender in this section for avoiding multiple fast retransmits, the sender
does not infer a packet drop from duplicate acknowledgements in these does not infer a packet drop from duplicate acknowledgements in these
circumstances. As always, the retransmit timer is the backup circumstances. As always, the retransmit timer is the backup
mechanism for inferring packet loss in this case. mechanism for inferring packet loss in this case.
The modification to Fast Retransmit for avoiding multiple Fast The modification to Fast Retransmit for avoiding multiple Fast
Retransmits replaces Step 1 in Section 3 with Step 1A below. In Retransmits replaces Step 1 in Section 3 with Step 1A below. In
addition, the modification adds Step 6 below: addition, the modification adds Step 6 below:
1A. When the third duplicate ACK is received, check to see if those 1A. When the third duplicate ACK is received and the sender is not
already in the Fast Recovery procedure, check to see if those
duplicate ACKs cover more than "send_high". If they do, then set duplicate ACKs cover more than "send_high". If they do, then set
ssthresh to no more than the value given in equation 1, record ssthresh to no more than the value given in equation 1, record
the highest sequence number transmitted in the variables the the highest sequence number transmitted in the variable
"recover" and "send_high", and go to Step 2. If the duplicate "recover", and go to Step 2. If the duplicate ACKs don't cover
ACKs don't cover send_high, then do nothing. That is, do not "send_high", then do nothing. That is, do not enter the Fast
enter the Fast Retransmit and Fast Recovery procedure, do not Retransmit and Fast Recovery procedure, do not change ssthresh,
change ssthresh, and do not go to Step 2 to retransmit the "lost" do not go to Step 2 to retransmit the "lost" segment, and do not
segment. execute Step 3 upon subsequent duplicate ACKs.
Steps 2-5 are the same as those steps in Section 3 above. Steps 2-5 are the same as those steps in Section 3 above.
6. After a retransmit timeout, record the highest sequence number 6. After a retransmit timeout, record the highest sequence number
transmitted in the variable "send_high". Do not change the transmitted in the variable "send_high" and exit the Fast
variable "recover". Recovery procedure if applicable.
Step 1A above, in checking whether the duplicate ACKs cover *more* Step 1A above, in checking whether the duplicate ACKs cover *more*
than "send_high", is the Careful variant of this algorithm. Another than "send_high", is the Careful variant of this algorithm. Another
possible variant would be to require simply that the three duplicate possible variant would be to require simply that the three duplicate
acknowledgements *cover* "send_high" before initiating another Fast acknowledgements *cover* "send_high" before initiating another Fast
Retransmit. We call this the Less Careful variant to Fast Retransmit. We call this the Less Careful variant to Fast
Retransmit. Retransmit.
There are two separate scenarios in which the TCP sender could There are two separate scenarios in which the TCP sender could
receive three duplicate acknowledgements acknowledging "send_high" receive three duplicate acknowledgements acknowledging "send_high"
skipping to change at page 9, line 37 skipping to change at page 9, line 30
both TCP end-nodes support the SACK option. The NewReno modification both TCP end-nodes support the SACK option. The NewReno modification
given in Section 3 implements the Impatient rather than the Slow-but- given in Section 3 implements the Impatient rather than the Slow-but-
Steady variant of NewReno. Steady variant of NewReno.
While this document mentions several possible variations to the While this document mentions several possible variations to the
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, Kacheong Poon, and Bernie Many thanks to Anil Agarwal, Mark Allman, Vern Paxson, Kacheong Poon,
Volz for detailed feedback on this document. and Bernie 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:
November 1998. Email to the tcpimpl mailing list, Message-ID ouch!". November 1998. Email to the tcpimpl mailing
"Pine.LNX.4.02A.9811021421340.26785-100000@sake.cs.washington.edu", list, Message-ID "Pine.LNX.4.02A.9811021421340.26785-
archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl". 100000@sake.cs.washington.edu", 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
TCPIMPL Working Group, August 1998. URLs the TCPIMPL Working Group, August 1998. URLs
"ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" and "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.ps" and
"ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf". "ftp://ftp.ee.lbl.gov/talks/sf-tcpimpl-aug98.pdf".
[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of [FF96] Kevin Fall and Sally Floyd. Simulation-based
Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996. Comparisons of Tahoe, Reno and SACK TCP. Computer
URL "ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z". Communication Review, July 1996. URL
"ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z".
[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical [Flo94] S. Floyd, TCP and Successive Fast Retransmits.
report, October 1994. URL Technical 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.
1998. Email to the tcpimpl mailing list, Message ID September 1998. Email to the tcpimpl mailing list,
"Pine.BSI.3.95.980923224136.26134A-100000@raptor.CS.Berkeley.EDU", Message ID "Pine.BSI.3.95.980923224136.26134A-
archived at "http://tcp-impl.lerc.nasa.gov/tcp-impl". 100000@raptor.CS.Berkeley.EDU", 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
Avoidance Schemes. Master's Thesis, MIT, 1995. URL "http://ana- and Avoidance Schemes. Master's Thesis, MIT, 1995. URL
www.lcs.mit.edu/anaweb/ps-papers/hoe-thesis.ps". "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
Control Scheme for TCP. In ACM SIGCOMM, August 1996. URL Congestion Control Scheme for TCP", In ACM SIGCOMM,
"http://www.acm.org/sigcomm/sigcomm96/program.html". August 1996. URL
"http://www.acm.org/sigcomm/sigcomm96/program.html".
[HTH98] A. Hughes, J. Touch, J. Heidemann, Issues in TCP Slow-Start [HTH98] Hughes, A., Touch, J. and J. Heidemann, "Issues in TCP
Restart After Idle, Work in progress, March 1998. Slow-Start Restart After Idle", Work in Progress, March
1998.
[LM97] Dong Lin and Robert Morris, "Dynamics of Random Early [LM97] Dong Lin and Robert Morris, "Dynamics of Random Early
Detection", SIGCOMM 97, September 1997. URL Detection", SIGCOMM 97, September 1997. URL
"http://www.acm.org/sigcomm/sigcomm97/program.html". "http://www.acm.org/sigcomm/sigcomm97/program.html".
[MMFR96] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective [MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Acknowledgement Options", RFC 2018, October 1996. Selective 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
mash.cs.berkeley.edu/ns/". "http://www-mash.cs.berkeley.edu/ns/".
[RFC2001] W. Stevens, "TCP Slow Start, Congestion Avoidance, Fast [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance,
Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. Fast Retransmit, and Fast Recovery Algorithms", RFC
2001, January 1997.
[RFC2001-bis] W. Stevens, M. Allman, and V. Paxson, "TCP Congestion [RFC2581] Stevens, W., Allman, M. and V. Paxson, "TCP Congestion
Control", draft-ietf-tcpimpl-cong-control-00.txt, August 1998. Control", RFC 2581, April 1999.
11. Security Considerations 11. Security Considerations
RFC 2001-bis discusses general security considerations concerning TCP RFC 2581 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 2581,
2001-bis, and so those considerations apply to this algorithm, too. and so those considerations apply to this algorithm, too. There are
There are no known additional security concerns for this specific no known additional security concerns for this specific algorithm.
algorithm.
AUTHORS' ADDRESSES 12. AUTHORS' ADDRESSES
Sally Floyd Sally Floyd
AT&T Center for Internet Research at ICSI (ACIRI) AT&T Center for Internet Research at ICSI (ACIRI)
Phone: +1 (510) 642-4274 x189 Phone: +1 (510) 642-4274 x189
Email: floyd@acm.org EMail: floyd@acm.org
URL: http://www-nrg.ee.lbl.gov/floyd/ URL: http://www.aciri.org/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 February 1999. 13. Full Copyright Statement
It expires August 1999.
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 45 change blocks. 
120 lines changed or deleted 125 lines changed or added

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