satellite communications in the global internet_ issues, pitfalls, and poten

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


2/16


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



3/16


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])



4/16


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.



5/16


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



6/16


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



7/16


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.



8/16


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)

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


9/16


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.



10/16


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.



11/16


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.



12/16


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.



13/16


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.



14/16


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



15/16


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.

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


16/16


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

satellite communications in the global internet_ issues, pitfalls, and poten

Documents