satellite communications in the global internet_ issues, pitfalls, and poten
TRANSCRIPT
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
1/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
Satellite Communications in the Global Internet:ssues, Pitfalls, and Potential
ongguang Zhang
ante De Lucia o Ryu
on K. Dao
ughes Research Laboratories
SA
Abstract
ecent deployment of commercial products in geosynchronous earth orbit (GEO) satellite
mmunication networks demonstrates the promise of ubiquitous access to the Internet. Delivering th
omise to end users requires integrating satellite communications into existing Internet transmission
nks. This effort is the topic of heated debate over whether common Internet applications can perform
tisfactorily over networks with high-latency links, such as those involving GEO satellite
ansmissions. Through simulations and actual satellite experiments, we contend that most applicatio
n work effectively. Certain TCP-based applications have technical shortcomings that surface in bo
rrestrial and satellite high-speed networks, but feasible solutions exist. Furthermore, multicast
plications and the network as a whole can benefit from the broadcast nature of satellite transmissio
d its simple network topology, as demonstrated by our experiments using NASA's Advanced
ommunications Technology Satellite (ACTS).
ontents
q Introduction
r Satellite networks
r Applications
q TCP over long delay networks
r Performance issues in TCP control mechanisms
s Window size
s Bandwidth adaptation
s Selective acknowledgment
s Slow start
s Congestion avoidance
s TCP for transactions
r Impacts on end-to-end performance
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (1 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
2/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
r Approaches for performance improvement
s TCP extensions
s Middleware
s Application protocol approaches
q Multicast
q Conclusion
q Acknowledgmentsq References
ntroduction
atellite networks
ost current Internet backbones and subnets are wired terrestrial networks (e.g., cable, telephone, an
ber optics) with bandwidth ranging from T1 (1.5 megabits per second [Mbps]) to OC-12 (622 Mbpurrently, researchers are working on the next-generation Internet that will support high-bandwidth
plications (> 45 Mbps), and ubiquitous computing with mobile/wireless networks (wireless local a
twork [LAN] and ATM, wireless metropolitan networks, and satellite networks). Among these mo
ireless networks, GEO satellite networks offer great potential for multimedia applications with thei
ility to broadcast and multicast large amounts of data over a very large area, thus achieving global
nnectivity [12]. Internet distribution via satellites, particularly GEO satellites, has the following
erits:
igh bandwidthA Ka-band (20-30 GHz) satellite can deliver throughput at gigabits per second rates.
expensive
A satellite communications system is relatively inexpensive because there are no cable-laying
costs, and one satellite covers a very large area.
ntethered communication
Users can enjoy untethered mobile communication anywhere within the footprints of the satel
mple network topology
Compared with the mesh interconnection model of the terrestrial Internet, GEO satellite netw
have much simpler delivery paths. The simpler topology often results in more manageablenetwork performance.
roadcast/multicast
Satellite networks are naturally attractive for broadcast/multicast applications (such as MBone
[7]). In contrast, multicast in a mesh interconnection network requires complicated multicast
routing. Performance can vary for each multicast group member and is dependent on the route
from the source.
n the other hand, satellite communications present one major challenge with respect to the
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (2 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
3/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
rformance of Internet applications -- the communication latency between two earth stations connec
y a satellite. For GEO satellite communications systems, the latency is at least 250 milliseconds
ometimes framing, queuing, and on-board switching can add extra delays, making the end-to-end
tency as high as 400 milliseconds). This is approximately 10 times higher than a point-to-point fibe
ptics connection across the continental United States. The latency might not affect bulk data transfe
d broadcast-type applications, but it will hurt highly interactive applications that require extensive
ndshaking between two sites. Unfortunately, one of the major Internet transport protocols, TCP,
quires such interaction.
EO (low earth orbit) and MEO (medium earth orbit) satellites can also provide global and broadban
mmunication capacities. Latency in a LEO system is comparable with terrestrial fiber optics, usual
nly about twice as large. Because neither a LEO nor a MEO satellite can stay in a fixed position
lative to the surface of the earth, a constellation of many satellites is required to provide complete
verage, increasing the complexity of the system relative to GEO systems. Network management is
uch harder problem because handoff, tracking, and routing need to be done properly. The advantag
mple topology is lost, and so is single-source broadcast/multicast capability.
pplications
ommon Internet applications include Web browsing, file transfer protocol (FTP), remote login
elnet), video teleconferencing, e-mail, and broadcast. They all use IP (Internet Protocol) as the
ansmission mechanism, so they can seamlessly run over satellite networks. However, performance
ries among applications because their requirements on network bandwidth and responsiveness, the
lerance to communication noise, and their implementation techniques are very different.
emote control and login
Remote control and login are very delay sensitive. Typically a user expects responsiveness on
order of tens of milliseconds during a remote login session. Remote control may require even
faster response, depending on applications. When compared with the often congested and cha
terrestrial Internet, system response time over GEO satellites is somewhat slower but more sta
If a user can endure a half-second to one-second delay, remote control and remote login
applications can run smoothly over satellites.
formation dissemination and broadcast
Satellite networks are better media to deliver bulk data, anywhere and anytime. Some illustrat
examples include maps and situation awareness data, stock market and financial numbers,
battlefield information, and medical data. Data broadcast, such as webcasting, network news,
TV programs can be very expensive for point-to-point networks, but is ideally suited to broad
satellites. Therefore, GEO satellites are far more suitable for these applications than is the
traditional terrestrial network.
deoconferencing
Videoconferencing and video distribution applications can usually tolerate a certain amount o
packet loss; thus they can be built on top of UDP (such as the MBone video tool vic [9])
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (3 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
4/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
Typically the protocol requires no bidirectional synchronous (handshake-style) communicatio
hence latency is not a prohibitive issue. Compared with the terrestrial Internet, GEO satellites
provide better quality in videoconferencing thanks to more available bandwidth and simpler
network topology.
ectronic mail
Traditionally electronic mail is not interactive. It does not require a great deal of bandwidth an
can tolerate reasonable delays (often in terms of minutes). It should work fine over any netwo
formation retrieval (WWW, FTP)Many such applications require reliable data transmissions, hence they are usually built on top
robust protocols like TCP. Because of the "acknowledge-and-retransmission" scheme being u
these protocols are often sensitive to communication latency. However, many of the informat
retrieval applications, especially the online interactive ones, desire the fastest possible respon
Their performance will depend on how TCP is being used in the implementation, that is, how
much information is being retrieved and whether it can be retrieved as a single transfer or a
number of smaller transfers. This effect of TCP is of particular interest to our study and we w
examine this issue in more detail later.
teractive gamingCertain applications that require instantaneous reaction time, like highly reactive network
gaming, do not work over GEO satellites because of physical delay limitations. Other types o
interactive gaming, such as chess, would not suffer from the delay.
he following figure summarizes these applications. They vary substantially in demands on bandwid
d responsiveness. The implementation techniques are also very different, as are the impacts of
twork delays. Some applications require guaranteed delivery; they use TCP and are sensitive to
tency. Others can use UDP or other real-time protocols that can tolerate delays. Multicast/broadcas
plications use reliable multicast such as SRM, which is less sensitive to delays than TCP and thusorks fine over satellite links. It is therefore inappropriate to make simple statements on whether GE
tellites make better Internet access. The purpose of this paper is to show the prospects for Internet
stribution over satellites and let users decide by their application priorities.
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (4 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
5/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
CP over long delay networks
n today's Internet, TCP is the protocol used by the vast majority of applications. The performance o
CP over long-delay networks will have a direct impact on the performance of Internet access using
EO satellites. In this section, we will analyze the performance issues in TCP control mechanisms an
rrent approaches to adopt and improve TCP for long-delay networks.
erformance issues in TCP control mechanisms
indow size
CP flow control starts from the "window size" concept of a TCP connection. It determines how mu
ta can be outstanding (i.e., unacknowledged) in the network. In long-delay networks, there can be
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (5 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
6/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
any unacknowledged segments. Theoretically, the amount of data that can be in a transit is given b
e bandwidth-delay product. In practice, memory and operating system resources limit the window
the current TCP standard, the maximum window size in TCP is 64 Kb. (Because of historical
mplementation issues concerned with signed and unsigned arithmetic, the practical window size is o
mited to 32 Kb.)
o maximize bandwidth utilization in a satellite network, TCP needs a much larger window size. For
ample, on a satellite link with a round-trip delay of 0.8 seconds and bandwidth of 1.54 Mbps, theeoretical optimal window size is 154 Kb, or considerably more than a maximum window size of 32
64K.
new TCP extension, or TCP-LW for "large-window" [6], has been defined to increase the maximu
indow size from 216 to 232, allowing better utilization of links with large bandwidth delay products
btain good TCP performance over satellite links, both sender and receiver use a version of TCP that
mplements TCP-LW. Applications should also set the size of the send and receiver buffers to be
ndwidth times delay.
andwidth adaptation
CP adapts to the available bandwidth of the network by increasing its window size as congestion
creases and reducing the window size as it increases. The speed of the adaptation is proportional to
tency, or the round trip time of the acknowledgment. In a satellite network with longer latency,
ndwidth adaptation takes longer and, as a result, TCP congestion control is not as effective.
urthermore, it will take much longer for TCP's linear increase to recover the window size after a pac
ss if a TCP "large-window" extension is used.
elective acknowledgment
he standard TCP acknowledgment scheme is cumulative. If a segment is lost, TCP senders will
transmit all data sent starting from the lost segment without regard to the successful transmission o
ter segments. TCP considers this lost segment as an indication of congestion and reduce its window
ze by half. Recently the newly defined standard TCP-SACK (Selective ACKnowledge) allows the
ceiver to explicitly inform the sender of the loss. Consequently, a sender can retransmit the lost
gments immediately rather than waiting for a timeout, reacting to supposed congestion, andultiplicatively decreasing its window. If lost segments are not caused by congestion, or the congest
transient, throughput in TCP-SACK should be much better. This will be helpful in satellite networ
cause anything that triggers timeouts and window size reduction will force a lengthy recovery in T
ow start
hen a TCP connection first starts up or is idle for a long time, it needs to quickly determine the
ailable bandwidth on the network. It does so by starting with an initial window size of one segmen
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (6 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
7/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
sually 512 bytes), then increasing the window size as packets are delivered successfully and
knowledgments arrive, until reaching the network saturation state (indicated by a packet drop). On
ne hand, slow start avoids congesting the network before it has a good assessment of the available
ndwidth; on the other hand, TCP bandwidth utilization is suboptimal during the procedure. Theref
e shorter TCP slow start lasts, the better performance it can achieve. The total time of a TCP slow s
riod is approximately RTT*log2(B/MSS), where RTTis the round trip time (twice the latency), B th
ailable bandwidth, and MSS the TCP segment size. Although the growth is exponential, for high-
ndwidth and long-delay networks (e.g., satellite links and terrestrial gigabit network), this can take
gnificant amount of time.
ongestion avoidance
ecently, new techniques have been introduced in TCP to avoid congestion before it happens. The fi
proach, called RED (random early detection) gateways [5], requires each gateway to monitor its ow
ueue length. When imminent congestion is detected the TCP sender is notified. By dropping a pack
rlier than it would normally, RED sends an implicit notification of congestion. The sender isfectively notified by the timeout of this packet. The principle behind the RED approach is that a few
rlier-than-usual drops may help avoid more packet drops later on. The TCP sender can then reduce
indow before serious congestion occurs.
nother approach is to have the TCP sender predict when congestion is about to occur and reduce its
ansmission window before intermediate routers drop packets (TCP Vegas [3]). TCP can keep track
e minimum round trip time seen during a transfer and use the most recently observed round trip tim
compute the data queued in the network. TCP can also keep track of the throughput before and aft
e congestion window changes to estimate the network congestion level. If estimates indicate that thumber of packets queued in the network is rising, it reduces the congestion window. As it observes
umber decreasing it increases the congestion window.
lthough neither approach has been widely adopted, both hold promise for satellite networks. As we
entioned earlier, TCP congestion control responds to congestion slowly because of latency. If such
ngestion can be avoided before it happens, it is a big win for high-speed and long-delay networks.
CP for transactions
any TCP applications involve only simple communications between the client and the server. The
teraction is called a transaction: a client sends a request to a server and the server replies. The
ypertext Transfer protocol (HTTP) for WWW browsing applications is a typical example of TCP w
ansactional behavior. Under standard TCP, even a small transaction involving a single request segm
d a reply must undergo TCP's three-way handshake in preparation for bidirectional data transfer. If
quest is bigger than a segment, TCP must also undergo the slow start procedure. It is very inefficie
establish such a TCP connection, send and receive an insignificant amount of data, and then tear it
own.
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (7 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
8/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
ansaction TCP, or T/TCP [2,10], is an extension to TCP designed to make such behavior more
ficient. T/TCP does this by bypassing the three-way handshake and slow start, using the cached sta
formation from previous connections. Although T/TCP is designed mainly for short client-server
teraction applications, it can be used to reduce the impact of latency on the beginning of a TCP
nnection. If slow start can be avoided, significant performance improvement can be achieved in a
tellite-based network.
mpacts on end-to-end performance
e have conducted a simple set of simulation experiments to explore the correlation among TCP
indow size, network bandwidth, latency, and end-to-end performance (response time and throughpu
he network simulation tool we used, NS [8], allows arbitrary network configuration and different T
rsions. The figure below describes the network topology of our experiment. We varied the
terconnection link bandwidth from 128 Kbps (kilobits per second) to 6.176 Mbps, the latency from
s to 400 ms (which covers local network, LEO, MEO, and GEO satellite links), and the workload (
mount of data sent in one TCP connection) from 1 KB to 100 MB. We also varied the TCP window
ze from 2 KB to 512 KB.
e recorded the throughput and response time of each TCP connection. Throughput determines the
ndwidth utilization of the link from the system manager's point of view, while the response time
flects performance as perceived by the user. A small sample of the results is compiled in the table
low:
Bandwidth 6.176 Mbps 1.544 Mbps 0.384 Mbps 0.384 Mbp
Amount Transfer 100M 10K 1M 10K
Measurement throughput throughput response time response t
Result in figure (click for detail and
xplanation)
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (8 of 16)25/8/2549 17:27:58
http://www.isoc.org/inet97/proceedings/F5/F5_1D.HTMhttp://www.isoc.org/inet97/proceedings/F5/F5_1C.HTMhttp://www.isoc.org/inet97/proceedings/F5/F5_1B.HTMhttp://www.isoc.org/inet97/proceedings/F5/F5_1A.HTM -
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
9/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
om the above results we can see that latency is a decisive factor in a satellite network only for the
sponse times of small transfers. If an interactive application often opens a TCP connection only to
nd a small amount of data, it will perform very inefficiently. The next section will suggest better
ternatives under this condition.
pproaches for performance improvement
ver the years, people have developed various techniques to mitigate the impact of latency. The first
ternative is to adopt a version of TCP that performs better over the satellite and does not hinder
rformance over terrestrial networks. The second approach relies on Internet gateways at the satellit
twork boundaries to perform special functions to speed up TCP sessions. The third approach is to
velop better implementations of common applications that use TCP more efficiently and more
nsitively.
CP extensions
ome of the TCP problems experienced on GEO satellite links today will arise in future high-speed
rrestrial networks because of the similar bandwidth-times-delay property. Problems like large wind
ze, prolonged slow start period, and ineffective bandwidth adaptation affect both networks. They pl
tellite networks and gigabit terrestrial networks in the same class of extensions for better performan
ome of the techniques discussed earlier, including TCP-LW, TCP-SACK, TCP-Vegas, T/TCP, and
ED gateways, can alleviate the problems for both networks. For example, TCP-Vegas can reduce th
umber of packets lost to congestion, hence reducing long delays after packet drops. In a similar way
CP-SACK can reduce the need for retransmission of unnecessary data. Other techniques like rate
ntrol and selective negative acknowledgments may further improve efficiency. The benefits of
plying these extensions/improvements have been demonstrated in MITRE's attempt to develop TC
odifications specifically tailored for space communications [4].
iddleware
reat performance improvements can be made in many cases by working at the Internet infrastructur
vel without the need to modify TCP. This layer is sometimes referred to as the middleware layer.
hile enhancements at the transport-layer require changes to the operating system of each end host,
hancements at the middleware layer usually require few or no such modifications.
plit-TCP
The idea of split-TCP (sometimes referred to as indirect TCP), is to break an end-to-end TCP
connection into two or three segments. Each segment is itself a complete TCP connection. Da
streams are forwarded from one segment to another (buffering if necessary). When split-TCP
applied to a satellite network, the middle segment spans the long-latency satellite link, and the
other two segments connect the routers that join the terrestrial Internet and the satellite link to
original endpoints.
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (9 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
10/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
Splitting isolates the effects of long latency. If the first and the last TCP segment span a low-
latency network, TCP slow start can speed up more quickly and the normal window size (with
TCP-LW) will work just fine. The middle segment, however, should implement special featur
such as T/TCP and use large windows to cope with long latency. This way, TCP performance
be improved with only minor changes to application software.CP spoofing
In TCP spoofing, an intermediate gateway (usually at the satellite uplink) prematurely
acknowledges a TCP segment without waiting for the actual acknowledgment from the receiv
This gives the sender the illusion of a low-latency network so the TCP slow start phase can
progress more rapidly. The intermediate gateway buffers segments in transit. When the actual
acknowledgment from the receiver arrives at the gateway, it is suppressed to prevent duplicate
acknowledgments from reaching the sender. If the receiver's acknowledgment never arrives an
the gateway times out, it retransmits the lost segment from its local buffer.
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (10 of 16)25/8/2549 17:27:58
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
11/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
Like split-TCP, TCP spoofing breaks the concept of end-to-end semantics because the sender
may think a segment has arrived at the destination while it is actually still in transit. This is
acceptable in many applications, such as WWW browsing through proxy, but it may causeproblems if an application is built upon end-to-end semantics.
pplication protocol approaches
CP has its shortcomings when used over long-delay networks. These can be avoided if Internet
plications use TCP more effectively, for example, by avoiding small and short transfers, as sugges
the previous section.
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (11 of 16)25/8/2549 17:27:59
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
12/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
ersistent TCP connections
In some client/server-type applications, the client program sends a request to the server and th
server replies. If each such request/reply is implemented in a separate TCP session, the overal
performance of the application will suffer significantly over a satellite network. However, we
speed up the performance by rewriting the application to use a single TCP session for all the
small requests/replies. For example, the current HTTP protocol for WWW applications perfor
poorly because a Web client fetches each Web object (page of text, icons, images, etc.) in a
separate TCP connection. A typical Web page consists of many such small objects. Although
amount of data is moderate, it would take tens of seconds to fetch such a page over a GEO
satellite. Recently, a new upcoming standard, HTTP 1.1, alleviates the performance problem b
using a persistent connection to combine many small transfers into a single fetch and to pipeli
the transfers so that the transmission delays overlap with each other. Using HTTP 1.1, a typic
Web page transmission time can be reduced to a few seconds over a GEO satellite, which is
comparable to the terrestrial Internet.
aching
Caching can reduce network utilization and latency as seen by the user. Caches are currently
available for protocols in use by the World Wide Web (e.g., HTTP, FTP, and Gopher). It requminimal cooperation from end users. Caching combined with data broadcast creates a new
information retrieval/dissemination paradigm that makes better utilization of network bandwi
Commonly requested and filtered Web documents are multicast to local caches. Most of the W
requests are satisfied by a nearby cache, with only occasional retrievals from remote servers. T
paradigm is better supported by GEO satellite networks because of its broadcast and high
bandwidth capability.
pplication-specific proxies
Application-specific proxies can use domain knowledge to match network constraints and red
the effect of latency. For example, a WWW proxy that prefetches Web pages can eliminate rotrips across satellite links. An X window proxy that converts synchronous X request/response
pairs into asynchronous communications can significantly improve the responsiveness of X
window programs (several times faster in many cases) [11].
Multicast
EO satellites can be a natural media for MBone (the virtual network over Internet for multicast
plications [7]) because of their large coverage area and broadcast capability. Currently, to multicasver the terrestrial MBone, the data must travel over numerous links and duplicate itself at numerous
termediate routers (see figure below for a recent map of MBone [1]). This takes up significant
ndwidth and raises the possibility of transient congestion from TCP cross traffic at each router alon
e path.
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (12 of 16)25/8/2549 17:27:59
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
13/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
n the contrary, multicast over satellite can deliver data directly to end-user networks or hosts with
inimal cost. The following figure envisions the future MBone with multicast satellite connecting
rategic points on the Internet.
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (13 of 16)25/8/2549 17:27:59
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
14/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
o demonstrate the potential role of satellites in Internet multicast, we have set up an experimental
Bone link over the NASA ACTS satellite between the NASA Lewis Research Center (LeRC) in O
d Hughes Research Laboratories (HRL) in California. The link allows two sites to connect directly
stead of going through tens of hops over the terrestrial MBone. (See above figure for location of Le
d HRL.)
ternet applications that use multicast can gain substantial benefit from a satellite network. First,
ulticast applications do not use TCP and are not sensitive to long bandwidth delay products in the
me way TCP is. Moreover, satellite networks can bypass potentially tens of intermediate nodes, thu
ducing the chances of packet drop and large delay jitter attributable to congestion. To illustrate this
e have conducted an MBone videoconferencing experiment between LeRC and HRL. LeRC transm
wo identical video streams with video tool vic [9] to HRL simultaneously, one over terrestrial MB
d the other over MBone over ACTS. At HRL, two workstations receive the streams respectively, a
cord the following quality of service (QoS) parameters at the receiver: packet loss, delay jitter,
ndwidth, and frame rate. We set the transmission rate at the source at 128 Kbps and 8 frames per
cond. (Because of the current MBone bandwidth restriction on the terrestrial Internet, we limited th
ndwidth to 128 Kbps, otherwise the performance advantage of MBone over ACTS would be even
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (14 of 16)25/8/2549 17:27:59
-
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
15/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
gger.) The following table shows the performance comparison for each QoS parameter.
Measurement bandwidth frame ratetransient packet loss
rate
packet delay
variation
Results in
igure (clickor details)
he first and second charts compare packet loss and delay jitter. Along the terrestrial MBone path, th
cket loss rate is well above 70 (first chart) and jitter occasionally hits 200 milliseconds or more
econd chart). These results translate into poor performance through low frame rate and low bandwi
he third chart shows that the video bandwidth received over terrestrial MBone is only one-fourth of
at received over ACTS, and the fourth chart shows that the frame rate over terrestrial MBone is onlne-sixth. However, we observe no packet loss over ACTS from the first chart, and from the second
art jitter was kept under 100 milliseconds. Consequently, the receiver gets the original bandwidth a
ame rate transmitted by the sender. These results imply that the use of GEO satellites as part of MB
n deliver high-quality services to end users in a bandwidth- and cost-effective manner.
onclusion
atellite networks promise a new era of global connectivity, but also present new challenges to comm
ternet applications. In this work, we have shown that many popular Internet applications perform to
er expectation over satellite networks, such as videoteleconferencing, MBone multicast, bulk data
ansfer, background electronic mail, and non-real-time information dissemination. Some other
plications, especially highly interactive applications such as Web browsing, do suffer from the
efficiencies of the current TCP standard over high-bandwidth long-latency links. However,
rformance of these applications can be improved by utilizing many of the techniques discussed in t
per. In the long term, further improvements can be made at the protocol level by extending the cur
CP standard, although much work needs to be done on possible extensions to ensure that they do no
gatively affect the Internet as a whole.
Acknowledgments
e would like to extend our thanks to NASA Lewis Research Center for its assistance in some of the
tellite experiments. We would also like to thank the Hughes Spaceway Group for valuable feedbac
d technical assistance.
ttp://www.isoc.org/inet97/proceedings/F5/F5_1.HTM (15 of 16)25/8/2549 17:27:59
http://www.isoc.org/inet97/proceedings/F5/F5_1Q.GIFhttp://www.isoc.org/inet97/proceedings/F5/F5_1O.GIFhttp://www.isoc.org/inet97/proceedings/F5/F5_1M.GIFhttp://www.isoc.org/inet97/proceedings/F5/F5_1K.GIF -
8/7/2019 Satellite Communications in the Global Internet_ Issues, Pitfalls, And Poten
16/16
atellite Communications in the Global Internet: Issues, Pitfalls, and Potential
eferences
1. E. Amir. A map of the MBone: August 5th, 1996. http://www.cs.berkeley.edu/~elan/mbone.h
2. R. Braden. Extending TCP for transactions-concepts. Internet Request for Comments RFC 13
November 1992.
3. L. S. Brakmo, S. W. O'Malley, and L. L. Peterson. TCP Vegas: New techniques for congestio
detection and avoidance. ACM SIGCOMM 1994, pages 24-35, May 1994.
4. R. C. Durst, G. J. Miller, and E. J. Travis. TCP extensions for space communications.
Proceedings of the 2nd ACM Conference on Mobile Computing and Networking, November
1996.
5. S. Floyd and V. Jacobson. Random early detection gateways for congestion avoidance. IEEE/
ACM Transactions on Networking, 1(4):397-413, August 1993.
6. V. Jacobson, R. Braden, and D. Borman. TCP extensions for high performance. Internet Requ
for Comments RFC 1323, May 1992.
7. M. R. Macedonia and D. P. Brutzman. MBone provides audio and video across the Internet.
IEEE Computer, 27(4):30-36, April 1994.
8. S. McCanne. ns - lbnl network simulator. http://www-nrg.ee.lbl.gov/ns/.
9. S. McCanne and V. Jacobson. vic: A flexible framework for packet video. ACM Multimedia
November 1995, San Francisco, California, pages 511-522, November 1995.
10. W. R. Stevens. TCP/IP Illustrated, Volume 3. Addison-Wesley Publishing Company, 1996.
11. Y. Zhang and S. K. Dao. HBX: High bandwidth X for satellite internetworking. In Proceedin
of the 10th X Technical Conference, X Resource, Issue 17, February 1996.
12. Y. Zhang and S. K. Dao. Integrating Direct Broadcast Satellites with Local Wireless Access,
Proceedings of the First International Workshop on Satellite-Based Information Services
(WOSBIS), Rye, New York, November 13, 1996.
http://www.cs.berkeley.edu/~elan/mbone.htmlhttp://www-nrg.ee.lbl.gov/ns/http://www-nrg.ee.lbl.gov/ns/http://www.cs.berkeley.edu/~elan/mbone.html