22nd AIAA International Communications Satellite Systems Conference & Exhibit 20049 -12 May 2004, Monterey, California

ABSTRACTWe recommend suitable transport protocols for anaeronautical network supporting Internet and dataservices via satellite. We study the characteristics of anaeronautical satellite hybrid network and focus on theproblems that cause dramatically degraded performanceof the Transport Protocol. We discuss variousextensions to standard TCP that alleviate some of theseperformance problems. Through simulation, we identifythose TCP implementations that can be expected toperform reasonably well. Based on the observation thatit is difficult for an end-to-end solution to solve theseproblems effectively, we propose a new TCP-splittingprotocol, termed Aeronautical Transport ControlProtocol (AeroTCP). The main idea of this protocol isto use a fixed window for flow control and oneduplicated acknowledgement (ACK) for fast recovery.Our simulation results show that AeroTCP can maintainhigher utilization for the satellite link than end-to-endTCP, especially in high BER environment.

1 INTRODUCTIONThe popularity of Internet and mobile communicationover the past decade has prompted for the provision ofInternet and other infotainment services to airlinepassengers. Broadband aeronautical communication hasbecome one of the hot topics in the communicationworld. This is mainly due to the fact that aircraft seemto be one of the last remaining islands where personalcommunications and Internet access are not available.Inspired by the big market and business opportunity,many investigations and commercial activities are beingdeveloped in this direction [1].

To make "E-mail and Internet above the clouds"possible, broadband communications with high bit ratehave to be provided to aircraft. In an aeronauticalscenario, global coverage is essential for providingcontinuous services. Recognizing the potential forsignificant improvements in over-ocean coverageafforded by the use of satellite technology foraeronautical communications, the airline industry isdeveloping a design for a global satellite-basedcommunications system to meet the needs of theaviation industry [2].

Copyright C 2004 by !he Am8rican InstlMe of Aeronautica end Astroneutica. Inc. All righ18 ~~

TRANSPORT PROTOCOL SUPPORT FOR AERONAUTICAL SATELLITE

Yadong Shang, Michael Hadjitheodosiou. John BarasCenter for Satellite & Hybrid Communication NetworksInstitute for Systems Research, University of Maryland,

College Park, MD 20742, USAshangyd@~lue.umd.edu. michalis@isr.umd.edu. baras@isr.umd.edu

AIAA 2004-3171

COMMUNICATIONS

Several Companies (e.g., Inmarsat, Iridium, Connexionby Boeing) have announced plans to use satellitetechnologies to provide commercial broadband dataservices for airline passengers [3, 4]. These systems areexpected to offer Internet access and to support virtualprivate networks (VPN) for passengers in flight.However, the performance of data communicationsprotocols and applications over such systems is thesubject of heated debate in the research community,especially the transport protocol in the Internet TCP/IPprotocol suite [5]. Some researchers insist that TCP willwork suitably in a satellite environment, while othershave suggested satellite specific protocol options forimproved performance, and still others claim that TCPcannot work effectively over satellite channels.

In this paper, we will evaluate how well TCP performsin aeronautical satellite networks. The remainder of thepaper is organized as follows: in section 2, we discussthe future aeronautical satellite systems that plan toprovide Internet access for passengers, focus on thespecial characteristics of aeronautical satelliteenvironment that impact transport layer protocolperformance. In section 3, we describe various TCPflavors and TCP extension that alleviate some of TCPperformance problems in satellite environment.Through analysis and simulation, we identify thoseTCP implementations that can be expected to performreasonably well for Internet applications in satellitenetworks. Based on the observation that it is difficultfor an end-to-end solution to solve the performanceproblems effectively in the satellite hybrid networks,we next investigate in section 4 the improvement byusing TCP splitting protocol in satellite gateway. Weproposed a new splitting based TCP protocol forsatellite connection, which we called AeroTCP. Thisnew protocol uses a fixed window for congestioncontrol and flow control, use one duplicated ACK forfast recovery. Based on the simulation result, weconclude that our splitting protocol has significantimprovement over end-to-end TCP solution in term oflink utilization and response time. This AeroTCP is thesuitable transport protocol for the future aeronauticalsatellite networks.

A m..ri"An Tnctit"t.. nf A ..rnnA"ti"c Anlf A ctrnnA"ti"c

2 AERONAUTICAL SATELLITENETWORKS

GfO(MEO) Sp8C8 S8gm8nt

K8~~~ ..,...

Figure I Aeronautical Satellite Network

