RFC relevance of practice

As per Relevance of the word practice, we have this rfc below:

Network Working Group M.
Request for Comments: 2488 NASA Lewis/Sterling
BCP: 28 D.
Category: Best Current Practice NASA
L.

January 1999

Enhancing TCP Over Satellite
using Standard

Status of this

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

Copyright

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

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

1.

Satellite channel characteristics may have an effect on the
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
protocol is important, it is not the only consideration
constructing a network containing satellite links. For example,
link protocol, application protocol, router buffer size,
discipline and proxy location are some of the considerations
must be taken into account. However, this document focuses
improving TCP in the satellite environment and non-TCP
are left for another document. Finally, there have been
satellite mitigations proposed and studied by the research community
While these mitigations may prove useful and safe for shared
in the future, this document only considers TCP mechanisms which

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
compliant with IETF standards).

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

2. Satellite

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

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

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

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
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
square of the distance traveled. For a satellite link
distance is large and so the signal becomes weak before
its destination. This results in a low signal-to-noise ratio
Some frequencies are particularly susceptible to
effects such as rain attenuation. For mobile applications
satellite channels are especially susceptible to multi-
distortion and shadowing (e.g., blockage by buildings).
bit error rates (BER) for a satellite link today are on the
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
existing satellite services and is currently being used by
services. Satellite error performance approaching fiber
become more common as advanced error control coding is used in
systems. However, many legacy satellite systems will continue
exhibit higher BER than newer satellite systems and
channels

BANDWIDTH - The radio spectrum is a limited natural resource
hence there is a restricted amount of bandwidth available
satellite systems which is typically controlled by licenses.
scarcity makes it difficult to trade bandwidth to solve
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).
new service at 30/20 GHz (Ka band) will be emerging over the
few years. Satellite-based radio repeaters are known
transponders. Traditional C band transponder bandwidth
typically 36 MHz to accommodate one color television channel (
1200 voice channels). Ku band transponders are typically
50 MHz. Furthermore, one satellite may carry a few
transponders

Not only is bandwidth limited by nature, but the allocations
commercial communications are limited by international agreements
that this scarce resource can be used fairly by many
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
channels (e.g., cannot be easily repaired, rain fades, etc.),
also have certain advantages over terrestrial links. First
satellites have a natural broadcast capability. This
satellites an advantage for multicast applications. Next,
can reach geographically remote areas or countries that have
terrestrial infrastructure. A related advantage is the ability
satellite links to reach mobile users

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

Long feedback

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

Large delay*bandwidth

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

Transmission

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

Allman, et. al. Best Current Practice [Page 4]

RFC 2488 Enhancing TCP Over Satellite Channels January 1999

Asymmetric

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

Variable Round Trip

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

Intermittent

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

Most satellite channels only exhibit a subset of the
characteristics. Furthermore, satellite networks are not the
environments where the above characteristics are found. However
satellite networks do tend to exhibit more of the above problems
the above problems are aggravated in the satellite environment.
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).

3. Lower Level

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

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

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
ensure that the data link protocol does not limit TCP performance
In particular, data link layer protocols often implement a
control window and retransmission mechanisms. When the link
window size is too small, performance will suffer just as when
TCP window size is too small (see section 4.3 for a discussion
appropriate window sizes). The impact that link
retransmissions have on TCP transfers is not currently
understood. The interaction between TCP retransmissions and
level retransmissions is a subject for further research

3.1 Path MTU

Path MTU discovery [MD90] is used to determine the maximum
size a connection can use on a given network path without
subjected to IP fragmentation. The sender transmits a packet that
the appropriate size for the local network to which it is
(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
fragmented to a given channel along the network path, the
that would normally fragment the packet and forward the
will instead return an ICMP message to the originator of the packet
The ICMP message will indicate that the original segment could not
transmitted without being fragmented and will also contain the
of the largest packet that can be forwarded by the gateway
Additional information from the IESG regarding Path MTU discovery
available in [Kno93].

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

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

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

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

3.2 Forward Error

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

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

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

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
occur as frequently in terrestrial networks. Finally, FEC is
without cost. FEC requires additional hardware and uses some of
available bandwidth. It can add delay and timing jitter due to
processing time of the coder/decoder

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

4. Standard TCP

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

4.1 Congestion

To avoid generating an inappropriate amount of network traffic
the current network conditions, during a connection TCP employs
congestion control mechanisms [Jac88] [Jac90] [Ste97].
algorithms are slow start, congestion avoidance, fast retransmit
fast recovery. These algorithms are used to adjust the amount
unacknowledged data that can be injected into the network and
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
bound on the amount of data the sender can inject into the
before receiving an acknowledgment (ACK). The value of cwnd
limited to the receiver's advertised window. The congestion
is increased or decreased during the transfer based on the
amount of congestion present in the network. The second variable
the slow start threshold (ssthresh). This variable determines
algorithm is used to increase the value of cwnd. If cwnd is
than ssthresh the slow start algorithm is used to increase the
of cwnd. However, if cwnd is greater than or equal to (or
greater than in some TCP implementations) ssthresh the

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
receiver's advertised window size. Furthermore, the value
ssthresh is set when congestion is detected

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

4.1.1 Slow Start and Congestion

When a host begins sending data on a TCP connection the host has
knowledge of the current state of the network between itself and
data receiver. In order to avoid transmitting an
large burst of traffic, the data sender is required to use the
start algorithm at the beginning of a transfer [Jac88] [Bra89]
[Ste97]. Slow start begins by initializing cwnd to 1
(although an IETF experimental mechanism would increase the size
the initial window to roughly 4 Kbytes [AFP98]) and ssthresh to
receiver's advertised window. This forces TCP to transmit
segment and wait for the corresponding ACK. For each ACK that
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
implementations when cwnd equals ssthresh), or loss is detected

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

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

