OueXX (2)

TCP Over Satellite Links : Problems and Solutions
S. Oueslati-Boulahia, A. Serhrouchni, S. Tohmé
ENST-Paris
email : oueslati,ahmed,[email protected]
*****
S. Baier, M. Berrada
Laboratoires d'Electronique Philips S.A.S
email : baier,[email protected]
Abstract
Satellite communications are destined to play an important role in future telecommunications infrastructure, thus the increasing interest in transporting Internet trac
over satellite links. Many studies have shown that TCP has a poor performance in the
context of satellite communications. This is due to many factors inherent to satellite
communications and for which TCP originally designed for terrestrial networks is not adapted. Our study is an overview of the many factors limiting TCP performance over a satellite link and the dierent solutions proposed to address the problem.
KEY WORDS : satellite communication, long-delay channels, bandwidth asymmetry, TCP mechanisms, non-TCP mechanisms, performance.
1 Introduction
In the past years, satellite communication systems used to provide exclusively xed circuit
and television broadcast services. Today, the explosive use of the Internet is at the origin
of the increasing interest in addressing issues related to the transport of Internet trac
via satellite. The idea is to provide home and small corporate users with Internet access
through VSAT1 devices at a low cost. The satellite solution is all the more interesting, as
many of the current and growing data services (FTP, WEB, MBONE) are highly asymmetric in terms of bandwidth requirements2 . Satellite systems are of particular interest
in this case because of their inherent capability to address an extremely large community
of users. Provided that intelligent uplink multiple access schemes are devised, satellite
communication systems are capable of achieving high revenues at low cost to individual
subscribers. It seems therefore very likely that TCP/IP will have to be used over satellite links. Yet, many factors specic to satellite communications adversely aect TCP
mechanisms, thereby yielding to poor performance.
The present work presents a twofold survey. The rst part points out the most important factors limiting TCP performance over satellite links and the TCP mechanisms
aected. The second part covers the proposed solutions to improve TCP performance in
the framework of asymmetric bandwidth satellite networks with end users directly accessing the satellite upstream channel3 (see g 2). The advisability of each solution will also
be discussed in this part.
Very Small Aperture Terminal
i.e. low bandwidth from the consumer to the information provider and relatively high bandwidth
toward the consumer.
3
In hybrid satellite networks, the upstream path may use a terrestrial channel.
1
2
1
2 Factors limiting TCP performance and mechanisms aected
This section is an overview of the several factors specic to satellite communications and
for which TCP - originally designed for terrestrial networks - is inadequate. For each
limiting factor, we shall indicate which TCP mechanisms are adversely aected.
2.1 Long propagation delay
The long propagation delay, characteristic of geosynchronous satellites, seriously limits
TCP performance. Long-delay channels require larger windows than what standard TCP
oers, and a more accurate Round Trip Time (RTT) evaluation. In addition, cumulative
ACKs and delayed ACKs are not particularly suited for long-delay satellite environment.
Finally, Slow Start and Congestion Avoidance prove to be rather inecient in the presence
of long propagation delays. The following subsections detail each of these points.
2.1.1 Window size
Sender
Transmission Time
Receiver
1
2
3
1
4
2
3
Wait Time
ack 1+2
4
5
Time
Figure 1: Sequence of TCP segment transmission over a satellite link
The TCP receiver's window size is very important because throughput is upper bounded
by the RTT value, regardless of the channel capacity, as :
Buffer Size
ThroughputMax = ReceiverRTT
With a 560 ms RTT (double satellite hop), and a Receiver Buer Size of 64 Kbytes (Maximum authorized value in Standard TCP), the throughput tops out at about 936 Kbps.
Figure 1 represents the transmission, over a satellite link, of a sequence of TCP segments
within a window of information. The gure shows that time to acknowledge a segment is
longer than the time required to transmit segments allowed by the ow control window.
The connection between TCP end points can be viewed as a pipe, and the delay*throughput
product represents the amount of data actually in transit in this pipe. The throughput is
the measure of the amount of data owing through the connection per unit of time. The
delay*bandwidth product measures the amount of unacknowledged data that TCP must
handle in order to keep the pipe full; it is the window that should be advertised by the
receiver to obtain maximum throughput on the TCP connection. With a 560 ms RTT
and a T1 downstream link (1.536 Mbps), 110 Kbytes of data can be in transit before the
acknowledgment of the rst segment of the window arrives. This is much more than what
most TCP implementations allow. Besides, even if the window scale option specied in
RFC 1323 is implemented, it is up to the application layer to take advantage of a large
window. Many applications in use do not. For instance, Unix FTP typically advertises
windows between 4 and 24 Kbytes.
2.1.2 Round-Trip measurement
TCP handles possible losses of data segments and ACKs by setting a timeout for each
segment sent. If the timer expires before receiving an ACK that covers this segment, the
segment is retransmitted. Fundamental to TCP timeout and retransmission strategy is
the measurement of the Round-Trip Time4 (RTT), according to which the Retransmission
TimeOut (RTO) is modied. While the original method, recommended in RFC 793, for the
calculation of the (RTO) used a multiple of the smoothed RTT, Jacobson's calculation [14]
of the RTO depends on both the smoothed RTT and the smoothed mean deviation.
An appropriate estimate of the RTO is capital to the congestion avoidance and control
strategy; if it is too short it results in unnecessary retransmissions, and if it is too long it
leads to a waste of bandwidth. Most current TCP implementations basically measure only
one RTT per window. While this is acceptable for small windows (with no more than eight
segments as it is reported in RFC 1072), it may yield to a poor estimate for larger windows
as it is the case in satellite communications. Consequently, in the satellite environment,
more accurate evaluations are required.
A new RTT evaluation mechanism has been proposed in RFC 1323. It uses a "timestamps" option which allows the sender to calculate an RTT for each received ACK, thereby
yielding to better RTT estimates.
2.1.3 Cumulative ACKs
Given the long delays experienced on satellite links it takes a long time for cumulative
acknowledgments to inform the sender about segment loss, especially when multiple packets
are lost from one window. Indeed, due to the limited information available from cumulative
ACKs, a TCP sender can only learn about a single lost packet per RTT. If all segments
queued on the receiver side because received out of order form a single contiguous bloc,
then no further loss was experienced. Otherwise, the sender will have to retransmit the
remaining segments.
A Selective ACKnowledgment (SACK) mechanism combined with a selective repeat
retransmission policy, was dened in RFC 2018. It provides more accurate information
about which segments should be retransmitted.
2.1.4 Slow Start and Congestion Avoidance
Slow Start is used to gradually increase the rate at which the sender injects data into the
network. Initially, a single segment is sent. Then, two segments are injected by the sender
for each received ACK, leading to an exponential increase in the size of the ow control
window on a RTT-time base5 . TCP remains in Slow Start mode till either :
the receiver advertised window is reached, or
The RTT is the elapsed time between sending a byte with a particular sequence number and receiving
an ACK that covers that sequence number.
5
although it is not exactly exponential because the receiver may delay its ACKs, typically sending one
ACK for every two segments that it receives.
4
a loss is detected, in which case TCP reenters Slow Start mode from the beginning,
or
the packet sending rate is one half the rate at which the last loss occurred; Congestion
Avoidance, then, takes over.
Congestion Avoidance is used to probe the network for available bandwidth by sending
one additional segment for each RTT, up to the receiver advertised window. If a loss is
detected, then TCP falls back into Slow Start mode.
Because the amount of time required for Slow Start and Congestion Avoidance to
complete is a function of the round-trip time, satellite links are particularly sensitive to
the limited throughput available during both phases.
2.1.5 Delayed ACKs
Normally TCP does not send an ACK directly following data reception. Instead, the ACK
is delayed hoping to send it along with data going in the same direction, especially in the
case of interactive applications. Most implementations use a 200-ms timer which goes o
at xed times relative to when the kernel was bootstrapped. TCP sends an ACK only if
the timer expires or if it receives a second segment. One ACK is then sent for every two
segments received.
Although delayed ACKs spare bandwidth and reduce protocol processing overhead by
avoiding the transmission of redundant ACKs, they slow down the ACK ow rate already
slow in the satellite environment (see next section) on the return path, and they roughly
double the time for Slow Start and Congestion Avoidance to complete. This adds to the
ineciency reported in the previous subsection of both mechanisms.
2.2 Asymmetry of the connection
Bulk data packets
Web server
ACKs + Requests
Internet
...
G
Gateway
End users
FTP server
Uplink (64 Kbps)
Downlink (1 Mbps)
Figure 2: Example of an asymmetric bandwidth satellite network
As we have already mentioned in the introduction, satellite communications are very
often used to provide asymmetric bandwidth services that are intended for large-scale information consumption6 . Typical Internet applications (e.g. FTP, WEB) require relatively
6
In asymmetric satellite networks used today, satellites are found at the edges of the Internet and
provide the end users with a shared access to the Internet.
low bandwidth from the user to the information provider (e.g. FTP or HTTP server)
and relatively high bandwidth towards the user. Figure 2 depicts an asymmetric satellite
network where end users directly access the Internet via a shared upstream channel. In
this conguration the return path carries requests (e.g. FTP or HTTP commands) and
acknowledgments (ACKs) for the responses received on the forward path (bulk data, e.g.
FTP les or Web documents). Yet, the strong asymmetry observed has a non negligible
eect on the TCP self clocking paradigm. TCP is self clocking, i.e., the source sends a
Symmetric links
Asymmetric links
Time 1
Time1
1
Time 35
1
1
1
Time 6
ack 1
ack 1
Time 10
Time 12
3
2
Time 16
16
ack 9
15
14
ack 10
11,12,13
17
ack 10
16
ack 11
12,13,14,15
18
ack 11
17
ack 12
13,14,15,16
Time 41
Time 8
ack 1
ack 1
10,11
Time 39
Time 5
Time 8
13 12
ack 9
Time 37
Time 4
Time 4
15 14
ack 8
2
Time 11
3
2
Time 17
ack 2
ack 2 ack 3
ack 3
Time 19
Time 20
7
6
5
4
ack 3
4
Time 22
7
Time 24
ack 4 ack 5 ack 6 ack 7
6
ack 4
14
13
12
ack 8 ack 9ack10ack11
4
Time 26
Time 34
15
5
ack 5
6,7
Bandwidth
Time 30
10
9
ack 6
8
ack 7
Time
Figure 3: Comparison of Slow Start mechanism in symmetric and asymmetric congurations
new packet only when it receives an ACK for an old one, thus the rate at which the source
injects new packets matches the rate at which the ACKs are returned by the other end.
This feature fundamental to TCP congestion control strategy implies that the throughput on the downstream is controlled by the rate of the ACK ow on the upstream. While
this is convenient for symmetrical congurations, it yields, in case of strong asymmetry, a
decrease in throughput for the following reasons :
A lower rate of incoming ACKs slows down the Slow Start and congestion avoidance
phases;
Congestion may occur on the receiver side, delaying the ACKs and possibly triggering
unnecessary retransmissions. Congestion occurs when the asymmetry ratio (Return
path capacity to Forward path capacity ) is higher than the ratio of ACK packet size
to Bulk data packet size 7 .
7
The bulk data packet size depends on the MSS (Maximum Segment Size) value to which is added the
TCP and IP overhead (40 bytes). The ACK packet size is 40 bytes.
Figure 3 is an illustration of the TCP self clocking principle. In this example the
forward path has twice as much bandwidth as the return path. For simplicity purpose
we assume that the ACK packets have the same size than bulk data packets. Let the
receiver advertised window be 8 segments. The example shows that, in the symmetric
conguration, Slow Start completes, i.e., the receiver maximum window size is reached,
after 27 time units, instead of 33 time units in the asymmetric case. The example also
shows ACK congestion on the receiver side. Finally, the example illustrates how does the
ACK ow rate command the packet sending rate on the forward path.
2.3 Errors in the satellite environment
Space communication links are subject to bit errors, though the bit error rate may signicantly vary depending on link parameters such as the frequency band used 8 . In addition,
errors often occur in bursts. Typical bit error rate for satellite links today are on the order
of 10?7 , or better [2].
TCP's strategy for error detection and recovery is not suited to the satellite communication environment. First, TCP needs to wait for a whole retransmit timeout to realize
that a segment is lost. Second, TCP assumes that every time a packet loss occurs, it is
due to congestion. While this may hold for terrestrial networks, it may cause congestion
control mechanisms to be unduly triggered, thereby resulting in a throughput degradation.
Both problems are partially addressed by the Fast Retransmit and Fast Recovery algorithms 9 which are supposed to work together. Once a packet is lost, duplicate ACKs
of the lost packet which should not be delayed will be received by the data sender.
The reception of several duplicate ACKs in a short lapse of time is a strong indication of
the absence of congestion. Consequently, upon the reception of the third duplicate ACK,
the lost packet is retransmitted without having to wait for the retransmit timer to expire.
When the Fast Retransmit detects the loss, TCP normally enters the Fast Recovery mode,
instead of the Slow Start mode. Fast recovery halves the data sending rate and begins
congestion avoidance immediately, without falling back to Slow Start.
Nevertheless, the Fast Retransmit and Fast Recovery mechanisms prove to be rather
inecient under certain circumstances. First, in case of multiple losses in the same window,
the Fast Recovery retransmits at most one segment per RTT, thus left errors will be
detected by timeouts, causing TCP to fall back into the Slow Start mode. On the other
hand, if the return path is highly constrained10 , as it may happen in typical satellite
asymmetric congurations, the retransmit timer may run out before the reception of the
third duplicate ACK, preventing TCP from entering Fast Retransmit.
3 Solutions for TCP over satellite
This second part of the survey describes dierent solutions proposed in order improve TCP
performance over satellite links. A possible classication of the solutions distinguishes :
solutions that attempt to extend standard TCP to the satellite communication environment, through the use of additional mechanisms and options, or the modication
of the existing ones.
solutions that do not require any modications of the TCP/IP protocol stack. One
approach is to "actively break TCP semantics at an intermediate node in the network". This approach, called spoong, attempts to counteract the negative eect of a
Ku and Ka bands are very sensitive to atmospheric weather conditions and electrostatic charge.
For a detailed description of theses algorithms, see [18] and RFC 2001
10
entailing a low ACK rate
8
9
given TCP mechanism while maintaining an end-user standard TCP implementation.
In hybrid architectures a spoong technique consists in isolating, in a transparent
way, the satellite link from the rest of the network. TCP performance issues for this
particular type of network topology are out of the scope of this paper, see [5, 8, 19]
for a thorough study.
An other approach consists in using non-TCP mechanisms which operate at a given
layer of the OSI model. In the remainder of this paper, an application level solution
and a link layer solution are examined. Other solutions at other levels have been proposed; for instance [2] recommends the use of the "Path MTU Discovery" mechanism
(Network layer mechanism) which allows TCP to use the largest possible packet size.
3.1 TCP extensions for enhanced performance
This section presents extensions/modications that were proposed to adapt TCP to satellite communication systems.
3.1.1 TCP Window scale option
This option was proposed in RFC 1323 to solve the window size limit problem, described
in section. This option denes an implicit scale factor, which when applied to the window
size value found in the 16-bit window eld of the TCP header, expands the denition of
the TCP window size to 32 bits.
However, expanding the window size to match the requirements of long-delay satellite
links increases the probability of packet loss per window. We already saw that Fast Retransmit and Fast Recovery eciently handle one packet loss per window, while multiple
losses typically disable their benecial eect.
3.1.2 TCP timestamps option
This option was dened in RFC 1323, in part to address the problem of the round-trip measurement problem reported in section. A mechanism using this option is specied; it allows
nearly every segment, including retransmissions, to be timed at negligible computational
cost.
The sender places a timestamp in each data segment, and the receiver echoes these
timestamps back in ACK segments. Then a single abstract provides the sender with an
accurate RTT measurement for every ACK segment. Notice that a one-to-one correspondence between data segments and ACK ones is not a necessary condition. In case of delayed
ACKs, the TCP receiver should reect the timestamp of the earliest unacknowledged segment. Indeed, an inated RTT measurement is preferable to a too short estimate, which
may trigger spurious retransmissions.
3.1.3 Combined eect of Fast Retransmit/Fast Recovery mechanism and SACK
We have already mentioned that the Fast Retransmit/Fast Recovery mechanism has a
benecial eect over TCP performance in the absence of congestion, as long as no more
than one drop is experienced in the same window. To generalize the Fast Retransmit/Fast
Recovery mechanism to handle multiple packet drops per window, Selective ACKnowledgments (SACK) are of great help. Compared to the normal cumulative acknowledgment,
SACKs provide the sender with a much more accurate vision of which packets have been
received and queued at the receiver side, and which have not still arrived. Consequently,
more than one missing packet can be retransmitted within a round-trip time, preventing
timeouts from occurring, hence the pipe from draining and TCP from reentering Slow
Start.
Each contiguous block of data queued at the receiver is dened in the SACK option by
two 32-bit unsigned integers representing the left and right edges of the block, so the 40
bytes available for TCP options can specify a maximum of 4 blocks11 .
The following rules extracted from RFC 2018 apply to the SACK option :
The SACK option will always report the block containing the most recently received
segment, in order to provide the sender with the most up-to-date information;
The SACK option should be lled out by repeating the most recent SACK blocks.
This assures that, in normal operation, any missing segment part of a non-contiguous
sequence space is reported in at least three successive SACK options.
It is important to notice that TCP implementations that use normal cumulative acknowledgments, are constrained to either retransmit at most one dropped packet per RTT
(e.g. Reno TCP), or to adopt an aggressive early retransmission strategy yielding to the
retransmission of packets that might have been successfully delivered (e.g Tahoe TCP).
Many studies showed evidence in favor of SACK [9]. In the particular case of satellite
communications, [16] examines the eectiveness of selective acknowledgment for dierent
bit error rates. Simulation results show that the addition of SACKs to the standard
TCP Reno greatly improve throughput relative to TCP Reno without SACK, for bit error
rates 12 of 10?7 .
However, the latter results were obtained for full-duplex symmetric satellite links. In
an asymmetric conguration, with a slow ACK ow rate, the SACK option may be useless
if TCP can not enter Fast Recovery due to the occurrence of timeout before the arrival of
the third duplicate ACK. Further work needs to be done in this direction.
3.1.4 Slow Start and Congestion Avoidance adaptations
We briey present in the following, the dierent modications that were proposed to enhance TCP performance.
Slow Start
Larger initial windows accelerate the opening of the congestion window by saving
a few RTTs and eliminating a delayed ACK timeout during the initial Slow Start
phase. This is of particular benet in long-delay environments and for short-lived
TCP connections13 .
Floyd in [12] suggests an initial window size of roughly 4 Kbytes14 , instead of one
segment. This change would only apply at the beginning of the connection, in the
rst round trip time, i.e, if TCP re-enters Slow Start after a retransmit timeout, the
congestion window is re-initialized to one segment.
In [1] larger initial windows are shown to improve TCP performance over satellite
channels. This study shows a 27% throughput increase, using the 4 segment initial
window suggested by Floyd, for 30 Kbyte FTP transfers, and a 180% throughput
increase, using a 32 segment initial window. However, these experiments were carried
11
The SACK option is expected to be used in conjunction with the timestamp option, which takes 10
bytes, thus a maximum of 3 SACK blocks will be allowed in this case.
12
Typical bit error rates for satellite links are on the order of 10?7 .
13
Larger initial windows will allow many email and web page transfers (smaller than 4Kbytes) to complete
within a single RTT.
14
More precisely, the initial window size would be that given in : min(4*MSS, max(2*MSS,4380 bytes))
out in the absence of competing trac. Further work needs to be done in order to
study the impact of larger initial windows on other competing connections.
The window increase algorithm needs to be slightly modied to oset the negative
eects of delayed ACKs, which reduce by half the ACKs' ow rate, hence the congestion window growth. TCP's window increase algorithm should take into account
the number of new segments covered by the ACK rather than the number of ACKs
received. This modication was also evaluated in [1]. The study shows a throughput
improvement of up to 15% (depending upon transfer size) as compared to standard
TCP.
The Slow Start threshold estimation Hoe [13] suggests that the initial Slow Start
threshold value15 be determined using both the the RTT and the available bandwidth of
the bottleneck link in the network between the sender and the receiver. The exact formula
combining both values is given in [13]. The idea is to detect, according to current network
conditions, the right time for TCP to switch from Slow Start to Congestion Avoidance.
Recent work [17] pointed out problems in the mechanism proposed by Hoe used to determine the available bandwidth. Further studies remain to be done before recommending
a widespread implementation.
Congestion Avoidance Much work have been done to improve Congestion avoidance al-
gorithms in order to use at best the available network bandwidth. The proposed algorithms
are either based on feedback (Random Early Detection (RED) [10], Explicit Congestion
Notication (ECN) [11], ATM-ABR service class) signals from the network or on network
responses to variations in source behavior. In the second case, mainly two adjustments
methods are used to control the amount of data sent into the network : rate-based and
window-based [15, 20, 6, 21]. The rate-based scheme regulates the inter-packet sending
time, while the window-based scheme operates by increasing or decreasing the window
size.
Two approaches can be distinguished for the latter scheme : delay-based (based on the
estimation of the RTT) and throughput-based (based on the estimation of the throughput). Both approaches can be interesting for satellite communications, because increasing
the congestion window by one segment every RTT (normal Congestion Avoidance algorithm) is very penalizing for TCP in long-delay environments. Consequently, the window
increase/decrease algorithm must not only consider the number of RTT that have passed,
but also the RTT value or an estimation of the available bandwidth.
Finally, in [7] a general undesirable eect on congestion avoidance algorithms based on
RTT estimation is reported when the backward path (ACK path) is highly constrained;
a typical situation in satellite communications. The authors propose to change these
algorithms by dividing the round trip time into a Forward Trip Time and a Backward Trip
Time. Simulation results show performance improvement using this distinction.
Further work needs to be done to validate all these propositions in the particular
environment of satellite communications.
3.2 XFTP : example of an application level solution
XFTP is a modied version of FTP using multiple simultaneous TCP connections; a large
virtual window can then be simulated. XFTP is specied in [4]. Experimental results in [1]
show the existence of an optimal number of connections allowing an optimized version of
15
The size of the window which once achieved, TCP should leave Slow Start and enter Congestion
Avoidance
XFTP to achieve approximately 90% (without overhead) of a satellite T1 link16 against a
maximum utilization of approximately 23% with a single TCP connection17 . Compared to
standard FTP, XFTP introduces the following modications :
A virtual initial window size of N segments instead of 1, where N is the number of
simultaneous TCP connections;
A virtual maximum window of N WMax , where WMax is the advertised receiver
window;
During Slow Start and Congestion Avoidance, the virtual window grows N times
faster;
Provided that a single loss is experienced per connection, multiple losses can be better
handled with XFTP, since losses are distributed between the N connections.
When one of the N connections experiences a loss, the degradation in throughput
incurred is limited to the connection of interest.
However, when XFTP uses too many connections, massive losses happen due to an
increased aggressiveness in data transmission. Besides, XFTP requires an additional complexity at both ends allowing a le to be divided between multiple data connections.
The authors of this study qualify XFTP as an "interim" solution to TCP inadequacies over satellite channels. The ultimate goal was to provide valuable insights into new
mechanisms to help TCP better utilize satellite channels. The lessons learned from XFTP
include the need for larger windows, selective ACKs and more aggressive Slow Start and
Congestion Avoidance mechanisms.
3.3 Link layer solutions
The idea behind this type of solutions is to detect and correct bit errors at the link layer in
a transparent way for the transport layer. This will spare TCP the triggering loss recovery
mechanisms and the loss in throughput they induce.
Error control schemes may be broadly classied as Forward Error Correction (FEC) or
Automatic Repeat Request (ARQ) protocols.
In an ARQ (Automatic Repeat Request) scheme, the information is segmented into
packets to which are attached check symbol, usually through CRC computing. This
allows the data receiver to detect erroneous packets and ask for retransmission.
In a FEC (Forward Error Correction) scheme, redundant blocks are added to information blocks, enabling the data receiver to detect and correct errors.
The choice of an error control technique depends mainly on the bit error rate. However,
other factors should also be considered such the propagation delay and the availability
of resources. For high lossy links, the FEC approach with high redundancy will spare
TCP multiple retransmissions, as compared to the ARQ approach. For low error bit rate
channels, ARQ might prove more ecient since it requires less overhead than FEC to
perform equivalent error control.
As for TCP mechanisms, long delays inherent to satellite communications negatively
impact the ARQ error control mechanism, yielding poor performance. Sophisticated ARQ
protocols with available feedback channel and buering capabilities have to be used otherwise. This, led to a widespread use of FEC methods for satellite communications. Recently,
16
17
192,000 bytes/s
The advertised window is 24 Kbytes and the RTT value is 560 ms.
the FEC scheme has been recommended in [2] for use in networks containing satellite channels.
Notice, that as link layer retransmission approach handles packet corruption independently of the transport protocol layer, interference may happen resulting in degraded
performance. One reason for this is that the link layer approach may aect the order in
which packets are delivered, thus triggering TCP loss recovery mechanisms. Consequently,
a tight coupling between the retransmission policies at the transport and link layers is
desirable for enhanced performance.
4 Conclusion
In the rst part of this paper, we outlined TCP inadequacies in the context of satellite
communications. The most limiting factors inherent to geostationary satellites appear to
be the long propagation delay and the asymmetric nature of the connection. The most
aected mechanisms are the timeout and retransmission mechanisms on the one hand (not
accurate enough), and the window increase algorithms during Slow Start and Congestion
avoidance phases on the other hand (too conservative).
In the second part, we covered some possible solutions to enhance TCP performance
over satellite links, when these are directly accessed by terminals. As far as TCP extensions
are concerned, we believe that the addition of the "Window" Scale, the "Timestamp" and
the SACK options should open the way to other modications of TCP. Window increase
algorithms, unbiased against long propagation delays, should also be tested and introduced.
Work on enhancing TCP over satellite channels is ongoing; for a complete overview of all
mechanisms likely to enhance TCP performance, refer to the latest Internet draft [3] dealing
with TCP research related to satellites.
Finally, intelligent resource allocation schemes on the upstream link may help better
utilize the available bandwidth on the downstream link, by reducing the negative eects
of a highly asymmetric conguration.
References
[1] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis,
Ohio, June 1997.
[2] Mark Allman and Dan Glover. Enhancing TCP Over Satellite Channels Using Standard Mechanisms. Internet Draft, October 1997. draft-ietf-tcpsat-stand-mech-00.txt.
[3] Mark Allman and Dan Glover. Ongoing TCP Research Related to Satellites. Internet
Draft, November 1997. draft-ietf-tcpsat-res-issues-00.txt.
[4] Mark Allman and Shawn Ostermann. Multiple Data Connection FTP Extensions.
Technical Report TR-19971, Ohio University, Febuary 1997.
[5] Eric Anvar. An Overview of TCP over Satellite and Wirless Links. Rapport de stage
3eme annee, ENST Paris, June 1997.
[6] L.S. Brakmo and S.W. O'Malley. TCP Vegas : New Techniques for Congestion Detection and Avoidance. In SIGCOMM Conference on Communications Architectures
and Protocols, London, pages 2435, October 1994.
[7] O. Elloumi, H. A, and M. Hamdi. Improving CongestionAvoidance Algorithms for
Asymmetric Networks. In ICC'97, Montreal, volume 3, pages 14171421, June 1997.
[8] A.D. Falk. A System for Hybrid Network Data Communications Terminal Using
Asymmetric TCP/IP to Support Internet Applications. Master's thesis, Ohio University, 1994.
[9] Kevin Fall and Sally Floyd. Simulation-based Comparisons of Tahoe, Reno, and
SACK TCP. Computer Communications Review, July 1996.
[10] S. Floyd and V. Jacobson. Random Early Detection Gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, 1:397413, August 1993.
[11] Sally Floyd. TCP and Explicit Congestion Notication. ACM Computer Communication Review, 24:823, October 1995.
[12] Sally Floyd and Mark Allman. Increasing TCP's Initial Window. INTERNET
DRAFT, July 1997.
[13] Janey C. Hoe. Improving the Start-up Behaviour of a Congestion Control Scheme for
TCP. In ACM SIGCOMM, August 1996.
[14] V. Jacobson. Congestion Avoidance and Control. Computer Communication Review,
18(4):314329, August 1988.
[15] Raj Jain. A Delay-Based Approach for Congestion Avoidance in Interconnected Heterogeneous Computer Networks. ACM Computer Communication Review, 19:5671,
October 1989.
[16] Hans Kruse Mark Allman, Chris Hayes and Shawn Ostermann. TCP Performance
over Satellite Links. In 5th International Conference on Telecommunication Systems,
March 1997.
[17] Vern Paxson. End-to-End Internet Packets Dynamics. In ACM SIGCOMM'97 Conference, Cannes, September 1997.
[18] W. Richard Stevens. TCP/IP Illustrated Volume 1 The Protocols. Addison-Wesley,
1994.
[19] J.S. Baras V. Arora, N. Suphasindhu and D. Dillon. Asymmetric Internet Access over
Satellite-Terrestrial Networks. Technical Report CSHCN TR 96 10, Ohio University,
1996.
[20] Z. Wang and J. Crowcroft. A New Congestion Control Scheme : Slow Start and Search
(Tri-S). ACM Computer Communication Review, 21:3243, January 1991.
[21] Z. Wang and J. Crowcroft. Eliminating Periodic Packet Losses in the 4.3-Tahoe BSD
TCP Congestion Control Algorithm. ACM Computer Communication Review, 22:9
16, April 1992.