TCP Over Satellite Links : Problems and Solutions S. Oueslati-Boulahia, A. Serhrouchni, S. Tohmé ENST-Paris email : oueslati,ahmed,tohme@res.enst.fr ***** S. Baier, M. Berrada Laboratoires d'Electronique Philips S.A.S email : baier,berrada@lep-philips.fr 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.