rfc2760.txt

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

   ACKs slows the cwnd growth rate.  In addition, when TCP starts
   sending, it sends 1 segment.  When using delayed ACKs a second
   segment must arrive before an ACK is sent.  Therefore, the receiver
   is always forced to wait for the delayed ACK timer to expire before
   ACKing the first segment, which also increases the transfer time.

   Several proposals have suggested ways to make slow start less time
   consuming.  These proposals are briefly outlined below and references
   to the research work given.

3.2.1 Larger Initial Window

3.2.1.1 Mitigation Description

   One method that will reduce the amount of time required by slow start
   (and therefore, the amount of wasted capacity) is to increase the
   initial value of cwnd.  An experimental TCP extension outlined in
   [AFP98] allows the initial size of cwnd to be increased from 1
   segment to that given in equation (1).

               min (4*MSS, max (2*MSS, 4380 bytes))               (1)

   By increasing the initial value of cwnd, more packets are sent during
   the first RTT of data transmission, which will trigger more ACKs,
   allowing the congestion window to open more rapidly.  In addition, by
   sending at least 2 segments initially, the first segment does not
   need to wait for the delayed ACK timer to expire as is the case when
   the initial size of cwnd is 1 segment (as discussed above).
   Therefore, the value of cwnd given in equation 1 saves up to 3 RTTs
   and a delayed ACK timeout when compared to an initial cwnd of 1
   segment.

   Also, we note that RFC 2581 [APS99], a standards-track document,
   allows a TCP to use an initial cwnd of up to 2 segments.  This change
   is highly recommended for satellite networks.

3.2.1.2 Research

   Several researchers have studied the use of a larger initial window
   in various environments.  [Nic97] and [KAGT98] show a reduction in
   WWW page transfer time over hybrid fiber coax (HFC) and satellite
   links respectively.  Furthermore, it has been shown that using an
   initial cwnd of 4 segments does not negatively impact overall
   performance over dialup modem links with a small number of buffers
   [SP98].  [AHO98] shows an improvement in transfer time for 16 KB
   files across the Internet and dialup modem links when using a larger
   initial value for cwnd.  However, a slight increase in dropped




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


   segments was also shown.  Finally, [PN98] shows improved transfer
   time for WWW traffic in simulations with competing traffic, in
   addition to a small increase in the drop rate.

3.2.1.3 Implementation Issues

   The use of a larger initial cwnd value requires changes to the
   sender's TCP stack.  Using an initial congestion window of 2 segments
   is allowed by RFC 2581 [APS99].  Using an initial congestion window
   of 3 or 4 segments is not expected to present any danger of
   congestion collapse [AFP98], however may degrade performance in some
   networks.

3.2.1.4 Topology Considerations

   It is expected that the use of a large initial window would be
   equally beneficial to all network architectures outlined in section
   2.

3.2.1.5 Possible Interaction and Relationships with Other Research

   Using a fixed larger initial congestion window decreases the impact
   of a long RTT on transfer time (especially for short transfers) at
   the cost of bursting data into a network with unknown conditions.  A
   mechanism that mitigates bursts may make the use of a larger initial
   congestion window more appropriate (e.g., limiting the size of line-
   rate bursts [FF96] or pacing the segments in a burst [VH97a]).

   Also, using delayed ACKs only after slow start (as outlined in
   section 3.2.3) offers an alternative way to immediately ACK the first
   segment of a transfer and open the congestion window more rapidly.
   Finally, using some form of TCP state sharing among a number of
   connections (as discussed in 3.8) may provide an alternative to using
   a fixed larger initial window.

3.2.2 Byte Counting

3.2.2.1 Mitigation Description

   As discussed above, the wide-spread use of delayed ACKs increases the
   time needed by a TCP sender to increase the size of the congestion
   window during slow start.  This is especially harmful to flows
   traversing long-delay GEO satellite links.  One mechanism that has
   been suggested to mitigate the problems caused by delayed ACKs is the
   use of "byte counting", rather than standard ACK counting
   [All97a,All98].  Using standard ACK counting, the congestion window
   is increased by 1 segment for each ACK received during slow start.
   However, using byte counting the congestion window increase is based



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


   on the number of previously unacknowledged bytes covered by each
   incoming ACK, rather than on the number of ACKs received.  This makes
   the increase relative to the amount of data transmitted, rather than
   being dependent on the ACK interval used by the receiver.

   Two forms of byte counting are studied in [All98].  The first is
   unlimited byte counting (UBC).  This mechanism simply uses the number
   of previously unacknowledged bytes to increase the congestion window
   each time an ACK arrives.  The second form is limited byte counting
   (LBC).  LBC limits the amount of cwnd increase to 2 segments.  This
   limit throttles the size of the burst of data sent in response to a
   "stretch ACK" [Pax97].  Stretch ACKs are acknowledgments that cover
   more than 2 segments of previously unacknowledged data.  Stretch ACKs
   can occur by design [Joh95] (although this is not standard), due to
   implementation bugs [All97b,PADHV99] or due to ACK loss.  [All98]
   shows that LBC prevents large line-rate bursts when compared to UBC,
   and therefore offers fewer dropped segments and better performance.
   In addition, UBC causes large bursts during slow start based loss
   recovery due to the large cumulative ACKs that can arrive during loss
   recovery.  The behavior of UBC during loss recovery can cause large
   decreases in performance and [All98] strongly recommends UBC not be
   deployed without further study into mitigating the large bursts.

   Note: The standards track RFC 2581 [APS99] allows a TCP to use byte
   counting to increase cwnd during congestion avoidance, however not
   during slow start.

