rfc2581.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 788 行 · 第 1/3 页

   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.