rfc2760.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

3.2.4.1 Mitigation Description

   The initial slow start phase is used by TCP to determine an
   appropriate congestion window size for the given network conditions
   [Jac88].  Slow start is terminated when TCP detects congestion, or
   when the size of cwnd reaches the size of the receiver's advertised
   window.  Slow start is also terminated if cwnd grows beyond a certain
   size.  The threshold at which TCP ends slow start and begins using
   the congestion avoidance algorithm is called "ssthresh" [Jac88].  In
   most implementations, the initial value for ssthresh is the
   receiver's advertised window.  During slow start, TCP roughly doubles
   the size of cwnd every RTT and therefore can overwhelm the network
   with at most twice as many segments as the network can handle.  By
   setting ssthresh to a value less than the receiver's advertised
   window initially, the sender may avoid overwhelming the network with
   twice the appropriate number of segments.  Hoe [Hoe96] proposes using
   the packet-pair algorithm [Kes91] and the measured RTT to determine a
   more appropriate value for ssthresh.  The algorithm observes the
   spacing between the first few returning ACKs to determine the
   bandwidth of the bottleneck link.  Together with the measured RTT,
   the delay*bandwidth product is determined and ssthresh is set to this
   value.  When TCP's cwnd reaches this reduced ssthresh, slow start is
   terminated and transmission continues using congestion avoidance,
   which is a more conservative algorithm for increasing the size of the
   congestion window.

3.2.4.2 Research

   It has been shown that estimating ssthresh can improve performance
   and decrease packet loss in simulations [Hoe96].  However, obtaining
   an accurate estimate of the available bandwidth in a dynamic network
   is very challenging, especially attempting to do so on the sending
   side of the TCP connection [AP99].  Therefore, before this mechanism
   is widely deployed, bandwidth estimation must be studied in a more
   detail.

3.2.4.3 Implementation Issues

   As outlined in [Hoe96], estimating ssthresh requires changes to the
   data sender's TCP stack.  As suggested in [AP99], bandwidth estimates
   may be more accurate when taken by the TCP receiver, and therefore
   both sender and receiver changes would be required.  Estimating



Allman, et al.               Informational                     [Page 11]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   ssthresh is safe to implement in production networks from a
   congestion control perspective, as it can only make TCP more
   conservative than outlined in RFC 2581 [APS99] (assuming the TCP
   implementation is using an initial ssthresh of infinity as allowed by
   [APS99]).

3.2.4.4 Topology Considerations

   It is expected that this mechanism will work equally well in all
   symmetric topologies outlined in section 2.  However, asymmetric
   links pose a special problem, as the rate of the returning ACKs may
   not be the bottleneck bandwidth in the forward direction.  This can
   lead to the sender setting ssthresh too low.  Premature termination
   of slow start can hurt performance, as congestion avoidance opens
   cwnd more conservatively.  Receiver-based bandwidth estimators do not
   suffer from this problem.

3.2.4.5 Possible Interaction and Relationships with Other Research

   Terminating slow start at the right time is useful to avoid multiple
   dropped segments.  However, using a selective acknowledgment-based
   loss recovery scheme (as outlined in section 3.3.2) can drastically
   improve TCP's ability to quickly recover from multiple lost segments
   Therefore, it may not be as important to terminate slow start before
   a large loss event occurs.  [AP99] shows that using delayed
   acknowledgments [Bra89] reduces the effectiveness of sender-side
   bandwidth estimation.  Therefore, using delayed ACKs only during slow
   start (as outlined in section 3.2.3) may make bandwidth estimation
   more feasible.

3.3 Loss Recovery

3.3.1 Non-SACK Based Mechanisms

3.3.1.1 Mitigation Description

   Several similar algorithms have been developed and studied that
   improve TCP's ability to recover from multiple lost segments in a
   window of data without relying on the (often long) retransmission
   timeout.  These sender-side algorithms, known as NewReno TCP, do not
   depend on the availability of selective acknowledgments (SACKs)
   [MMFR96].

   These algorithms generally work by updating the fast recovery
   algorithm to use information provided by "partial ACKs" to trigger
   retransmissions.  A partial ACK covers some new data, but not all
   data outstanding when a particular loss event starts.  For instance,
   consider the case when segment N is retransmitted using the fast



Allman, et al.               Informational                     [Page 12]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   retransmit algorithm and segment M is the last segment sent when
   segment N is resent.  If segment N is the only segment lost, the ACK
   elicited by the retransmission of segment N would be for segment M.
   If, however, segment N+1 was also lost, the ACK elicited by the
   retransmission of segment N will be N+1.  This can be taken as an
   indication that segment N+1 was lost and used to trigger a
   retransmission.

3.3.1.2 Research

   Hoe [Hoe95,Hoe96] introduced the idea of using partial ACKs to
   trigger retransmissions and showed that doing so could improve
   performance.  [FF96] shows that in some cases using partial ACKs to
   trigger retransmissions reduces the time required to recover from
   multiple lost segments.  However, [FF96] also shows that in some
   cases (many lost segments) relying on the RTO timer can improve
   performance over simply using partial ACKs to trigger all
   retransmissions.  [HK99] shows that using partial ACKs to trigger
   retransmissions, in conjunction with SACK, improves performance when
   compared to TCP using fast retransmit/fast recovery in a satellite
   environment.  Finally, [FH99] describes several slightly different
   variants of NewReno.

3.3.1.3 Implementation Issues

   Implementing these fast recovery enhancements requires changes to the
   sender-side TCP stack.  These changes can safely be implemented in
   production networks and are allowed by RFC 2581 [APS99].

