rfc2488.txt

中、英文RFC文档大全打包下载完全版 .

   dropped somewhere in the network and segment 12 arrives at the
   receiver.  The receiver is going to send a duplicate ACK covering
   segment 10 (and all previous segments).

   The fast retransmit algorithm uses these duplicate ACKs to detect
   lost segments.  If 3 duplicate ACKs arrive at the data originator,
   TCP assumes that a segment has been lost and retransmits the missing
   segment without waiting for the RTO to expire.  After a segment is
   resent using fast retransmit, the fast recovery algorithm is used to
   adjust the congestion window.  First, the value of ssthresh is set to
   half of the value of cwnd.  Next, the value of cwnd is halved.
   Finally, the value of cwnd is artificially increased by 1 segment for
   each duplicate ACK that has arrived.  The artificial inflation can be
   done because each duplicate ACK represents 1 segment that has left
   the network.  When the cwnd permits, TCP is able to transmit new
   data.  This allows TCP to keep data flowing through the network at
   half the rate it was when loss was detected.  When an ACK for the
   retransmitted packet arrives, the value of cwnd is reduced back to
   ssthresh (half the value of cwnd when the congestion was detected).








Allman, et. al.          Best Current Practice                 [Page 10]

RFC 2488         Enhancing TCP Over Satellite Channels      January 1999


   Generally, fast retransmit can resend only one segment per window of
   data sent.  When multiple segments are lost in a given window of
   data, one of the segments will be resent using fast retransmit and
   the rest of the dropped segments must usually wait for the RTO to
   expire, which causes TCP to revert to slow start.

   TCP's response to congestion differs based on the way the congestion
   is detected.  If the retransmission timer causes a packet to be
   resent, TCP drops ssthresh to half the current cwnd and reduces the
   value of cwnd to 1 segment (thus triggering slow start).  However, if
   a segment is resent via fast retransmit both ssthresh and cwnd are
   set to half the current value of cwnd and congestion avoidance is
   used to send new data.  The difference is that when retransmitting
   due to duplicate ACKs, TCP knows that packets are still flowing
   through the network and can therefore infer that the congestion is
   not that bad.  However, when resending a packet due to the expiration
   of the retransmission timer, TCP cannot infer anything about the
   state of the network and therefore must proceed conservatively by
   sending new data using the slow start algorithm.

   Note that the fast retransmit/fast recovery algorithms, as discussed
   above can lead to a phenomenon that allows multiple fast retransmits
   per window of data [Flo94].  This can reduce the size of the
   congestion window multiple times in response to a single "loss
   event".  The problem is particularly noticeable in connections that
   utilize large congestion windows, since these connections are able to
   inject enough new segments into the network during recovery to
   trigger the multiple fast retransmits.  Reducing cwnd multiple times
   for a single loss event may hurt performance [GJKFV98].

   The best way to improve the fast retransmit/fast recovery algorithms
   is to use a selective acknowledgment (SACK) based algorithm for loss
   recovery.  As discussed below, these algorithms are generally able to
   quickly recover from multiple lost segments without needlessly
   reducing the value of cwnd.  In the absence of SACKs, the fast
   retransmit and fast recovery algorithms should be used.  Fixing these
   algorithms to achieve better performance in the face of multiple fast
   retransmissions is beyond the scope of this document.  Therefore, TCP
   implementers are advised to implement the current version of fast
   retransmit/fast recovery outlined in RFC 2001 [Ste97] or subsequent
   versions of RFC 2001.

4.1.3 Congestion Control in Satellite Environment

   The above algorithms have a negative impact on the performance of
   individual TCP connection's performance because the algorithms slowly
   probe the network for additional capacity, which in turn wastes
   bandwidth.  This is especially true over long-delay satellite



Allman, et. al.          Best Current Practice                 [Page 11]