3.2.2.2 Research

   Using byte counting, as opposed to standard ACK counting, has been
   shown to reduce the amount of time needed to increase the value of
   cwnd to an appropriate size in satellite networks [All97a].  In
   addition, [All98] presents a simulation comparison of byte counting
   and the standard cwnd increase algorithm in uncongested networks and
   networks with competing traffic.  This study found that the limited
   form of byte counting outlined above can improve performance, while
   also increasing the drop rate slightly.

   [BPK97,BPK98] also investigated unlimited byte counting in
   conjunction with various ACK filtering algorithms (discussed in
   section 3.10) in asymmetric networks.










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


3.2.2.3 Implementation Issues

   Changing from ACK counting to byte counting requires changes to the
   data sender's TCP stack.  Byte counting violates the algorithm for
   increasing the congestion window outlined in RFC 2581 [APS99] (by
   making congestion window growth more aggressive during slow start)
   and therefore should not be used in shared networks.

3.2.2.4 Topology Considerations

   It has been suggested by some (and roundly criticized by others) that
   byte counting will allow TCP to provide uniform cwnd increase,
   regardless of the ACKing behavior of the receiver.  In addition, byte
   counting also mitigates the retarded window growth provided by
   receivers that generate stretch ACKs because of the capacity of the
   return link, as discussed in [BPK97,BPK98].  Therefore, this change
   is expected to be especially beneficial to asymmetric networks.

3.2.2.5 Possible Interaction and Relationships with Other Research

   Unlimited byte counting should not be used without a method to
   mitigate the potentially large line-rate bursts the algorithm can
   cause.  Also, LBC may send bursts that are too large for the given
   network conditions.  In this case, LBC may also benefit from some
   algorithm that would lessen the impact of line-rate bursts of
   segments.  Also note that using delayed ACKs only after slow start
   (as outlined in section 3.2.3) negates the limited byte counting
   algorithm because each ACK covers only one segment during slow start.
   Therefore, both ACK counting and byte counting yield the same
   increase in the congestion window at this point (in the first RTT).

3.2.3 Delayed ACKs After Slow Start

3.2.3.1 Mitigation Description

   As discussed above, TCP senders use the number of incoming ACKs to
   increase the congestion window during slow start.  And, since delayed
   ACKs reduce the number of ACKs returned by the receiver by roughly
   half, the rate of growth of the congestion window is reduced.  One
   proposed solution to this problem is to use delayed ACKs only after
   the slow start (DAASS) phase.  This provides more ACKs while TCP is
   aggressively increasing the congestion window and less ACKs while TCP
   is in steady state, which conserves network resources.








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


3.2.3.2 Research

   [All98] shows that in simulation, using delayed ACKs after slow start
   (DAASS) improves transfer time when compared to a receiver that
   always generates delayed ACKs.  However, DAASS also slightly
   increases the loss rate due to the increased rate of cwnd growth.

3.2.3.3 Implementation Issues

   The major problem with DAASS is in the implementation.  The receiver
   has to somehow know when the sender is using the slow start
   algorithm.  The receiver could implement a heuristic that attempts to
   watch the change in the amount of data being received and change the
   ACKing behavior accordingly.  Or, the sender could send a message (a
   flipped bit in the TCP header, perhaps) indicating that it was using
   slow start.  The implementation of DAASS is, therefore, an open
   issue.

   Using DAASS does not violate the TCP congestion control specification
   [APS99].  However, the standards (RFC 2581 [APS99]) currently
   recommend using delayed acknowledgments and DAASS goes (partially)
   against this recommendation.

3.2.3.4 Topology Considerations

   DAASS should work equally well in all scenarios presented in section
   2.  However, in asymmetric networks it may aggravate ACK congestion
   in the return link, due to the increased number of ACKs (see sections
   3.9 and 3.10 for a more detailed discussion of ACK congestion).

3.2.3.5 Possible Interaction and Relationships with Other Research

   DAASS has several possible interactions with other proposals made in
   the research community.  DAASS can aggravate congestion on the path
   between the data receiver and the data sender due to the increased
   number of returning acknowledgments.  This can have an especially
   adverse effect on asymmetric networks that are prone to experiencing
   ACK congestion.  As outlined in sections 3.9 and 3.10, several
   mitigations have been proposed to reduce the number of ACKs that are
   passed over a low-bandwidth return link.  Using DAASS will increase
   the number of ACKs sent by the receiver.  The interaction between
   DAASS and the methods for reducing the number of ACKs is an open
   research question.  Also, as noted in section 3.2.1.5 above, DAASS
   provides some of the same benefits as using a larger initial
   congestion window and therefore it may not be desirable to use both
   mechanisms together.  However, this remains an open question.
   Finally, DAASS and limited byte counting are both used to increase




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


   the rate at which the congestion window is opened.  The DAASS
   algorithm substantially reduces the impact limited byte counting has
   on the rate of congestion window increase.

3.2.4 Terminating Slow Start