The future aeronautical satellite systems will offerInternet connections at up to broadband (tens of Mbps)data rates via networks of GEO or LEO satellites [6].Here, we consider architecture based on packetswitching network that is fully compatible with theTCP/IP protocol suite. Figure I illustrates the generaltopology, in which users on aircraft access the Internetvia the satellite system.

This system will be composed of three major segments:cabin segment with on-board networks, space segmentfor interconnection of the cabin with the terrestrialnetworks, ground segment which provides theinterconnection to the terrestrial personal and datanetworks as well as the Internet backbone.

For the near-term future and any evolutionary approachtowards aeronautical multimedia communications, abroadband network based on GEO satellites seems to bethe first option. However, a GEO solution for thepurpose of future broadband communications to aircraftin flight reveals several problems, such as the coverageproblems at higher latitudes and the extreme antennasteering requirements at lowest elevation angles. With aLEO or MEO solution, in particular, potential systemcapacity limitations and latency for real-timecommunications could be reduced. On the other hand,besides system costs, especially networking complexitytend to increase while moving to lower orbits. Satellitehandover will become a major issue, and inter-satellitelinks may be necessary at least for LEO constellationsto provide connectivity over large ocean areas. Sincewe are focus on the transport protocol and forsimplicity, we will use GEO bent-pipe satellite for ouranalysis and simulation.

The service scenario considers travelers in aircraft onthe move. Since people are becoming more and more

used to their own communications equipment, such asmobile phones and laptops with Internet connection,either through a wired or wireless network interface.Thus the cabin segment will consist of wireless accesstechnologies (Such as Blue tooth, Wireless LAN) aswell as conventional IP fixed wired networks.

The main characteristics of the end-to-end path thataffect transport protocol performance are longpropagation delay, large bandwidth delay product, highbit error rate, and bandwidth asymmetry. If part of thecommunication path includes a satellite channel, theseparameters can vary substantially from those found onwired networks.

.~.

Grounll Segment

Long propagation delay: The three main componentsof delay are propagation delay, transmission delay, andqueuing delay. In the broadband satellite case, thedominant portion is expected to be propagation delay.OED satellite is about 36,OOOkm above the earth. Thepropagation delay from the earth up to the satellite andfrom the satellite down to the earth is about 125ms.Therefore a typical round trip time (RTT) for two-waysystem is about 5OOms plus the delay for terrestrialnetworks.

Large bandwidth-delay product: We assume herethat the GEO satellite operates on KIKa band to providebroadband connection for aircraft. The bandwidth delayproduct (e.g., 20Mbps.580ms RTT) in this system isvery large. To fully utilize such channel, we need to putthat much of data (equal to bandwidth-delay product)into the link. Since TCP will send new data until itreceives the ACKs for old data, that means TCPwindow should be at least the bandwidth delay product.

High bit error rate: In satellite channel, bit error rateof the order of 10-6 are often observed. This is primarilybecause the existing systems with legacy equipmentand many existing transponders were optimized foranalog voice and video services. New modulation andcoding techniques, along with higher-poweredsatellites, should help to make bit error rate very lowfor OED system.

Bandwidth asymmetry: Satellite networks can beasymmetric in several ways. Some satellite networksare inherently bandwidth asymmetric, such as thosebased on a direct broadcast satellite (DBS) downlinkand a return via a dial-up modem line. For purely GEOor LEO system, bandwidth asymmetries may exist formany users due to economic factors.

In addition, an aeronautical satellite network has somespecific network characteristics.

2Am..ri"An Tnc:tihtt.. nf A..rnnAl1ti..c: Anti Ac:trnnA.tti..c:

Mobile Aircraft: In this network, passengers inside theaircraft connect to the aircraft gateway using their ownequipments via wired or wireless connections. Theaircraft gateway connects to the ground network via abent-pipe satellite. The mobility of the aircraft will putaddition track requirements for the antennas on theaircraft and the satellite.

ED-route Low HER: When the aircraft is en-route,there are no obstacles (such as rain, cloud) between theaircraft and the satellite. It is possible that the satellitelink maintains connectivity and achieves "fiber-like"quality (BER of 10011) most of the time.

FIFO Satellite Channel: The bent-pipe satellite link isa FIFO channel and there is no out-of-order deliverybetween satellite gateways. Congestion over thesatellite link is impossible if the packets are sent at therate of the satellite bandwidth.

Intermittent connectivity: Due to handover andrelative geometric position changes of aircraft andsatellites, intermittent connectivity are expected inaeronautical network with typical during of severalseconds to several minutes.

