doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc2581.txt b/doc/rfc/rfc2581.txt
new file mode 100644
index 0000000..07c1475
--- /dev/null
+++ b/doc/rfc/rfc2581.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          M. Allman
+Request for Comments: 2581                  NASA Glenn/Sterling Software
+Obsoletes: 2001                                                V. Paxson
+Category: Standards Track                                   ACIRI / ICSI
+                                                              W. Stevens
+                                                              Consultant
+                                                              April 1999
+
+
+                         TCP Congestion Control
+
+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 (1999).  All Rights Reserved.
+
+Abstract
+
+   This document defines TCP's four intertwined congestion control
+   algorithms: slow start, congestion avoidance, fast retransmit, and
+   fast recovery.  In addition, the document specifies how TCP should
+   begin transmission after a relatively long idle period, as well as
+   discussing various acknowledgment generation methods.
+
+1. Introduction
+
+   This document specifies four TCP [Pos81] congestion control
+   algorithms: slow start, congestion avoidance, fast retransmit and
+   fast recovery.  These algorithms were devised in [Jac88] and [Jac90].
+   Their use with TCP is standardized in [Bra89].
+
+   This document is an update of [Ste97].  In addition to specifying the
+   congestion control algorithms, this document specifies what TCP
+   connections should do after a relatively long idle period, as well as
+   specifying and clarifying some of the issues pertaining to TCP ACK
+   generation.
+
+   Note that [Ste94] provides examples of these algorithms in action and
+   [WS95] provides an explanation of the source code for the BSD
+   implementation of these algorithms.
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 1]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   This document is organized as follows.  Section 2 provides various
+   definitions which will be used throughout the document.  Section 3
+   provides a specification of the congestion control algorithms.
+   Section 4 outlines concerns related to the congestion control
+   algorithms and finally, section 5 outlines security considerations.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [Bra97].
+
+2. Definitions
+
+   This section provides the definition of several terms that will be
+   used throughout the remainder of this document.
+
+   SEGMENT:
+      A segment is ANY TCP/IP data or acknowledgment packet (or both).
+
+   SENDER MAXIMUM SEGMENT SIZE (SMSS):  The SMSS is the size of the
+      largest segment that the sender can transmit.  This value can be
+      based on the maximum transmission unit of the network, the path
+      MTU discovery [MD90] algorithm, RMSS (see next item), or other
+      factors.  The size does not include the TCP/IP headers and
+      options.
+
+   RECEIVER MAXIMUM SEGMENT SIZE (RMSS):  The RMSS is the size of the
+      largest segment the receiver is willing to accept.  This is the
+      value specified in the MSS option sent by the receiver during
+      connection startup.  Or, if the MSS option is not used, 536 bytes
+      [Bra89].  The size does not include the TCP/IP headers and
+      options.
+
+   FULL-SIZED SEGMENT: A segment that contains the maximum number of
+      data bytes permitted (i.e., a segment containing SMSS bytes of
+      data).
+
+   RECEIVER WINDOW (rwnd) The most recently advertised receiver window.
+
+   CONGESTION WINDOW (cwnd):  A TCP state variable that limits the
+      amount of data a TCP can send.  At any given time, a TCP MUST NOT
+      send data with a sequence number higher than the sum of the
+      highest acknowledged sequence number and the minimum of cwnd and
+      rwnd.
+
+   INITIAL WINDOW (IW):  The initial window is the size of the sender's
+      congestion window after the three-way handshake is completed.
+
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 2]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   LOSS WINDOW (LW):  The loss window is the size of the congestion
+      window after a TCP sender detects loss using its retransmission
+      timer.
+
+   RESTART WINDOW (RW):  The restart window is the size of the
+      congestion window after a TCP restarts transmission after an idle
+      period (if the slow start algorithm is used; see section 4.1 for
+      more discussion).
+
+   FLIGHT SIZE:  The amount of data that has been sent but not yet
+      acknowledged.
+
+3. Congestion Control Algorithms
+
+   This section defines the four congestion control algorithms: slow
+   start, congestion avoidance, fast retransmit and fast recovery,
+   developed in [Jac88] and [Jac90].  In some situations it may be
+   beneficial for a TCP sender to be more conservative than the
+   algorithms allow, however a TCP MUST NOT be more aggressive than the
+   following algorithms allow (that is, MUST NOT send data when the
+   value of cwnd computed by the following algorithms would not allow
+   the data to be sent).
+
+3.1 Slow Start and Congestion Avoidance
+
+   The slow start and congestion avoidance algorithms MUST be used by a
+   TCP sender to control the amount of outstanding data being injected
+   into the network.  To implement these algorithms, two variables are
+   added to the TCP per-connection state.  The congestion window (cwnd)
+   is a sender-side limit on the amount of data the sender can transmit
+   into the network before receiving an acknowledgment (ACK), while the
+   receiver's advertised window (rwnd) is a receiver-side limit on the
+   amount of outstanding data.  The minimum of cwnd and rwnd governs
+   data transmission.
+
+   Another state variable, the slow start threshold (ssthresh), is used
+   to determine whether the slow start or congestion avoidance algorithm
+   is used to control data transmission, as discussed below.
+
+   Beginning transmission into a network with unknown conditions
+   requires TCP to slowly probe the network to determine the available
+   capacity, in order to avoid congesting the network with an
+   inappropriately large burst of data.  The slow start algorithm is
+   used for this purpose at the beginning of a transfer, or after
+   repairing loss detected by the retransmission timer.
+
+
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 3]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   IW, the initial value of cwnd, MUST be less than or equal to 2*SMSS
+   bytes and MUST NOT be more than 2 segments.
+
+   We note that a non-standard, experimental TCP extension allows that a
+   TCP MAY use a larger initial window (IW), as defined in equation 1
+   [AFP98]:
+
+      IW = min (4*SMSS, max (2*SMSS, 4380 bytes))           (1)
+
+   With this extension, a TCP sender MAY use a 3 or 4 segment initial
+   window, provided the combined size of the segments does not exceed
+   4380 bytes.  We do NOT allow this change as part of the standard
+   defined by this document.  However, we include discussion of (1) in
+   the remainder of this document as a guideline for those experimenting
+   with the change, rather than conforming to the present standards for
+   TCP congestion control.
+
+   The initial value of ssthresh MAY be arbitrarily high (for example,
+   some implementations use the size of the advertised window), but it
+   may be reduced in response to congestion.  The slow start algorithm
+   is used when cwnd < ssthresh, while the congestion avoidance
+   algorithm is used when cwnd > ssthresh.  When cwnd and ssthresh are
+   equal the sender may use either slow start or congestion avoidance.
+
+   During slow start, a TCP increments cwnd by at most SMSS bytes for
+   each ACK received that acknowledges new data.  Slow start ends when
+   cwnd exceeds ssthresh (or, optionally, when it reaches it, as noted
+   above) or when congestion is observed.
+
+   During congestion avoidance, cwnd is incremented by 1 full-sized
+   segment per round-trip time (RTT).  Congestion avoidance continues
+   until congestion is detected.  One formula commonly used to update
+   cwnd during congestion avoidance is given in equation 2:
+
+      cwnd += SMSS*SMSS/cwnd                     (2)
+
+   This adjustment is executed on every incoming non-duplicate ACK.
+   Equation (2) provides an acceptable approximation to the underlying
+   principle of increasing cwnd by 1 full-sized segment per RTT.  (Note
+   that for a connection in which the receiver acknowledges every data
+   segment, (2) proves slightly more aggressive than 1 segment per RTT,
+   and for a receiver acknowledging every-other packet, (2) is less
+   aggressive.)
+
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 4]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   Implementation Note: Since integer arithmetic is usually used in TCP
+   implementations, the formula given in equation 2 can fail to increase
+   cwnd when the congestion window is very large (larger than
+   SMSS*SMSS).  If the above formula yields 0, the result SHOULD be
+   rounded up to 1 byte.
+
+   Implementation Note: older implementations have an additional
+   additive constant on the right-hand side of equation (2).  This is
+   incorrect and can actually lead to diminished performance [PAD+98].
+
+   Another acceptable way to increase cwnd during congestion avoidance
+   is to count the number of bytes that have been acknowledged by ACKs
+   for new data.  (A drawback of this implementation is that it requires
+   maintaining an additional state variable.)  When the number of bytes
+   acknowledged reaches cwnd, then cwnd can be incremented by up to SMSS
+   bytes.  Note that during congestion avoidance, cwnd MUST NOT be
+   increased by more than the larger of either 1 full-sized segment per
+   RTT, or the value computed using equation 2.
+
+   Implementation Note: some implementations maintain cwnd in units of
+   bytes, while others in units of full-sized segments.  The latter will
+   find equation (2) difficult to use, and may prefer to use the
+   counting approach discussed in the previous paragraph.
+
+   When a TCP sender detects segment loss using the retransmission
+   timer, the value of ssthresh MUST be set to no more than the value
+   given in equation 3:
+
+      ssthresh = max (FlightSize / 2, 2*SMSS)            (3)
+
+   As discussed above, FlightSize is the amount of outstanding data in
+   the network.
+
+   Implementation Note: an easy mistake to make is to simply use cwnd,
+   rather than FlightSize, which in some implementations may
+   incidentally increase well beyond rwnd.
+
+   Furthermore, upon a timeout cwnd MUST be set to no more than the loss
+   window, LW, which equals 1 full-sized segment (regardless of the
+   value of IW).  Therefore, after retransmitting the dropped segment
+   the TCP sender uses the slow start algorithm to increase the window
+   from 1 full-sized segment to the new value of ssthresh, at which
+   point congestion avoidance again takes over.
+
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 5]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+3.2 Fast Retransmit/Fast Recovery
+
+   A TCP receiver SHOULD send an immediate duplicate ACK when an out-
+   of-order segment arrives.  The purpose of this ACK is to inform the
+   sender that a segment was received out-of-order and which sequence
+   number is expected.  From the sender's perspective, duplicate ACKs
+   can be caused by a number of network problems.  First, they can be
+   caused by dropped segments.  In this case, all segments after the
+   dropped segment will trigger duplicate ACKs.  Second, duplicate ACKs
+   can be caused by the re-ordering of data segments by the network (not
+   a rare event along some network paths [Pax97]).  Finally, duplicate
+   ACKs can be caused by replication of ACK or data segments by the
+   network.  In addition, a TCP receiver SHOULD send an immediate ACK
+   when the incoming segment fills in all or part of a gap in the
+   sequence space.  This will generate more timely information for a
+   sender recovering from a loss through a retransmission timeout, a
+   fast retransmit, or an experimental loss recovery algorithm, such as
+   NewReno [FH98].
+
+   The TCP sender SHOULD use the "fast retransmit" algorithm to detect
+   and repair loss, based on incoming duplicate ACKs.  The fast
+   retransmit algorithm uses the arrival of 3 duplicate ACKs (4
+   identical ACKs without the arrival of any other intervening packets)
+   as an indication that a segment has been lost.  After receiving 3
+   duplicate ACKs, TCP performs a retransmission of what appears to be
+   the missing segment, without waiting for the retransmission timer to
+   expire.
+
+   After the fast retransmit algorithm sends what appears to be the
+   missing segment, the "fast recovery" algorithm governs the
+   transmission of new data until a non-duplicate ACK arrives.  The
+   reason for not performing slow start is that the receipt of the
+   duplicate ACKs not only indicates that a segment has been lost, but
+   also that segments are most likely leaving the network (although a
+   massive segment duplication by the network can invalidate this
+   conclusion).  In other words, since the receiver can only generate a
+   duplicate ACK when a segment has arrived, that segment has left the
+   network and is in the receiver's buffer, so we know it is no longer
+   consuming network resources.  Furthermore, since the ACK "clock"
+   [Jac88] is preserved, the TCP sender can continue to transmit new
+   segments (although transmission must continue using a reduced cwnd).
+
+   The fast retransmit and fast recovery algorithms are usually
+   implemented together as follows.
+
+   1.  When the third duplicate ACK is received, set ssthresh to no more
+       than the value given in equation 3.
+
+
+
+
+Allman, et. al.             Standards Track                     [Page 6]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   2.  Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS.
+       This artificially "inflates" the congestion window by the number
+       of segments (three) that have left the network and which the
+       receiver has buffered.
+
+   3.  For each additional duplicate ACK received, increment cwnd by
+       SMSS.  This artificially inflates the congestion window in order
+       to reflect the additional segment that has left the network.
+
+   4.  Transmit a segment, if allowed by the new value of cwnd and the
+       receiver's advertised window.
+
+   5.  When the next ACK arrives that acknowledges new data, set cwnd to
+       ssthresh (the value set in step 1).  This is termed "deflating"
+       the window.
+
+       This ACK should be the acknowledgment elicited by the
+       retransmission from step 1, one RTT after the retransmission
+       (though it may arrive sooner in the presence of significant out-
+       of-order delivery of data segments at the receiver).
+       Additionally, this ACK should acknowledge all the intermediate
+       segments sent between the lost segment and the receipt of the
+       third duplicate ACK, if none of these were lost.
+
+   Note: This algorithm is known to generally not recover very
+   efficiently from multiple losses in a single flight of packets
+   [FF96].  One proposed set of modifications to address this problem
+   can be found in [FH98].
+
+4. Additional Considerations
+
+4.1 Re-starting Idle Connections
+
+   A known problem with the TCP congestion control algorithms described
+   above is that they allow a potentially inappropriate burst of traffic
+   to be transmitted after TCP has been idle for a relatively long
+   period of time.  After an idle period, TCP cannot use the ACK clock
+   to strobe new segments into the network, as all the ACKs have drained
+   from the network.  Therefore, as specified above, TCP can potentially
+   send a cwnd-size line-rate burst into the network after an idle
+   period.
+
+   [Jac88] recommends that a TCP use slow start to restart transmission
+   after a relatively long idle period.  Slow start serves to restart
+   the ACK clock, just as it does at the beginning of a transfer.  This
+   mechanism has been widely deployed in the following manner.  When TCP
+   has not received a segment for more than one retransmission timeout,
+   cwnd is reduced to the value of the restart window (RW) before
+
+
+
+Allman, et. al.             Standards Track                     [Page 7]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   transmission begins.
+
+   For the purposes of this standard, we define RW = IW.
+
+   We note that the non-standard experimental extension to TCP defined
+   in [AFP98] defines RW = min(IW, cwnd), with the definition of IW
+   adjusted per equation (1) above.
+
+   Using the last time a segment was received to determine whether or
+   not to decrease cwnd fails to deflate cwnd in the common case of
+   persistent HTTP connections [HTH98].  In this case, a WWW server
+   receives a request before transmitting data to the WWW browser.  The
+   reception of the request makes the test for an idle connection fail,
+   and allows the TCP to begin transmission with a possibly
+   inappropriately large cwnd.
+
+   Therefore, a TCP SHOULD set cwnd to no more than RW before beginning
+   transmission if the TCP has not sent data in an interval exceeding
+   the retransmission timeout.
+
+4.2 Generating Acknowledgments
+
+   The delayed ACK algorithm specified in [Bra89] SHOULD be used by a
+   TCP receiver.  When used, a TCP receiver MUST NOT excessively delay
+   acknowledgments.  Specifically, an ACK SHOULD be generated for at
+   least every second full-sized segment, and MUST be generated within
+   500 ms of the arrival of the first unacknowledged packet.
+
+   The requirement that an ACK "SHOULD" be generated for at least every
+   second full-sized segment is listed in [Bra89] in one place as a
+   SHOULD and another as a MUST.  Here we unambiguously state it is a
+   SHOULD.  We also emphasize that this is a SHOULD, meaning that an
+   implementor should indeed only deviate from this requirement after
+   careful consideration of the implications.  See the discussion of
+   "Stretch ACK violation" in [PAD+98] and the references therein for a
+   discussion of the possible performance problems with generating ACKs
+   less frequently than every second full-sized segment.
+
+   In some cases, the sender and receiver may not agree on what
+   constitutes a full-sized segment.  An implementation is deemed to
+   comply with this requirement if it sends at least one acknowledgment
+   every time it receives 2*RMSS bytes of new data from the sender,
+   where RMSS is the Maximum Segment Size specified by the receiver to
+   the sender (or the default value of 536 bytes, per [Bra89], if the
+   receiver does not specify an MSS option during connection
+   establishment).  The sender may be forced to use a segment size less
+   than RMSS due to the maximum transmission unit (MTU), the path MTU
+   discovery algorithm or other factors.  For instance, consider the
+
+
+
+Allman, et. al.             Standards Track                     [Page 8]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   case when the receiver announces an RMSS of X bytes but the sender
+   ends up using a segment size of Y bytes (Y < X) due to path MTU
+   discovery (or the sender's MTU size).  The receiver will generate
+   stretch ACKs if it waits for 2*X bytes to arrive before an ACK is
+   sent.  Clearly this will take more than 2 segments of size Y bytes.
+   Therefore, while a specific algorithm is not defined, it is desirable
+   for receivers to attempt to prevent this situation, for example by
+   acknowledging at least every second segment, regardless of size.
+   Finally, we repeat that an ACK MUST NOT be delayed for more than 500
+   ms waiting on a second full-sized segment to arrive.
+
+   Out-of-order data segments SHOULD be acknowledged immediately, in
+   order to accelerate loss recovery.  To trigger the fast retransmit
+   algorithm, the receiver SHOULD send an immediate duplicate ACK when
+   it receives a data segment above a gap in the sequence space.  To
+   provide feedback to senders recovering from losses, the receiver
+   SHOULD send an immediate ACK when it receives a data segment that
+   fills in all or part of a gap in the sequence space.
+
+   A TCP receiver MUST NOT generate more than one ACK for every incoming
+   segment, other than to update the offered window as the receiving
+   application consumes new data [page 42, Pos81][Cla82].
+
+4.3 Loss Recovery Mechanisms
+
+   A number of loss recovery algorithms that augment fast retransmit and
+   fast recovery have been suggested by TCP researchers.  While some of
+   these algorithms are based on the TCP selective acknowledgment (SACK)
+   option [MMFR96], such as [FF96,MM96a,MM96b], others do not require
+   SACKs [Hoe96,FF96,FH98].  The non-SACK algorithms use "partial
+   acknowledgments" (ACKs which cover new data, but not all the data
+   outstanding when loss was detected) to trigger retransmissions.
+   While this document does not standardize any of the specific
+   algorithms that may improve fast retransmit/fast recovery, these
+   enhanced algorithms are implicitly allowed, as long as they follow
+   the general principles of the basic four algorithms outlined above.
+
+   Therefore, when the first loss in a window of data is detected,
+   ssthresh MUST be set to no more than the value given by equation (3).
+   Second, until all lost segments in the window of data in question are
+   repaired, the number of segments transmitted in each RTT MUST be no
+   more than half the number of outstanding segments when the loss was
+   detected.  Finally, after all loss in the given window of segments
+   has been successfully retransmitted, cwnd MUST be set to no more than
+   ssthresh and congestion avoidance MUST be used to further increase
+   cwnd.  Loss in two successive windows of data, or the loss of a
+   retransmission, should be taken as two indications of congestion and,
+   therefore, cwnd (and ssthresh) MUST be lowered twice in this case.
+
+
+
+Allman, et. al.             Standards Track                     [Page 9]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   The algorithms outlined in [Hoe96,FF96,MM96a,MM6b] follow the
+   principles of the basic four congestion control algorithms outlined
+   in this document.
+
+5.  Security Considerations
+
+   This document requires a TCP to diminish its sending rate in the
+   presence of retransmission timeouts and the arrival of duplicate
+   acknowledgments.  An attacker can therefore impair the performance of
+   a TCP connection by either causing data packets or their
+   acknowledgments to be lost, or by forging excessive duplicate
+   acknowledgments.  Causing two congestion control events back-to-back
+   will often cut ssthresh to its minimum value of 2*SMSS, causing the
+   connection to immediately enter the slower-performing congestion
+   avoidance phase.
+
+   The Internet to a considerable degree relies on the correct
+   implementation of these algorithms in order to preserve network
+   stability and avoid congestion collapse.  An attacker could cause TCP
+   endpoints to respond more aggressively in the face of congestion by
+   forging excessive duplicate acknowledgments or excessive
+   acknowledgments for new data.  Conceivably, such an attack could
+   drive a portion of the network into congestion collapse.
+
+6.  Changes Relative to RFC 2001
+
+   This document has been extensively rewritten editorially and it is
+   not feasible to itemize the list of changes between the two
+   documents. The intention of this document is not to change any of the
+   recommendations given in RFC 2001, but to further clarify cases that
+   were not discussed in detail in 2001. Specifically, this document
+   suggests what TCP connections should do after a relatively long idle
+   period, as well as specifying and clarifying some of the issues
+   pertaining to TCP ACK generation.  Finally, the allowable upper bound
+   for the initial congestion window has also been raised from one to
+   two segments.
+
+Acknowledgments
+
+   The four algorithms that are described were developed by Van
+   Jacobson.
+
+   Some of the text from this document is taken from "TCP/IP
+   Illustrated, Volume 1: The Protocols" by W. Richard Stevens
+   (Addison-Wesley, 1994) and "TCP/IP Illustrated, Volume 2: The
+   Implementation" by Gary R. Wright and W.  Richard Stevens (Addison-
+   Wesley, 1995).  This material is used with the permission of
+   Addison-Wesley.
+
+
+
+Allman, et. al.             Standards Track                    [Page 10]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   Neal Cardwell, Sally Floyd, Craig Partridge and Joe Touch contributed
+   a number of helpful suggestions.
+
+References
+
+   [AFP98]  Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
+            Initial Window Size, RFC 2414, September 1998.
+
+   [Bra89]  Braden, R., "Requirements for Internet Hosts --
+            Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [Bra97]  Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [Cla82]  Clark, D., "Window and Acknowledgment Strategy in TCP", RFC
+            813, July 1982.
+
+   [FF96]   Fall, K. and S. Floyd, "Simulation-based Comparisons of
+            Tahoe, Reno and SACK TCP", Computer Communication Review,
+            July 1996. ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
+
+   [FH98]   Floyd, S. and T. Henderson, "The NewReno Modification to
+            TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
+
+   [Flo94]  Floyd, S., "TCP and Successive Fast Retransmits. Technical
+            report", October 1994.
+            ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
+
+   [Hoe96]  Hoe, J., "Improving the Start-up Behavior of a Congestion
+            Control Scheme for TCP", In ACM SIGCOMM, August 1996.
+
+   [HTH98]  Hughes, A., Touch, J. and J. Heidemann, "Issues in TCP
+            Slow-Start Restart After Idle", Work in Progress.
+
+   [Jac88]  Jacobson, V., "Congestion Avoidance and Control", Computer
+            Communication Review, vol. 18, no. 4, pp. 314-329, Aug.
+            1988.  ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
+
+   [Jac90]  Jacobson, V., "Modified TCP Congestion Avoidance Algorithm",
+            end2end-interest mailing list, April 30, 1990.
+            ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.
+
+   [MD90]   Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
+            November 1990.
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                    [Page 11]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+   [MM96a]  Mathis, M. and J. Mahdavi, "Forward Acknowledgment: Refining
+            TCP Congestion Control", Proceedings of SIGCOMM'96, August,
+            1996, Stanford, CA.  Available
+            fromhttp://www.psc.edu/networking/papers/papers.html
+
+   [MM96b]  Mathis, M. and J. Mahdavi, "TCP Rate-Halving with Bounding
+            Parameters", Technical report.  Available from
+            http://www.psc.edu/networking/papers/FACKnotes/current.
+
+   [MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
+            Selective Acknowledgement Options", RFC 2018, October 1996.
+
+   [PAD+98] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, J.,
+            Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known TCP
+            Implementation Problems", RFC 2525, March 1999.
+
+   [Pax97]  Paxson, V., "End-to-End Internet Packet Dynamics",
+            Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997.
+
+   [Pos81]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+            September 1981.
+
+   [Ste94]  Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols",
+            Addison-Wesley, 1994.
+
+   [Ste97]  Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
+            Retransmit, and Fast Recovery Algorithms", RFC 2001, January
+            1997.
+
+   [WS95]   Wright, G. and W. Stevens, "TCP/IP Illustrated, Volume 2:
+            The Implementation", Addison-Wesley, 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                    [Page 12]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+Authors' Addresses
+
+   Mark Allman
+   NASA Glenn Research Center/Sterling Software
+   Lewis Field
+   21000 Brookpark Rd.  MS 54-2
+   Cleveland, OH  44135
+   216-433-6586
+
+   EMail: mallman@grc.nasa.gov
+   http://roland.grc.nasa.gov/~mallman
+
+
+   Vern Paxson
+   ACIRI / ICSI
+   1947 Center Street
+   Suite 600
+   Berkeley, CA 94704-1198
+
+   Phone: +1 510/642-4274 x302
+   EMail: vern@aciri.org
+
+
+   W. Richard Stevens
+   1202 E. Paseo del Zorro
+   Tucson, AZ  85718
+   520-297-9416
+
+   EMail: rstevens@kohala.com
+   http://www.kohala.com/~rstevens
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                    [Page 13]
+
+RFC 2581                 TCP Congestion Control               April 1999
+
+
+Full Copyright Statement
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman, et. al.             Standards Track                    [Page 14]
+