rfc2488.txt

RFC 的详细文档！

3.  Lower Level Mitigations

   It is recommended that those utilizing satellite channels in their
   networks should use the following two non-TCP mechanisms which can
   increase TCP performance.  These mechanisms are Path MTU Discovery
   and forward error correction (FEC) and are outlined in the following
   two sections.

   The data link layer protocol employed over a satellite channel can
   have a large impact on performance of higher layer protocols.  While
   beyond the scope of this document, those constructing satellite



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


   networks should tune these protocols in an appropriate manner to
   ensure that the data link protocol does not limit TCP performance.
   In particular, data link layer protocols often implement a flow
   control window and retransmission mechanisms.  When the link level
   window size is too small, performance will suffer just as when the
   TCP window size is too small (see section 4.3 for a discussion of
   appropriate window sizes).  The impact that link level
   retransmissions have on TCP transfers is not currently well
   understood.  The interaction between TCP retransmissions and link
   level retransmissions is a subject for further research.

3.1 Path MTU Discovery

   Path MTU discovery [MD90] is used to determine the maximum packet
   size a connection can use on a given network path without being
   subjected to IP fragmentation.  The sender transmits a packet that is
   the appropriate size for the local network to which it is connected
   (e.g., 1500 bytes on an Ethernet) and sets the IP "don't fragment"
   (DF) bit.  If the packet is too large to be forwarded without being
   fragmented to a given channel along the network path, the gateway
   that would normally fragment the packet and forward the fragments
   will instead return an ICMP message to the originator of the packet.
   The ICMP message will indicate that the original segment could not be
   transmitted without being fragmented and will also contain the size
   of the largest packet that can be forwarded by the gateway.
   Additional information from the IESG regarding Path MTU discovery is
   available in [Kno93].

   Path MTU Discovery allows TCP to use the largest possible packet
   size, without incurring the cost of fragmentation and reassembly.
   Large packets reduce the packet overhead by sending more data bytes
   per overhead byte.  As outlined in section 4, increasing TCP's
   congestion window is segment based, rather than byte based and
   therefore, larger segments enable TCP senders to increase the
   congestion window more rapidly, in terms of bytes, than smaller
   segments.

   The disadvantage of Path MTU Discovery is that it may cause a delay
   before TCP is able to start sending data.  For example, assume a
   packet is sent with the DF bit set and one of the intervening
   gateways (G1) returns an ICMP message indicating that it cannot
   forward the segment.  At this point, the sending host reduces the
   packet size per the ICMP message returned by G1 and sends another
   packet with the DF bit set.  The packet will be forwarded by G1,
   however this does not ensure all subsequent gateways in the network
   path will be able to forward the segment.  If a second gateway (G2)
   cannot forward the segment it will return an ICMP message to the
   transmitting host and the process will be repeated.  Therefore, path



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


   MTU discovery can spend a large amount of time determining the
   maximum allowable packet size on the network path between the sender
   and receiver.  Satellite delays can aggravate this problem (consider
   the case when the channel between G1 and G2 is a satellite link).
   However, in practice, Path MTU Discovery does not consume a large
   amount of time due to wide support of common MTU values.
   Additionally, caching MTU values may be able to eliminate discovery
   time in many instances, although the exact implementation of this and
   the aging of cached values remains an open problem.

   The relationship between BER and segment size is likely to vary
   depending on the error characteristics of the given channel.  This
   relationship deserves further study, however with the use of good
   forward error correction (see section 3.2) larger segments should
   provide better performance, as with any network [MSMO97].  While the
   exact method for choosing the best MTU for a satellite link is
   outside the scope of this document, the use of Path MTU Discovery is
   recommended to allow TCP to use the largest possible MTU over the
   satellite channel.

3.2 Forward Error Correction

   A loss event in TCP is always interpreted as an indication of
   congestion and always causes TCP to reduce its congestion window
   size.  Since the congestion window grows based on returning
   acknowledgments (see section 4), TCP spends a long time recovering
   from loss when operating in satellite networks.  When packet loss is
   due to corruption, rather than congestion, TCP does not need to
   reduce its congestion window size.  However, at the present time
   detecting corruption loss is a research issue.

   Therefore, for TCP to operate efficiently, the channel
   characteristics should be such that nearly all loss is due to network
   congestion.  The use of forward error correction coding (FEC) on a
   satellite link should be used to improve the bit-error rate (BER) of
   the satellite channel.  Reducing the BER is not always possible in
   satellite environments.  However, since TCP takes a long time to
   recover from lost packets because the long propagation delay imposed
   by a satellite link delays feedback from the receiver [PS97], the
   link should be made as clean as possible to prevent TCP connections
   from receiving false congestion signals.  This document does not make
   a specific BER recommendation for TCP other than it should be as low
   as possible.

   FEC should not be expected to fix all problems associated with noisy
   satellite links.  There are some situations where FEC cannot be
   expected to solve the noise problem (such as military jamming, deep
   space missions, noise caused by rain fade, etc.).  In addition, link



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


   outages can also cause problems in satellite systems that do not
   occur as frequently in terrestrial networks.  Finally, FEC is not
   without cost.  FEC requires additional hardware and uses some of the
   available bandwidth.  It can add delay and timing jitter due to the
   processing time of the coder/decoder.

   Further research is needed into mechanisms that allow TCP to
   differentiate between congestion induced drops and those caused by
   corruption.  Such a mechanism would allow TCP to respond to
   congestion in an appropriate manner, as well as repairing corruption
   induced loss without reducing the transmission rate.  However, in the
   absence of such a mechanism packet loss must be assumed to indicate
   congestion to preserve network stability.  Incorrectly interpreting
   loss as caused by corruption and not reducing the transmission rate
   accordingly can lead to congestive collapse [Jac88] [FF98].