Variable Round Trip Times: Because the aircraft flyaround the world, the propagation delay to and ITom thesatellite varies over time. The variance of the RTT canbe as large as 80ms. The impact of the variation to TCPis an open problem in literature.

In summary, we assume the aeronautical satellitenetworks characterized by high BER, high bandwidthdelay product, and long delay. Although the KIKa bandsatellite can provide higher bandwidth than Ku band,satellite bandwidth is still a scarce resource comparedto the bandwidth provided by optical fibers in theterrestrial networks. Therefore, we assume the satellitelink is the bottleneck of the system.

3 END- TO-END TCP PERFORMANCEIn this section, we describes basic TCP operation,identifies protocol options helpful to improve TCPperformance in satellite environment. We also quantifYhow well different TCP implementations perform in asatellite environment for Internet services.

3.1 TCP OPERATIONTCP is a connection-oriented, end-to-end, process-to-process reliable transport protocol [7]. TCP source anddestination port combined with IP source anddestination addresses uniquely identity each TCPconnection. There are several mechanisms in TCP toensure those functions, such as flow control, congestioncontrol and error control.

Flow control: TCP uses a sliding window to achieveflow control. The TCP receiver sets the receive window(RCYWND) field in the acknowledgement to its freebuffer size so that the sender will never overflow thereceiver's buffer.

Congestion control (8): The TCP sender maintains astate variable CWND for congestion window size.While RCVWND is used to guard that the sender willnot overload the receiver buffer, the CWND is used toguard that the sender will not overload the network. TheTCP sender can send at most the minimum ofRCYWND and CWND window worth packets withoutreceiving any ACK. In the most popular TCP Reno,there are four algorithms used for congestion control,which are slow start, congestion avoidance, fastretransmit, and fast recovery. Slow start is used uponthe start of a new connection to probe the networkbandwidth, it increases the CWND by one MaximumSegment Size (MSS) when an ACK is received, whichresults in increasing congestion window exponentially.TCP stays in slow start until its CWND is greater thanthe slow start threshold. After that TCP gets intocongestion avoidance, it increases CWND about oneMSS per round trip time (RTT). Fast retransmitalgorithm is triggered when a fixed number of duplicateacknowledgements (usually 3) are received. TCPretransmits the potential lost packet indicated by theacknowledgement and cuts its CWND to half. Afterthat, it inflates its CWND by one MSS when a duplicateacknowledgement is received. If there is one and onlyone packet lost in a single window, the inflation canincrease the CWND to the original CWND before theloss after about half RTT. After that TCP can send anew packet when each duplicate acknowledgement isreceived if allowed by the RCYWND. Finally it willsend half a window new packets when it receives thefirst non-duplicate acknowledgement. TCP Renodoesn't like TCP Tahoe, which does not have the fastrecovery algorithm and sends half a window packets inburst after the loss has been recovered.

Error control: Error control is the main component ofreliable protocols, which includes error detection anderror recovery. TCP uses acknowledgement packet,timer and retransmission to achieve error control. TCPuses cumulative acknowledgement, which means whena packet gets lost, it prevents the acknowledgementfrom being advanced and the window cannot slide untilthe lost packet is recovered. The sliding windowmechanism actuaIly ties the flow control, congestioncontrol and error control together and it becomesvulnerable when there are losses due to congestion lossand packet corruptions in the network.

3.2 TCP FLAVORS AND EXTENSIONAs originally specified, TCP did not perform well oversatellite networks (or high latency networks in general)for a number of reasons related to the protocol syntaxand semantics. Over the past decade, a number of TCPflavors and extensions have been specified whichimprove upon the performance of the basic protocol insatellite environments [9, 10].

Large Initial Window [11): For a connection withlarge RTf, TCP spends a long time in slow start beforereaching the available bandwidth. The time taken byTCP slow start to reach the satellite bandwidth (SatBW)is about RTT . 1082 (SatBW . RTf) when every TCP

segment is acknowledged. For short transfers, theycould be finished in slow start, which obviously doesnot use the bandwidth efficiently. Some researcherspropose to use a large initial window up to 4380 bytes(or a maximum of 4 segments) rather than 1 segment.Thus Files less than 4K bytes (many web pages are lessthan this size) can finish their transfers in one RTTrather than 2, 3.

