rfc2488.txt

RFC 的详细文档！

Network Working Group                                    M. Allman
Request for Comments: 2488            NASA Lewis/Sterling Software
BCP: 28                                                  D. Glover
Category: Best Current Practice                         NASA Lewis
                                                        L. Sanchez
                                                               BBN
                                                      January 1999

                 Enhancing TCP Over Satellite Channels
                       using Standard Mechanisms

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   The Transmission Control Protocol (TCP) provides reliable delivery of
   data across any network path, including network paths containing
   satellite channels.  While TCP works over satellite channels there
   are several IETF standardized mechanisms that enable TCP to more
   effectively utilize the available capacity of the network path.  This
   document outlines some of these TCP mitigations.  At this time, all
   mitigations discussed in this document are IETF standards track
   mechanisms (or are compliant with IETF standards).

1.  Introduction

   Satellite channel characteristics may have an effect on the way
   transport protocols, such as the Transmission Control Protocol (TCP)
   [Pos81], behave.  When protocols, such as TCP, perform poorly,
   channel utilization is low.  While the performance of a transport
   protocol is important, it is not the only consideration when
   constructing a network containing satellite links.  For example, data
   link protocol, application protocol, router buffer size, queueing
   discipline and proxy location are some of the considerations that
   must be taken into account.  However, this document focuses on
   improving TCP in the satellite environment and non-TCP considerations
   are left for another document.  Finally, there have been many
   satellite mitigations proposed and studied by the research community.
   While these mitigations may prove useful and safe for shared networks
   in the future, this document only considers TCP mechanisms which are



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


   currently well understood and on the IETF standards track (or are
   compliant with IETF standards).

   This document is divided up as follows: Section 2 provides a brief
   outline of the characteristics of satellite networks.  Section 3
   outlines two non-TCP mechanisms that enable TCP to more effectively
   utilize the available bandwidth.  Section 4 outlines the TCP
   mechanisms defined by the IETF that may benefit satellite networks.
   Finally, Section 5 provides a summary of what modern TCP
   implementations should include to be considered "satellite friendly".

2.  Satellite Characteristics

   There is an inherent delay in the delivery of a message over a
   satellite link due to the finite speed of light and the altitude of
   communications satellites.

   Many communications satellites are located at Geostationary Orbit
   (GSO) with an altitude of approximately 36,000 km [Sta94].  At this
   altitude the orbit period is the same as the Earth's rotation period.
   Therefore, each ground station is always able to "see" the orbiting
   satellite at the same position in the sky.  The propagation time for
   a radio signal to travel twice that distance (corresponding to a
   ground station directly below the satellite) is 239.6 milliseconds
   (ms) [Mar78].  For ground stations at the edge of the view area of
   the satellite, the distance traveled is 2 x 41,756 km for a total
   propagation delay of 279.0 ms [Mar78].  These delays are for one
   ground station-to-satellite-to-ground station route (or "hop").
   Therefore, the propagation delay for a message and the corresponding
   reply (one round-trip time or RTT) could be at least 558 ms.  The RTT
   is not based solely on satellite propagation time.  The RTT will be
   increased by other factors in the network, such as the transmission
   time and propagation time of other links in the network path and
   queueing delay in gateways.  Furthermore, the satellite propagation
   delay will be longer if the link includes multiple hops or if
   intersatellite links are used.  As satellites become more complex and
   include on-board processing of signals, additional delay may be
   added.

   Other orbits are possible for use by communications satellites
   including Low Earth Orbit (LEO) [Stu95] [Mon98] and Medium Earth
   Orbit (MEO) [Mar78].  The lower orbits require the use of
   constellations of satellites for constant coverage.  In other words,
   as one satellite leaves the ground station's sight, another satellite
   appears on the horizon and the channel is switched to it.  The
   propagation delay to a LEO orbit ranges from several milliseconds
   when communicating with a satellite directly overhead, to as much as
   80 ms when the satellite is on the horizon.  These systems are more



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


   likely to use intersatellite links and have variable path delay
   depending on routing through the network.

   Satellite channels are dominated by two fundamental characteristics,
   as described below:

      NOISE - The strength of a radio signal falls in proportion to the
      square of the distance traveled.  For a satellite link the
      distance is large and so the signal becomes weak before reaching
      its destination.  This results in a low signal-to-noise ratio.
      Some frequencies are particularly susceptible to atmospheric
      effects such as rain attenuation.  For mobile applications,
      satellite channels are especially susceptible to multi-path
      distortion and shadowing (e.g., blockage by buildings).  Typical
      bit error rates (BER) for a satellite link today are on the order
      of 1 error per 10 million bits (1 x 10^-7) or less frequent.
      Advanced error control coding (e.g., Reed Solomon) can be added to
      existing satellite services and is currently being used by many
      services.  Satellite error performance approaching fiber will
      become more common as advanced error control coding is used in new
      systems.  However, many legacy satellite systems will continue to
      exhibit higher BER than newer satellite systems and terrestrial
      channels.

      BANDWIDTH - The radio spectrum is a limited natural resource,
      hence there is a restricted amount of bandwidth available to
      satellite systems which is typically controlled by licenses.  This
      scarcity makes it difficult to trade bandwidth to solve other
      design problems.  Typical carrier frequencies for current, point-
      to-point, commercial, satellite services are 6 GHz (uplink) and 4
      GHz (downlink), also known as C band, and 14/12 GHz (Ku band).  A
      new service at 30/20 GHz (Ka band) will be emerging over the next
      few years.  Satellite-based radio repeaters are known as
      transponders.  Traditional C band transponder bandwidth is
      typically 36 MHz to accommodate one color television channel (or
      1200 voice channels).  Ku band transponders are typically around
      50 MHz.  Furthermore, one satellite may carry a few dozen
      transponders.

   Not only is bandwidth limited by nature, but the allocations for
   commercial communications are limited by international agreements so
   that this scarce resource can be used fairly by many different
   applications.








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


   Although satellites have certain disadvantages when compared to fiber
   channels (e.g., cannot be easily repaired, rain fades, etc.), they
   also have certain advantages over terrestrial links.  First,
   satellites have a natural broadcast capability.  This gives
   satellites an advantage for multicast applications.  Next, satellites
   can reach geographically remote areas or countries that have little
   terrestrial infrastructure.  A related advantage is the ability of
   satellite links to reach mobile users.

   Satellite channels have several characteristics that differ from most
   terrestrial channels.  These characteristics may degrade the
   performance of TCP.  These characteristics include:

   Long feedback loop

      Due to the propagation delay of some satellite channels (e.g.,
      approximately 250 ms over a geosynchronous satellite) it may take
      a long time for a TCP sender to determine whether or not a packet
      has been successfully received at the final destination.  This
      delay hurts interactive applications such as telnet, as well as
      some of the TCP congestion control algorithms (see section 4).

   Large delay*bandwidth product

      The delay*bandwidth product (DBP) defines the amount of data a
      protocol should have "in flight" (data that has been transmitted,
      but not yet acknowledged) at any one time to fully utilize the
      available channel capacity.  The delay used in this equation is
      the RTT and the bandwidth is the capacity of the bottleneck link
      in the network path.  Because the delay in some satellite
      environments is large, TCP will need to keep a large number of
      packets "in flight" (that is, sent but not yet acknowledged) .

   Transmission errors

      Satellite channels exhibit a higher bit-error rate (BER) than
      typical terrestrial networks.  TCP uses all packet drops as
      signals of network congestion and reduces its window size in an
      attempt to alleviate the congestion.  In the absence of knowledge
      about why a packet was dropped (congestion or corruption), TCP
      must assume the drop was due to network congestion to avoid
      congestion collapse [Jac88] [FF98].  Therefore, packets dropped
      due to corruption cause TCP to reduce the size of its sliding
      window, even though these packet drops do not signal congestion in
      the network.






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


   Asymmetric use

      Due to the expense of the equipment used to send data to
      satellites, asymmetric satellite networks are often constructed.
      For example, a host connected to a satellite network will send all
      outgoing traffic over a slow terrestrial link (such as a dialup
      modem channel) and receive incoming traffic via the satellite
      channel.  Another common situation arises when both the incoming
      and outgoing traffic are sent using a satellite link, but the
      uplink has less available capacity than the downlink due to the
      expense of the transmitter required to provide a high bandwidth
      back channel.  This asymmetry may have an impact on TCP
      performance.

   Variable Round Trip Times

      In some satellite environments, such as low-Earth orbit (LEO)
      constellations, the propagation delay to and from the satellite
      varies over time.  Whether or not this will have an impact on TCP
      performance is currently an open question.

   Intermittent connectivity

      In non-GSO satellite orbit configurations, TCP connections must be
      transferred from one satellite to another or from one ground
      station to another from time to time.  This handoff may cause
      packet loss if not properly performed.

   Most satellite channels only exhibit a subset of the above
   characteristics.  Furthermore, satellite networks are not the only
   environments where the above characteristics are found.  However,
   satellite networks do tend to exhibit more of the above problems or
   the above problems are aggravated in the satellite environment.  The
   mechanisms outlined in this document should benefit most networks,
   especially those with one or more of the above characteristics (e.g.,
   gigabit networks have large delay*bandwidth products).