4.  Standard TCP Mechanisms

   This section outlines TCP mechanisms that may be necessary in
   satellite or hybrid satellite/terrestrial networks to better utilize
   the available capacity of the link.  These mechanisms may also be
   needed to fully utilize fast terrestrial channels.  Furthermore,
   these mechanisms do not fundamentally hurt performance in a shared
   terrestrial network.  Each of the following sections outlines one
   mechanism and why that mechanism may be needed.

4.1 Congestion Control

   To avoid generating an inappropriate amount of network traffic for
   the current network conditions, during a connection TCP employs four
   congestion control mechanisms [Jac88] [Jac90] [Ste97].  These
   algorithms are slow start, congestion avoidance, fast retransmit and
   fast recovery.  These algorithms are used to adjust the amount of
   unacknowledged data that can be injected into the network and to
   retransmit segments dropped by the network.

   TCP senders use two state variables to accomplish congestion control.
   The first variable is the congestion window (cwnd).  This is an upper
   bound on the amount of data the sender can inject into the network
   before receiving an acknowledgment (ACK).  The value of cwnd is
   limited to the receiver's advertised window.  The congestion window
   is increased or decreased during the transfer based on the inferred
   amount of congestion present in the network.  The second variable is
   the slow start threshold (ssthresh).  This variable determines which
   algorithm is used to increase the value of cwnd.  If cwnd is less
   than ssthresh the slow start algorithm is used to increase the value
   of cwnd.  However, if cwnd is greater than or equal to (or just
   greater than in some TCP implementations) ssthresh the congestion



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


   avoidance algorithm is used.  The initial value of ssthresh is the
   receiver's advertised window size.  Furthermore, the value of
   ssthresh is set when congestion is detected.

   The four congestion control algorithms are outlined below, followed
   by a brief discussion of the impact of satellite environments on
   these algorithms.

4.1.1 Slow Start and Congestion Avoidance

   When a host begins sending data on a TCP connection the host has no
   knowledge of the current state of the network between itself and the
   data receiver.  In order to avoid transmitting an inappropriately
   large burst of traffic, the data sender is required to use the slow
   start algorithm at the beginning of a transfer [Jac88] [Bra89]
   [Ste97].  Slow start begins by initializing cwnd to 1 segment
   (although an IETF experimental mechanism would increase the size of
   the initial window to roughly 4 Kbytes [AFP98]) and ssthresh to the
   receiver's advertised window.  This forces TCP to transmit one
   segment and wait for the corresponding ACK.  For each ACK that is
   received during slow start, the value of cwnd is increased by 1
   segment.  For example, after the first ACK is received cwnd will be 2
   segments and the sender will be allowed to transmit 2 data packets.
   This continues until cwnd meets or exceeds ssthresh (or, in some
   implementations when cwnd equals ssthresh), or loss is detected.

   When the value of cwnd is greater than or equal to (or equal to in
   certain implementations) ssthresh the congestion avoidance algorithm
   is used to increase cwnd [Jac88] [Bra89] [Ste97].  This algorithm
   increases the size of cwnd more slowly than does slow start.
   Congestion avoidance is used to slowly probe the network for
   additional capacity.  During congestion avoidance, cwnd is increased
   by 1/cwnd for each incoming ACK.  Therefore, if one ACK is received
   for every data segment, cwnd will increase by roughly 1 segment per
   round-trip time (RTT).

   The slow start and congestion control algorithms can force poor
   utilization of the available channel bandwidth when using long-delay
   satellite networks [All97].  For example, transmission begins with
   the transmission of one segment.  After the first segment is
   transmitted the data sender is forced to wait for the corresponding
   ACK.  When using a GSO satellite this leads to an idle time of
   roughly 500 ms when no useful work is being accomplished.  Therefore,
   slow start takes more real time over GSO satellites than on typical
   terrestrial channels.  This holds for congestion avoidance, as well
   [All97].  This is precisely why Path MTU Discovery is an important
   algorithm.  While the number of segments we transmit is determined by
   the congestion control algorithms, the size of these segments is not.



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


   Therefore, using larger packets will enable TCP to send more data per
   segment which yields better channel utilization.

4.1.2 Fast Retransmit and Fast Recovery

   TCP's default mechanism to detect dropped segments is a timeout
   [Pos81].  In other words, if the sender does not receive an ACK for a
   given packet within the expected amount of time the segment will be
   retransmitted.  The retransmission timeout (RTO) is based on
   observations of the RTT.  In addition to retransmitting a segment
   when the RTO expires, TCP also uses the lost segment as an indication
   of congestion in the network.  In response to the congestion, the
   value of ssthresh is set to half of the cwnd and the value of cwnd is
   then reduced to 1 segment.  This triggers the use of the slow start
   algorithm to increase cwnd until the value of cwnd reaches half of
   its value when congestion was detected.  After the slow start phase,
   the congestion avoidance algorithm is used to probe the network for
   additional capacity.

   TCP ACKs always acknowledge the highest in-order segment that has
   arrived.  Therefore an ACK for segment X also effectively ACKs all
   segments < X.  Furthermore, if a segment arrives out-of-order the ACK
   triggered will be for the highest in-order segment, rather than the
   segment that just arrived.  For example, assume segment 11 has been