RFC 2488         Enhancing TCP Over Satellite Channels      January 1999


   channels because of the large amount of time required for the sender
   to obtain feedback from the receiver [All97] [AHKO97].  However, the
   algorithms are necessary to prevent congestive collapse in a shared
   network [Jac88].  Therefore, the negative impact on a given
   connection is more than offset by the benefit to the entire network.

4.2 Large TCP Windows

   The standard maximum TCP window size (65,535 bytes) is not adequate
   to allow a single TCP connection to utilize the entire bandwidth
   available on some satellite channels.  TCP throughput is limited by
   the following formula [Pos81]:

                      throughput = window size / RTT

   Therefore, using the maximum window size of 65,535 bytes and a
   geosynchronous satellite channel RTT of 560 ms [Kru95] the maximum
   throughput is limited to:

         throughput = 65,535 bytes / 560 ms = 117,027 bytes/second

   Therefore, a single standard TCP connection cannot fully utilize, for
   example, T1 rate (approximately 192,000 bytes/second) GSO satellite
   channels.  However, TCP has been extended to support larger windows
   [JBB92].  The window scaling options outlined in [JBB92] should be
   used in satellite environments, as well as the companion algorithms
   PAWS (Protection Against Wrapped Sequence space) and RTTM (Round-Trip
   Time Measurements).

   It should be noted that for a satellite link shared among many flows,
   large windows may not be necessary.  For instance, two long-lived TCP
   connections each using a window of 65,535 bytes, as in the above
   example, can fully utilize a T1 GSO satellite channel.

   Using large windows often requires both client and server
   applications or TCP stacks to be hand tuned (usually by an expert) to
   utilize large windows.  Research into operating system mechanisms
   that are able to adjust the buffer capacity as dictated by the
   current network conditions is currently underway [SMM98].  This will
   allow stock TCP implementations and applications to better utilize
   the capacity provided by the underlying network.

4.3 Acknowledgment Strategies

   There are two standard methods that can be used by TCP receivers to
   generated acknowledgments.  The method outlined in [Pos81] generates
   an ACK for each incoming segment.  [Bra89] states that hosts SHOULD
   use "delayed acknowledgments".  Using this algorithm, an ACK is



Allman, et. al.          Best Current Practice                 [Page 12]

RFC 2488         Enhancing TCP Over Satellite Channels      January 1999


   generated for every second full-sized segment, or if a second full-
   size segment does not arrive within a given timeout (which must not
   exceed 500 ms).  The congestion window is increased based on the
   number of incoming ACKs and delayed ACKs reduce the number of ACKs
   being sent by the receiver.  Therefore, cwnd growth occurs much more
   slowly when using delayed ACKs compared to the case when the receiver
   ACKs each incoming segment [All98].

   A tempting "fix" to the problem caused by delayed ACKs is to simply
   turn the mechanism off and let the receiver ACK each incoming
   segment.  However, this is not recommended.  First, [Bra89] says that
   a TCP receiver SHOULD generate delayed ACKs.  And, second, increasing
   the number of ACKs by a factor of two in a shared network may have
   consequences that are not yet understood.  Therefore, disabling
   delayed ACKs is still a research issue and thus, at this time TCP
   receivers should continue to generate delayed ACKs, per [Bra89].