4.1.2 Fast Retransmit and Fast

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

TCP ACKs always acknowledge the highest in-order segment that
arrived. Therefore an ACK for segment X also effectively ACKs
segments < X. Furthermore, if a segment arrives out-of-order the
triggered will be for the highest in-order segment, rather than
segment that just arrived. For example, assume segment 11 has
dropped somewhere in the network and segment 12 arrives at
receiver. The receiver is going to send a duplicate ACK
segment 10 (and all previous segments).

The fast retransmit algorithm uses these duplicate ACKs to
lost segments. If 3 duplicate ACKs arrive at the data originator
TCP assumes that a segment has been lost and retransmits the
segment without waiting for the RTO to expire. After a segment
resent using fast retransmit, the fast recovery algorithm is used
adjust the congestion window. First, the value of ssthresh is set
half of the value of cwnd. Next, the value of cwnd is halved
Finally, the value of cwnd is artificially increased by 1 segment
each duplicate ACK that has arrived. The artificial inflation can
done because each duplicate ACK represents 1 segment that has
the network. When the cwnd permits, TCP is able to transmit
data. This allows TCP to keep data flowing through the network
half the rate it was when loss was detected. When an ACK for
retransmitted packet arrives, the value of cwnd is reduced back
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
data sent. When multiple segments are lost in a given window
data, one of the segments will be resent using fast retransmit
the rest of the dropped segments must usually wait for the RTO
expire, which causes TCP to revert to slow start

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

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

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

4.1.3 Congestion Control in Satellite

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

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
to obtain feedback from the receiver [All97] [AHKO97]. However,
algorithms are necessary to prevent congestive collapse in a
network [Jac88]. Therefore, the negative impact on a
connection is more than offset by the benefit to the entire network

4.2 Large TCP

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

throughput = window size /

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

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

Therefore, a single standard TCP connection cannot fully utilize,
example, T1 rate (approximately 192,000 bytes/second) GSO
channels. However, TCP has been extended to support larger
[JBB92]. The window scaling options outlined in [JBB92] should
used in satellite environments, as well as the companion
PAWS (Protection Against Wrapped Sequence space) and RTTM (Round-
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
connections each using a window of 65,535 bytes, as in the
example, can fully utilize a T1 GSO satellite channel

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

4.3 Acknowledgment

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

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
exceed 500 ms). The congestion window is increased based on
number of incoming ACKs and delayed ACKs reduce the number of
being sent by the receiver. Therefore, cwnd growth occurs much
slowly when using delayed ACKs compared to the case when the
ACKs each incoming segment [All98].

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

4.4 Selective

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

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

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

Mechanism Use Section
+------------------------+-------------+------------+--------+
| 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)
ensure the recommended mechanisms are supported in their stack
current and/or future versions. Alternatively, the
Supercomputer Center tracks TCP implementations and which
they support, as well as providing guidance on tuning various
implementations [PSC].

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

6. Security

The authors believe that the recommendations contained in this
do not alter the security implications of TCP. However, when using
broadcast medium such as satellites links to transfer user
and/or network control traffic, one should be aware of the
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,
performed successfully, could reveal critical traffic
information that would jeopardize the proper functioning of
network. These attacks could reduce the ability of the network
provide data transmission services efficiently. Eavesdroppers
also compromise the privacy of user data, especially if end-to-
security mechanisms are not in use. While passive monitoring
occur on any network, the wireless broadcast nature of
links allows reception of signals without physical connection to
network which enables monitoring to be conducted without detection
However, it should be noted that the resources needed to monitor
satellite link are non-trivial