Window Scaling (12): In TCP protocol syntax, thereceiver advertised window in the TCP header cannotbe more than 64K bytes, which limits the two-waythroughput to roughly 1 Mbps in GEO satellitenetworks. Window Scaling is proposed to solve thisproblem, which significantly increases the amount ofdata that can be outstanding on a connection byintroducing a scaling factor to be applied to the windowfield. This is particularly important for the satellitelinks, which require large windows to fulIy utilize theirhigh bit rate.

111111Prof~e ConIig Application Config QoS corIiguration

Selective Acknowledgements (SACK) [13): BecauseTCP Reno (popularly used in many systems) treats alllosses as congestion in the network. The link layer errorcan causes TCP to drop its window to a small size andleads to poor performance. TCP SACK can conveynon-contiguous segments received by the receiver inthe acknowledgements so that the sender can recovererror much faster than TCP Reno, which well know canrecover only on loss per RIT.

Path MTU discovery [14): This option allows the TCPsender to probe the network for the largest allowableMessage Transfer Unit (MTU). Using large MTUs ismore efficient to reduce the overhead and helps thecongestion window to open faster.

Forward Error Correction (FEC): FEC is usuallyused in satellite communication to reduce the bit errorrate. However, FEC consumes some bandwidth bysending redundant information together with the dataand transforms the original random error nature to onewith burst error.

In this work, we are interested in quantifying theperformance of TCP implementations with thosestandard enhancements. Note that even though some ofthese options have been specified for over severalyears, not all implementations use them today. It isimportant to emphasize that all of the aboveimplementations would be regarded as conformant tothe TCP standards; in practice, many more variants ofTCP exist.

Space SegmentSatelite

88IVIII 1

GrOU"ld GatewayInternet

aerver 2Ground Segment

Figure 2 Experiment setup for End-to-end TCP solutions

3.3 END- TO-END TCP PERFORMANCEIn this section we study how well different TCPimplementations perform in aeronautical satellitenetwork for Internet services. The detail of thesimulation setup can be found in [15].

The experiment setup of this simulation is shown infigure 2. A KIKa-band GEO satellite operates in themicrowave switch mode, in which it behaves as a bent-pipe transponder. Its spot beam is used to establish thecommunication link between the satellite and the fixedground terminal, which provides the interconnection toInternet backbone. The aircraft, which includes on-board network, communicates with satellite by itstracking antenna. The client on the aircraft willdownload files from the ground server by using FTPduring the flight. For each scenario, the forward andreturn links have data rate 5Mbps and IMbps,respectively. Both the client and the server have TCPbuffer size of 65536 bytes.

To maintain high throughput for large file transfers, theTCP congestion window must be large. This impliesthat the congestion avoidance and loss recoverymechanisms are very important in determiningperformance. In this simulation, we examine theperformance of four variants of TCP loss recovery andcongestion control: Tahoe (Fast Retransmission), Reno(Fast Retransmission and Fast Recovery), SACK (Reno+ Selective ACK), and Window Scaling (SACK +Window Scaling) [16].

Figure 3. TCP perfonnance for satellite link (1.6MB)

Figure 3 shows the TCP perfonnance for the satellitelink with FTP file size of 1.6MB. We can see that theresponse time to download a file increasesexponentially with the BER. That's because the TCP

congestion window cannot recovery quickly when thereare lots of packet losses (high BER). For same BER, theWindows Scaling and SACK have better performancethan Reno, Tahoe, where Tahoe need the largestresponse time to download the same file. Thedifferences of response time are more obvious when theBER becomes large.

We see that Window Scaling and SACK have almostsame performance. That is because in these scenarios,both the client and the server use TCP buffer size of65536 bytes. The congestion window of TCPconnection cannot be larger than the buffer size.Window scaling will have better performance thanSACK when we have large buffer size. Figure 4 showsthis effect. Here the client will download file of size1.6MB. When the receiver's buffer size is less than65536 bytes, the Window scaling and SACK have sameperformance. Actually window scaling is not used inthis case. When the buffer size is larger than 65536bytes, window scaling needs less time than SACK todownload the same file. The difference in the responsetime will become more obvious in low HER and for bigfile.

TCP Perfonn8nce va Bulfer Size

Buffer SIze (Byte)(Data Rate: 5MbpI, FTP "Ie SIze: 1.6MB)

Figure 4. TCP performance with different buffer size

From previous results, we can conclude that bystandard TCP with some enhancements for the satellitecommunications system with our configuration andsystem architecture, basic communication requirementscan be meet. If TCP/IP protocols are going to beadopted in the future satellite system, somemodifications of the protocol stacks will be necessary toachieve better performance. In particular, TCP SACKwith window scaling option has better performancethan other TCP flavors in our scenario. It also achieveshigh link utilization when the link HER is relative low.However, when the link HER becomes high, the end-to-

5Am..r;""n Tndjtllt.. of A..ron""t;"" "ntl Amon""t;""

end solutions cannot solve those problems effectively.We will discuss this problem in next section.

4 TCP SPLITTING PROTOCOLAlthough TCP can work well over GEO satellite linksunder certain conditions, there are cases for which eventhe best end-to-end modifications cannot ensure goodperformance. Furthermore, in an actual network with aheterogeneous user population, users and servers cannotall be expected to be running satellite-optimizedversions ofTCP. This has led to the practice of splittingtransport connections. In this section we describeunsolved problems by use end-to-end TCP solutions,the design of our splitting protocol, and theperformance comparison of the splitting protocol andend-to-end solutions.

4.1 Unsolved oroblemsDespite the progress on improving TCP, there remainsome vexing attributes of the protocol that impairperformance over satellite links. The end-to-endenhancements cannot solve these problems, or not veryeffectively.

Small operational window: Satellite TCP connectionsneed large windows to fully utilize the availablebandwidth. However it takes much longer for satelliteTCP connections than for terrestrial TCP connections toreach the target window size because of the largepropagation delay and the slow start algorithm in TCP.And the window multiplicative decrease strategy makesthe hard gained large TCP window very vulnerable tocongestion. The misinterpretation of link layercorruption as congestion makes this situation evenworse [17]. In the best case, the packet loss does notcause timeout and TCP can stay in congestionavoidance phase rather than in slow start, the additiveincrease strategy makes the window to grow veryslowly. From the above observations, we can see thateven if the window scaling option is available, it isdifficult for satellite TCP connections to actuallyoperate with large windows.

Asymmetric link: With respect to transport protocols,the forward throughput achievable depends not only onthe link characteristics and traffic levels in the forwardpath but also on those of the reverse path. Thecongestion in reverse path could lead to poorperformance in the forward link because TCP usesACKs to clock out data. To alleviate this problem,ACK filtering was proposed to drop the ACKs in thefront of the IP queue by taking advantage of thecumulative acknowledgement strategy in TCP [18]. The

situation is even worse for two-way transfers. When theusers are sending data and browsing the web at thesame time, a lot of data packets could be queued infront of ACKs in a FIFO queue, which increases theACKs delay dramatically. In this case, a priority queuecan be used to schedule the ACK to be sent first.

TCP fairness: For bulk transfer, TCP throughput isinverse proportional to RTT, so TCP connection withlarge RTT does not get its fair share of the bandwidthwhen it competes with the connections with shorterRTT [19]. It is difficult for end-to-end solutions tosolve this fairness problem. Using the Constant-rateadditive increase policy can correct this bias. However,it is difficult to implement in a heterogeneous network.

Because the feedback information of the satellite iseither delayed too long or too noisy or both, end-to-endschemes cannot solve these problems very effectively.An alternative to end-to-end schemes is to keep thelarge window of packets in the network such as at thesatellite gateway between the satellite and aircraftplatform. Considering the interoperability issue, wepropose a connection splitting based scheme to solvethose problems.

4.2 SOlittiD2 orotocolThe idea behind split connections is to shield high-latency or noisy network segments tTom the rest of thenetwork, in a manner transparent to applications. Figure5 illustrates the general split case, in which an end-to-end TCP connection is split into 3 connections at theaircraft gateway and ground gateway. One connectionis tTom the Internet server to the ground gateway,another one is tTom the ground gateway to the aircraftgateway, and the last one is tTom the aircraft gateway tothe client in aircraft. We consider the data transfer tTomthe Internet servers to the client in aircraft. Groundgateway sends premature acknowledgements to theInternet servers and takes responsibility to relay all theacknowledged packets to the aircraft gateway reliably.The aircraft gateway does the same job to relay the datato the client.

The goal of splitting connections is for end users to beunaware of the presence of an intermediate agent, otherthan improved performance. From the perspective ofthe hose in the wide-area Internet, it is communicatingwith a well-connected host with a much shorter latency.For the satellite link between the ground gateway andthe aircraft gateway, a satellite optimized transportprotocol can be used.

6A mp,.;rAn 'nditlltp nf A prnnAlItirc: Anti A c:trnnAlItirc:

Ii IIProlae Config Apptication Config

Figure 5 TCP Splitting protocol for Aeronautical Satellite Networks

Because GEO satellite channel is a FIFO channel, thereis no out-of-order routing. And congestion over thesatellite link is impossible if the packets are sent at therate of the satellite bandwidth. The above observationsmotivate us to decouple the congestion control anderror control in TCP first and then design more efficientand effective congestion and error schemes with ourspecific network characteristics in mind. We design anew TCP splitting protocol, which we calledAeronautical Transport Control Protocol (AeroTCP),for the satellite connection. The main idea is to use oneduplicate ACK to trigger the fast retransmission at thesatellite gateway and to use a fixed window size for thesatellite TCP connection. This implementation of thisidea will be discussed in detail in the following.

Flow Control: We still use a sliding window for flowcontrol, however, here the window are fixed for eachsatellite connection. For a normal router, they only havethe functions up to IP layer, while the satellite gatewayis able to process TCP packets. All the TCP packetsreceived from the servers are forwarded to the TCPreceived buffer of the ground gateway and they aremoved from the received buffer to send buffer fortransmission. The receive buffer and send buffer can beimplemented by one physical buffer.

The buffer size assigned to each connection at thesatellite gateway has a direct impact on the end-to-endTCP throughput. Consider the traffic from Internetserver to the client on aircraft, assume there is only oneconnection in this system, the buffer size assigned tothe TCP connection is Buff and the effective satellite

Space Segment

Q oS ~ alienSillelite

Ground Se~nt

8tI¥8r 1

GrtU1d Gal8M&' IrUmIt

I Ground connection I IeMIf 2Satelli teconnection

bandwidth is SatBW. The date in the satellite pipe isSatWin and the advertised receiver window for theserver is RecvWin. The round trip time for the satelliteconnection is SatRTT and for the ground connection isGndRTT. Then the system reaches the steady state, theinput rate of the queue at the ground gateway should beequal to the output rate of the queue, Le., RecvWin /GndRTT = SatWin / SatRTT. The throughput of theconnection is min (SatBW, Buff / (SatRTT +GndRTT)) and the backlog packets are max (0, Buff -SatBW . (SatRTT + TerrRTT)) [20]. From the above

analysis, we can see that the buffer size can become thebottleneck of the end-to-end TCP performance if it isless than the bandwidth delay product. However whenthe buffer size is greater than the bandwidth delayproduct, there are packets backlogged at the satellitegateway and these backlogged packets cannotcontribute to the throughput and only increase thequeuing delay.

When there are multiple connections in this system, thebandwidth available to each connection is a function ofthe number of connections and their activities. Forsimplicity, we assign each connection a static peak rate,which is the maximum bandwidth it can achieve and ismuch smaller than the total satellite bandwidth, and thebuffer size is set corresponding to that peak rate.

We assume large but not infinite buffer is available atthe client and the TCP flow control is still enforced sothat the gateway will not overflow the receiver's buffer.

7Amp,.;, n Tnditlltp nf Aprnn..llti,..c ..nti Adrnn..llti,..c

Congestion Control: For the sateliite connections, thesateliite link bandwidth to be shared among them isfixed and known. Besides the number of connectionsand the traffic arrival pattern are known. All thisinformation is available at the satellite gateway.Therefore there is no need to use slow start to probe thebandwidth and use additive increase and multiplicativedecrease congestion avoidance to guarantee fairresource sharing as in the distributed case.

In our scheme, we cancel all the congestion controlalgorithms in TCP. The gateway can send packets aslong as there are packets in the buffer and the receiver'swindow allows sending. Also there is no need toexponentially back off the timer after timeout becausecongestion is impossible over the satellite link. Timer isused only for error recovery. As long as there arepackets buffered at the satellite gateway, the satellitelink can be fully utilized. When the traffic loadincreases, the buffers begin to be filled up and thecongestion is back pressured to the sources through theadvertised receiver windows. When the traffic loaddecreases, the buffers begin to be emptied and largeradvertised receiver windows are sent to the source sothe sources can speed up. This way satellite linkefficiency is achieved.

Error Control: TCP depends on duplicateacknowledgements and timer for error control Becauseout of order packet arrivals are possible in the wide areanetworks, the fast retransmit algorithm is triggered afterthree rather than one or two duplicateacknowledgements are received. The three duplicateacknowledgements requirement puts a high burden onthe return channel bandwidth. The high bit error rate ofthe satellite link can cause multiple packet losses in oneRIT and may lead to timeout. When the retransmittedpackets are lost, timer could be the only means for errorrecovery. However, timer has to be conservative and isusually set much larger than the round trip delay tomake sure the packet does leave the networks. Theseconservative loss detection and recovery schemes inTCP are not effective in satellite networks and shouldbe enhanced.

In our scheme, we explore the specific characteristics ofour network. Firstly, because congestion is impossiblefor the satellite connections and any loss must becaused by the link layer corruption. So the errorrecovery scheme can operate independently with thecongestion control scheme. Secondly, the satellite linkis a FIFO channel and out of order packet arrivals areimpossible.

We design a scheme for error control by using oneduplicated ACK for fast recovery. We keep track of the

packets in sequence space of all acknowledged packets.Whenever a duplicated acknowledgement is received,we just assume that packet is lost and retransmit it.During the recovery, we use the same idea as in TCPNewReno [21]. We use partial ACKs to calculate theburst loss gap and send all the potentially lost packetsbeginning from the partial acknowledgement number.Although it is possible that the sender could retransmitpackets that have already been correctly received by thereceiver, it is more effective in recovering burst errors(popular in satellite environment). Timer is still used asthe last resort for loss recovery, however, after timerexpires, two copies of the lost packet are sent toincrease redundancy.

4.3 TCP Solittin2 Protocol Performance

1111Profle Carl.. AWc~"on (~

.. ,.,.. "I ~.. 'Icieri ~-

Figure 6 Experiment setup for TCP splitting Protocol

To test our splitting scheme, we setup a simulationmodel as shown in figure 6. A client downloads a file of1.6M bytes from a server via a satellite link. The linkdelay between the hybrid gateway and the client is25Oms and the link delay between server and gatewayis 40ms. Therefore the RTT between the server and theclient is 580ms. The satellite link bandwidth is OSI(1.544Mbps) and the ground link is lOMbps. Thetransport protocol for the ground connection is normalTCP SACK, while we use our TCP splitting scheme forthe satellite connection. We assume the satellite linkbetween the gateway and the client is noise channelwith various bit error rate, while the ground link has noerror. The statistics we collect is link utilization andlink throughput of the two downstream links.

Figure 7 shows the utilization for our scheme and forTCP connection splitting scheme. The TCP connectionsplitting scheme uses TCP SACK for both the satelliteconnections and terrestrial connections. When the biterror rate is very low, both schemes can achieve veryhigh throughput since the TCP can actually operatewith large window. For TCP connection splittingscheme, when the bit error rate increases up to 10-6, thelink layer corruption causes the satellite TCP to drop itscongestion window, which leads to degradedperformance. When the BER increases to lO's, the

8A mprir"n Tnc:titlltp nf A prnn"lItir.. ..nti A drnn"lItir..

retransmitted packets can get lost again and TCP mayhave to wait for the timeout to recover the error. Aftertimeout, the congestion window is set to one and TCPenters slow start and the link utilization is very low.While for our scheme, the TCP can send packet at therate of bandwidth as long as there are packets in thebuffer and the receiver has enough buffer. Theutilization is drop when the BER increases to 10,5,which is because lots of packets are lost due to layererror corruptions.

Figure 7 Utilization for different bit error rates

BER

Figure 8 Response time for FTP application

It is important to compare our scheme with the end-to-end TCP solutions. Figure 8 shows the FTP responsetime for end-to-end TCP, TCP splitting, and our schemeto download a file of 1.6M bytes. The TCP splittinguses TCP SACK for both the satellite connections andterrestrial connections. We can see that the TCPsplitting has better performance than end-to-end TCPbecause in TCP splitting, the terrestrial connection can

operate with large window and send packets to gatewayfaster due to no error. It is interesting that performanceis improved if we just use splitting protocol, althoughnot noticeable when the BER is high. In the other hand,our scheme has the best performance than both end-to-end TCP and TCP splitting. This is because both thesatellite connection and terrestrial connection of ourscheme can operate with large window. The responsetime is more obvious when the BER increase to 10' .

In summary, we have described the design andperformance of a satellite-optimized transport protocol,AeroTCP. AeroTCP inherently incorporates many ofthe features that have been proposed or adopted as TCPoptions for improved satellite performance. AeroTCPallows for the use of rate-based congestion control andis well matched to satellite networks.

5 CONCLUSIONSIn this paper, we have investigated the performance ofIP-Compatible transport protocols over satellite linksfrom several perspectives. We observed degradation inTCP performance for large bandwidth-delay productnetworks such as aeronautical satellite systems. If theright TCP options are used and congestion is light, TCPcan work well for large file transfers even over GEOlinks. Because it is difficult for an end-to-end TCPsolution to solve the problems in the aeronauticalsatellite networks, we propose a connection splittingbased solution, AeroTCP, which is designed for thesatellite connections by taking advantage of the specificcharacteristics of the satellite networks. Our simulationresults show that our scheme can maintain highutilization of the satellite link and has betterperformance than end-to-end solutions.

Acknowledl!ements:Center for Satellite

This work is supported by theand Hybrid Communication

Networlcs, under NASA cooperative agreement NCC8-235 and NASA cooperative agreement NAG3-2844.

REFERENCESOagur Ercetin, Michael O. Ball, LeandrosTassiulas, "Next Generation Satellite systems forAeronautical Communications", TechnicalResearch Report of National Center of Excellencein Aviation Operations Research, NEXTOR T .R.2000-1, ISR T.R. 2000-20

1.

2.

3.

4.

M. Werner, M. Holzbock, "System Design forAeronautical Broadband SatelliteCommunications", In Proceedings Int. Conferenceon Communications (ICC'02), Paper # J03-3, 2002Peter W. Lemme, Simon M. Glenister, Alan W.Miller, "Iridium Aeronautical SatelliteCommunications", IEEE AES System magazine,November 1999W. H. Jones, M. de La Chapelle, "Connexion byBoeingSM-Broadband Satellite CommunicationSystem for Mobile Platforms", MilitaryCommunications Conference, 200 I. MILCOM2001. Communications for Network-CentricOperations: Creating the Information Force. IEEE,Volume: 2,2001 Page(s): TSS -7S8 vol.2.W. Stevens, "TCP/IP Illustrated", Volume 3,Addison Wesley, 1996.Walter J. Gribbin, "Aeronautical SatelliteNetworks", IEEE 1988, CH2674-0-11/88/oo00-13SJ. Postel, "Transmission Control Protocol", InternetRFC 793,1981.M. Allman, V. Paxson, and W. Stevens, "TCPCongestion Control", RFC 2S8I, 1999M. Allman, D. Glover, and 1. Sanchez, "EnhancingTCP Over Satellite Channels using StandardMechanisms", RFC 2488, 1999M. Allman(ed), S. Dawkins, D. Glover, J. Griner,D. Tran, T. Henderson, J. Heidemann, J. Touch, H.Kruse, S. Ostermann, K. Scott, and J. Semke,"Ongoing TCP research Related to Satellites", RFC2760,2000

10.

It. M. Allman, S. Floyd, C. Partridge, "IncreasingTCP's Initial Window", Internet RFC 2414,September 1998.V. Jacobson, R. Braden, and D. Borman, "TCPExtensions for High performance", Internet RFC1323, 1992M. Mathis, J. Mahdavi, S. Floyd, and A.Romanow, "TCP Selective AcknowledgementOptions", Internet RFC 2018,1996.J. Mogul and S.Deering, "Path MTU discovery",Internet RFC 1191, 1990.Yadong Shang, Michael, Hadjitheodosiou, andJohn Baras, "Using Broadband Satellite Systems toSupport Aeronautical Communications", Proc. 21-International Communications SateIlite SystemsConference and Exhibit, 15-19 Apr. 2003,Yokohama, Japan.

12.

13.

14.

15.

16. K. Fall and S. Floyd, "Simulation-basedComparisons of Tahoe, Reno, and SACK TCP",ACM Computer Communications Review, Vol. 26,DO. 3, pp. 5-21, July 1996.

17. Xiaoming Zhou, Xicheng Liu, and John Baras,"Flow Control at Satellite Gateways", TechnicalResearch Report, ISR, University of Maryland,CSHCN TR 2002-19, http://www.isr.umd.edu

18. H. Balakrishnan, V. Padmanabhan, and R. Katx,"The Effects of Asymmetry on TCP performance",Proceedings of Third ACM/IEEE MobiComConference, pp. 77-89, Sept. 1997.

19. T. Lakshman and U. Madhow, "The Performanceof TCP/IP for Networks with High Bandwidth-Delay Products and Random Loss", IEEE/ACMTransactions on Networking, vol. 5, no. 3, pp. 336-350, June 1997.

20. Xiaoming Zhou and John S. Baras, "TCP overGEO satellite hybrid networks", in Proc. IEEEMilCom Conference, 2002.

21. S. Floyd and T. Henderson, "The New RenoModification to TCP's Fast Recovery Algorithm",Internet RFC 2582 (Experimental), April 1999.

10Amp" n Tnc:titl1tp nf Aprnn.."ti..c: ..ntl Ac:trnn.."t;..c: