Enhancing TCP Over Satellite Channels using Standard Mechanisms
RFC 2488

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

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,