3.3.1.4 Topology Considerations

   It is expected that these changes will work well in all environments
   outlined in section 2.

3.3.1.5 Possible Interaction and Relationships with Other Research

   See section 3.3.2.2.5.

3.3.2 SACK Based Mechanisms

3.3.2.1 Fast Recovery with SACK

3.3.2.1.1 Mitigation Description

   Fall and Floyd [FF96] describe a conservative extension to the fast
   recovery algorithm that takes into account information provided by
   selective acknowledgments (SACKs) [MMFR96] sent by the receiver.  The
   algorithm starts after fast retransmit triggers the resending of a



Allman, et al.               Informational                     [Page 13]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   segment.  As with fast retransmit, the algorithm cuts cwnd in half
   when a loss is detected.  The algorithm keeps a variable called
   "pipe", which is an estimate of the number of outstanding segments in
   the network.  The pipe variable is decremented by 1 segment for each
   duplicate ACK that arrives with new SACK information.  The pipe
   variable is incremented by 1 for each new or retransmitted segment
   sent.  A segment may be sent when the value of pipe is less than cwnd
   (this segment is either a retransmission per the SACK information or
   a new segment if the SACK information indicates that no more
   retransmits are needed).

   This algorithm generally allows TCP to recover from multiple segment
   losses in a window of data within one RTT of loss detection.  Like
   the forward acknowledgment (FACK) algorithm described below, the SACK
   information allows the pipe algorithm to decouple the choice of when
   to send a segment from the choice of what segment to send.

   [APS99] allows the use of this algorithm, as it is consistent with
   the spirit of the fast recovery algorithm.

3.3.2.1.2 Research

   [FF96] shows that the above described SACK algorithm performs better
   than several non-SACK based recovery algorithms when 1--4 segments
   are lost from a window of data.  [AHKO97] shows that the algorithm
   improves performance over satellite links.  Hayes [Hay97] shows the
   in certain circumstances, the SACK algorithm can hurt performance by
   generating a large line-rate burst of data at the end of loss
   recovery, which causes further loss.

3.3.2.1.3 Implementation Issues

   This algorithm is implemented in the sender's TCP stack.  However, it
   relies on SACK information generated by the receiver.  This algorithm
   is safe for shared networks and is allowed by RFC 2581 [APS99].

3.3.2.1.4 Topology Considerations

   It is expected that the pipe algorithm will work equally well in all
   scenarios presented in section 2.

3.3.2.1.5 Possible Interaction and Relationships with Other Research

   See section 3.3.2.2.5.







Allman, et al.               Informational                     [Page 14]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


3.3.2.2 Forward Acknowledgments

3.3.2.2.1 Mitigation Description

   The Forward Acknowledgment (FACK) algorithm [MM96a,MM96b] was
   developed to improve TCP congestion control during loss recovery.
   FACK uses TCP SACK options to glean additional information about the
   congestion state, adding more precise control to the injection of
   data into the network during recovery.  FACK decouples the congestion
   control algorithms from the data recovery algorithms to provide a
   simple and direct way to use SACK to improve congestion control.  Due
   to the separation of these two algorithms, new data may be sent
   during recovery to sustain TCP's self-clock when there is no further
   data to retransmit.

   The most recent version of FACK is Rate-Halving [MM96b], in which one
   packet is sent for every two ACKs received during recovery.
   Transmitting a segment for every-other ACK has the result of reducing
   the congestion window in one round trip to half of the number of
   packets that were successfully handled by the network (so when cwnd
   is too large by more than a factor of two it still gets reduced to
   half of what the network can sustain).  Another important aspect of
   FACK with Rate-Halving is that it sustains the ACK self-clock during
   recovery because transmitting a packet for every-other ACK does not
   require half a cwnd of data to drain from the network before
   transmitting, as required by the fast recovery algorithm
   [Ste97,APS99].

   In addition, the FACK with Rate-Halving implementation provides
   Thresholded Retransmission to each lost segment.  "Tcprexmtthresh" is
   the number of duplicate ACKs required by TCP to trigger a fast
   retransmit and enter recovery.  FACK applies thresholded
   retransmission to all segments by waiting until tcprexmtthresh SACK
   blocks indicate that a given segment is missing before resending the
   segment.  This allows reasonable behavior on links that reorder
   segments.  As described above, FACK sends a segment for every second
   ACK received during recovery.  New segments are transmitted except
   when tcprexmtthresh SACK blocks have been observed for a dropped
   segment, at which point the dropped segment is retransmitted.

   [APS99] allows the use of this algorithm, as it is consistent with
   the spirit of the fast recovery algorithm.

3.3.2.2.2 Research

   The original FACK algorithm is outlined in [MM96a].  The algorithm
   was later enhanced to include Rate-Halving [MM96b].  The real-world
   performance of FACK with Rate-Halving was shown to be much closer to



Allman, et al.               Informational                     [Page 15]

RFC 2760       Ongoing TCP Research Related to Satellites  February 2000


   the theoretical maximum for TCP than either TCP Reno or the SACK-
   based extensions to fast recovery outlined in section 3.3.2.1
   [MSMO97].

3.3.2.2.3 Implementation Issues

   In order to use FACK, the sender's TCP stack must be modified.  In
   addition, the receiver must be able to generate SACK options to
   obtain the full benefit of using FACK.  The FACK algorithm is safe
   for shared networks and is allowed by RFC 2581 [APS99].

3.3.2.2.4 Topology Considerations