rfc2760.txt

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

   RTT connections obtaining only a small fraction of their fair share
   of the bandwidth.

   One effective solution to this problem is to deploy fair queueing and
   TCP-friendly buffer management in network routers [Sut98].  However,
   in the absence of help from the network, other researchers have
   investigated changes to the congestion avoidance policy at the TCP
   sender, as described in [Flo91,HK98].

3.4.2 Research

   The "Constant-Rate" increase policy has been studied in [Flo91,HK98].
   It attempts to equalize the rate at which TCP senders increase their
   sending rate during congestion avoidance.  Both [Flo91] and [HK98]
   illustrate cases in which the "Constant-Rate" policy largely corrects
   the bias against long RTT connections, although [HK98] presents some
   evidence that such a policy may be difficult to incrementally deploy
   in an operational network.  The proper selection of a constant (for
   the constant rate of increase) is an open issue.

   The "Increase-by-K" policy can be selectively used by long RTT
   connections in a heterogeneous environment.  This policy simply
   changes the slope of the linear increase, with connections over a
   given RTT threshold adding "K" segments to the congestion window
   every RTT, instead of one.  [HK98] presents evidence that this
   policy, when used with small values of "K", may be successful in
   reducing the unfairness while keeping the link utilization high, when
   a small number of connections share a bottleneck link.  The selection
   of the constant "K," the RTT threshold to invoke this policy, and
   performance under a large number of flows are all open issues.



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


3.4.3 Implementation Issues

   Implementation of either the "Constant-Rate" or "Increase-by-K"
   policies requires a change to the congestion avoidance mechanism at
   the TCP sender.  In the case of "Constant-Rate," such a change must
   be implemented globally.  Additionally, the TCP sender must have a
   reasonably accurate estimate of the RTT of the connection.  The
   algorithms outlined above violate the congestion avoidance algorithm
   as outlined in RFC 2581 [APS99] and therefore should not be
   implemented in shared networks at this time.

3.4.4 Topology Considerations

   These solutions are applicable to all satellite networks that are
   integrated with a terrestrial network, in which satellite connections
   may be competing with terrestrial connections for the same bottleneck
   link.

3.4.5 Possible Interaction and Relationships with Other Research

   As shown in [PADHV99], increasing the congestion window by multiple
   segments per RTT can cause TCP to drop multiple segments and force a
   retransmission timeout in some versions of TCP.  Therefore, the above
   changes to the congestion avoidance algorithm may need to be
   accompanied by a SACK-based loss recovery algorithm that can quickly
   repair multiple dropped segments.

3.5 Multiple Data Connections

3.5.1 Mitigation Description

   One method that has been used to overcome TCP's inefficiencies in the
   satellite environment is to use multiple TCP flows to transfer a
   given file.  The use of N TCP connections makes the sender N times
   more aggressive and therefore can improve throughput in some
   situations.  Using N multiple TCP connections can impact the transfer
   and the network in a number of ways, which are listed below.

   1. The transfer is able to start transmission using an effective
      congestion window of N segments, rather than a single segment as
      one TCP flow uses.  This allows the transfer to more quickly
      increase the effective cwnd size to an appropriate size for the
      given network.  However, in some circumstances an initial window
      of N segments is inappropriate for the network conditions.  In
      this case, a transfer utilizing more than one connection may
      aggravate congestion.





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


   2. During the congestion avoidance phase, the transfer increases the
      effective cwnd by N segments per RTT, rather than the one segment
      per RTT increase that a single TCP connection provides.  Again,
      this can aid the transfer by more rapidly increasing the effective
      cwnd to an appropriate point.  However, this rate of increase can
      also be too aggressive for the network conditions.  In this case,
      the use of multiple data connections can aggravate congestion in
      the network.

   3. Using multiple connections can provide a very large overall
      congestion window.  This can be an advantage for TCP
      implementations that do not support the TCP window scaling
      extension [JBB92].  However, the aggregate cwnd size across all N
      connections is equivalent to using a TCP implementation that
      supports large windows.

   4. The overall cwnd decrease in the face of dropped segments is
      reduced when using N parallel connections.  A single TCP
      connection reduces the effective size of cwnd to half when a
      single segment loss is detected.  When utilizing N connections
      each using a window of W bytes, a single drop reduces the window
      to:

        (N * W) - (W / 2)

   Clearly this is a less dramatic reduction in the effective cwnd size
   than when using a single TCP connection.  And, the amount by which
   the cwnd is decreased is further reduced by increasing N.

   The use of multiple data connections can increase the ability of
   non-SACK TCP implementations to quickly recover from multiple dropped
   segments without resorting to a timeout, assuming the dropped
   segments cross connections.

   The use of multiple parallel connections makes TCP overly aggressive
   for many environments and can contribute to congestive collapse in
   shared networks [FF99].  The advantages provided by using multiple
   TCP connections are now largely provided by TCP extensions (larger
   windows, SACKs, etc.).  Therefore, the use of a single TCP connection
   is more "network friendly" than using multiple parallel connections.
   However, using multiple parallel TCP connections may provide
   performance improvement in private networks.









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


3.5.2 Research

   Research on the use of multiple parallel TCP connections shows
   improved performance [IL92,Hah94,AOK95,AKO96].  In addition, research
   has shown that multiple TCP connections can outperform a single
   modern TCP connection (with large windows and SACK) [AHKO97].
   However, these studies did not consider the impact of using multiple
   TCP connections on competing traffic.  [FF99] argues that using
   multiple simultaneous connections to transfer a given file may lead
   to congestive collapse in shared networks.

3.5.3 Implementation Issues

   To utilize multiple parallel TCP connections a client application and
   the corresponding server must be customized.  As outlined in [FF99]
   using multiple parallel TCP connections is not safe (from a
   congestion control perspective) in shared networks and should not be
   used.

3.5.4 Topological Considerations

   As stated above, [FF99] outlines that the use of multiple parallel
   connections in a shared network, such as the Internet, may lead to
   congestive collapse.  However, the use of multiple connections may be
   safe and beneficial in private networks.  The specific topology being
   used will dictate the number of parallel connections required.  Some
   work has been done to determine the appropriate number of connections
   on the fly [AKO96], but such a mechanism is far from complete.

3.5.5 Possible Interaction and Relationships with Other Research

   Using multiple concurrent TCP connections enables use of a large
   congestion window, much like the TCP window scaling option [JBB92].
   In addition, a larger initial congestion window is achieved, similar
   to using [AFP98] or TCB sharing (see section 3.8).

3.6 Pacing TCP Segments

3.6.1 Mitigation Description

   Slow-start takes several round trips to fully open the TCP congestion
   window over routes with high bandwidth-delay products.  For short TCP
   connections (such as WWW traffic with HTTP/1.0), the slow-start
   overhead can preclude effective use of the high-bandwidth satellite
   links.  When senders implement slow-start restart after a TCP
   connection goes idle (suggested by Jacobson and Karels [JK92]),





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


   performance is reduced in long-lived (but bursty) connections (such
   as HTTP/1.1, which uses persistent TCP connections to transfer
   multiple WWW page elements) [Hei97a].

   Rate-based pacing (RBP) is a technique, used in the absence of
   incoming ACKs, where the data sender temporarily paces TCP segments
   at a given rate to restart the ACK clock.  Upon receipt of the first
   ACK, pacing is discontinued and normal TCP ACK clocking resumes.  The
   pacing rate may either be known from recent traffic estimates (when
   restarting an idle connection or from recent prior connections), or
   may be known through external means (perhaps in a point-to-point or
   point-to-multipoint satellite network where available bandwidth can
   be assumed to be large).

   In addition, pacing data during the first RTT of a transfer may allow
   TCP to make effective use of high bandwidth-delay links even for
   short transfers.  However, in order to pace segments during the first
   RTT a TCP will have to be using a non-standard initial congestion
   window and a new mechanism to pace outgoing segments rather than send
   them back-to-back.  Determining an appropriate size for the initial
   cwnd is an open research question.  Pacing can also be used to reduce
   bursts in general (due to buggy TCPs or byte counting, see section
   3.2.2 for a discussion on byte counting).

3.6.2 Research

   Simulation studies of rate-paced pacing for WWW-like traffic have
   shown reductions in router congestion and drop rates [VH97a].  In
   this environment, RBP substantially improves performance compared to
   slow-start-after-idle for intermittent senders, and it slightly
   improves performance over burst-full-cwnd-after-idle (because of
   drops) [VH98].  More recently, pacing has been suggested to eliminate
   burstiness in networks with ACK filtering [BPK97].

3.6.3 Implementation Issues

   RBP requires only sender-side changes to TCP.  Prototype
   implementations of RBP are available [VH97b].  RBP requires an
   additional sender timer for pacing.  The overhead of timer-driven
   data transfer is often considered too high for practical use.
   Preliminary experiments suggest that in RBP this overhead is minimal
   because RBP only requires this timer for one RTT of transmission
   [VH98].  RBP is expected to make TCP more conservative in sending
   bursts of data after an idle period in hosts that do not revert to
   slow start after an idle period.  On the other hand, RBP makes TCP
   more aggressive if the sender uses the slow start algorithm to start
   the ACK clock after a long idle period.




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


3.6.4  Topology Considerations

   RBP could be used to restart idle TCP connections for all topologies
   in Section 2.  Use at the beginning of new connections would be
   restricted to topologies where available bandwidth can be estimated
   out-of-band.

3.6.5 Possible Interaction and Relationships with Other Research

   Pacing segments may benefit from sharing state amongst various flows
   between two hosts, due to the time required to determine the needed
   information.  Additionally, pacing segments, rather than sending
   back-to-back segments, may make estimating the available bandwidth
   (as outlined in section 3.2.4) more difficult.

3.7 TCP Header Compression

   The TCP and IP header information needed to reliably deliver packets
   to a remote site across the Internet can add significant overhead,
   especially for interactive applications.  Telnet packets, for
   example, typically carry only a few bytes of data per packet, and
   standard IPv4/TCP headers add at least 40 bytes to this; IPv6/TCP
   headers add at least 60 bytes.  Much of this information rema