4.4 Selective Acknowledgments

   Selective acknowledgments (SACKs) [MMFR96] allow TCP receivers to
   inform TCP senders exactly which packets have arrived.  SACKs allow
   TCP to recover more quickly from lost segments, as well as avoiding
   needless retransmissions.

   The fast retransmit algorithm can generally only repair one loss per
   window of data.  When multiple losses occur, the sender generally
   must rely on a timeout to determine which segment needs to be
   retransmitted next.  While waiting for a timeout, the data segments
   and their acknowledgments drain from the network.  In the absence of
   incoming ACKs to clock new segments into the network, the sender must
   use the slow start algorithm to restart transmission.  As discussed
   above, the slow start algorithm can be time consuming over satellite
   channels.  When SACKs are employed, the sender is generally able to
   determine which segments need to be retransmitted in the first RTT
   following loss detection.  This allows the sender to continue to
   transmit segments (retransmissions and new segments, if appropriate)
   at an appropriate rate and therefore sustain the ACK clock.  This
   avoids a costly slow start period following multiple lost segments.
   Generally SACK is able to retransmit all dropped segments within the
   first RTT following the loss detection.  [MM96] and [FF96] discuss
   specific congestion control algorithms that rely on SACK information
   to determine which segments need to be retransmitted and when it is
   appropriate to transmit those segments.  Both these algorithms follow
   the basic principles of congestion control outlined in [Jac88] and
   reduce the window by half when congestion is detected.






Allman, et. al.          Best Current Practice                 [Page 13]

RFC 2488         Enhancing TCP Over Satellite Channels      January 1999


5.  Mitigation Summary

   Table 1 summarizes the mechanisms that have been discussed in this
   document.  Those mechanisms denoted "Recommended" are IETF standards
   track mechanisms that are recommended by the authors for use in
   networks containing satellite channels.  Those mechanisms marked
   "Required' have been defined by the IETF as required for hosts using
   the shared Internet [Bra89].  Along with the section of this document
   containing the discussion of each mechanism, we note where the
   mechanism needs to be implemented.  The codes listed in the last
   column are defined as follows: "S" for the data sender, "R" for the
   data receiver and "L" for the satellite link.

    Mechanism                 Use          Section      Where
   +------------------------+-------------+------------+--------+
   | Path-MTU Discovery     | Recommended | 3.1        | S      |
   | FEC                    | Recommended | 3.2        | L      |
   | TCP Congestion Control |             |            |        |
   |   Slow Start           | Required    | 4.1.1      | S      |
   |   Congestion Avoidance | Required    | 4.1.1      | S      |
   |   Fast Retransmit      | Recommended | 4.1.2      | S      |
   |   Fast Recovery        | Recommended | 4.1.2      | S      |
   | TCP Large Windows      |             |            |        |
   |   Window Scaling       | Recommended | 4.2        | S,R    |
   |   PAWS                 | Recommended | 4.2        | S,R    |
   |   RTTM                 | Recommended | 4.2        | S,R    |
   | TCP SACKs              | Recommended | 4.4        | S,R    |
   +------------------------+-------------+------------+--------+
                                Table 1

   Satellite users should check with their TCP vendors (implementors) to
   ensure the recommended mechanisms are supported in their stack in
   current and/or future versions.  Alternatively, the Pittsburgh
   Supercomputer Center tracks TCP implementations and which extensions
   they support, as well as providing guidance on tuning various TCP
   implementations [PSC].

   Research into improving the efficiency of TCP over satellite channels
   is ongoing and will be summarized in a planned memo along with other
   considerations, such as satellite network architectures.

6.  Security Considerations

   The authors believe that the recommendations contained in this memo
   do not alter the security implications of TCP.  However, when using a
   broadcast medium such as satellites links to transfer user data
   and/or network control traffic, one should be aware of the intrinsic
   security implications of such technology.



Allman, et. al.          Best Current Practice                 [Page 14]

RFC 2488         Enhancing TCP Over Satellite Channels      January 1999


   Eavesdropping on network links is a form of passive attack that, if
   performed successfully, could reveal critical traffic control
   information that would jeopardize the proper functioning of the
   network.  These attacks could reduce the ability of the network to
   provide data transmission services efficiently.  Eavesdroppers could
   also compromise the privacy of user data, especially if end-to-end
   security mechanisms are not in use.  While passive monitoring can
   occur on any network, the wireless broadcast nature of satellite
   links allows reception of signals without physical connection to the
   network which enables monitoring to be conducted without detection.
   However, it should be noted that the resources needed to monitor a