Data encryption at the physical and/or link layers can provide
communication over satellite channels. However, this still
traffic vulnerable to eavesdropping on networks before and
traversing the satellite link. Therefore, end-to-end
mechanisms should be considered. This document does not make
recommendations as to which security mechanisms should be employed
However, those operating and using satellite networks should
the currently available network security mechanisms and choose
that meet their security requirements

This document has benefited from comments from the members of the
Over Satellite Working Group. In particular, we would like to
Aaron Falk, Matthew Halsey, Hans Kruse, Matt Mathis, Greg Nakanishi
Vern Paxson, Jeff Semke, Bill Sepmeier and Eric Travis for
useful comments about this document

[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP'
Initial Window", RFC 2414, September 1998.

[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann
TCP Performance Over Satellite Links. In Proceedings
the 5th International Conference on
Systems, March 1997.

[All97] Mark Allman. Improving TCP Performance Over
Channels. Master's thesis, Ohio University, June 1997.

[All98] Mark Allman. On the Generation and Use of
Acknowledgments. ACM Computer Communication Review, 28(5),
October 1998.

Allman, et. al. Best Current Practice [Page 15]

RFC 2488 Enhancing TCP Over Satellite Channels January 1999

[Bra89] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989.

[FF96] Kevin Fall and Sally Floyd. Simulation-based
of Tahoe, Reno and SACK TCP. Computer
Review, July 1996.

[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-
Congestion Control in the Internet. Submitted to
Transactions on Networking

[Flo94] S. Floyd, TCP and Successive Fast Retransmits.
report, October 1994.
ftp://ftp.ee.lbl.gov/papers/fastretrans.ps

[GJKFV98] Rohit Goyal, Raj Jain, Shiv Kalyanaraman, Sonia Fahmy
Bobby Vandalore, Improving the Performance of TCP over
ATM-UBR service, 1998. Sumbitted to
Communications

[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm
Technical Report, LBL, April 1990.

[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
High Performance", RFC 1323, May 1992.

[Jac88] Van Jacobson. Congestion Avoidance and Control. In
SIGCOMM, 1988.

[Kno93] Knowles, S., "IESG Advice from Experience with Path
Discovery", RFC 1435, March 1993.

[Mar78] James Martin. Communications Satellite Systems.
Hall, 1978.

[MD90] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.

[MM96] Matt Mathis and Jamshid Mahdavi. Forward Acknowledgment
Refining TCP Congestion Control. In ACM SIGCOMM, 1996.

[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "
Selective Acknowledgment Options", RFC 2018, October 1996.

[Mon98] M. J. Montpetit. TELEDESIC: Enabling The Global
Interaccess. In Proc. of the International
Symposium, May 1998.

Allman, et. al. Best Current Practice [Page 16]

RFC 2488 Enhancing TCP Over Satellite Channels January 1999

[MSMO97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The
Behavior of the TCP Congestion Avoidance Algorithm",
Computer Communication Review, volume 27, number3,
1997. available
http://www.psc.edu/networking/papers/papers.html

[Pos81] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981.

[PS97] Craig Partridge and Tim Shepard. TCP Performance
Satellite Links. IEEE Network, 11(5), September/
1997.

[PSC] Jamshid Mahdavi. Enabling High Performance Data
on Hosts. http://www.psc.edu/networking/perf_tune.html

[SMM98] Jeff Semke, Jamshid Mahdavi and Matt Mathis. Automatic
Buffer Tuning. In ACM SIGCOMM, August 1998. To appear

[Sta94] William Stallings. Data and Computer Communications
MacMillian, 4th edition, 1994.

[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance,
Retransmit, and Fast Recovery Algorithms", RFC 2001,
1997.

[Stu95] M. A. Sturza. Architecture of the TELEDESIC
System. In Proceedings of the International
Satellite Conference, 1995.

Allman, et. al. Best Current Practice [Page 17]

RFC 2488 Enhancing TCP Over Satellite Channels January 1999

Authors'

Mark
NASA Lewis Research Center/Sterling
21000 Brookpark Rd. MS 54-2
Cleveland, OH 44135

Phone: +1 216 433 6586
EMail: mallman@lerc.nasa.
http://roland.lerc.nasa.gov/~

Daniel R.
NASA Lewis Research
21000 Brookpark Rd
Cleveland, OH 44135

Phone: +1 216 433 2847
EMail: Daniel.R.Glover@lerc.nasa.

Luis A.
BBN
GTE
10 Moulton
Cambridge, MA 02140

Phone: +1 617 873 3351
EMail: lsanchez@ir.bbn.

Allman, et. al. Best Current Practice [Page 18]

RFC 2488 Enhancing TCP Over Satellite Channels January 1999

Full Copyright

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

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Allman, et. al. Best Current Practice [Page 19]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX