Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Design and performance evaluation of multicast transport protocols over broadband satellite network Wang, Chen 2002

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_2002-0597.pdf [ 3.58MB ]
Metadata
JSON: 831-1.0065182.json
JSON-LD: 831-1.0065182-ld.json
RDF/XML (Pretty): 831-1.0065182-rdf.xml
RDF/JSON: 831-1.0065182-rdf.json
Turtle: 831-1.0065182-turtle.txt
N-Triples: 831-1.0065182-rdf-ntriples.txt
Original Record: 831-1.0065182-source.json
Full Text
831-1.0065182-fulltext.txt
Citation
831-1.0065182.ris

Full Text

D E S I G N A N D P E R F O R M A N C E M U L T I C A S T  E V A L U A T I O N O F  T R A N S P O R T P R O T O C O L S  B R O A D B A N D  S A T E L L I T E  O V E R  N E T W O R K  by Chen Wang  M.A.Sc. of Biomedical Engineering, PLA Postgraduate Medical School, China, 1988 B.S. of Electrical Engineering, Chendu Meteorology Institute, China, 1985 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES DEPARTMENT OF ELECTRICAL COMPUTER ENGINEERING We accept this thesis as conforming to the required standard  THE UNIVERSITY OF BRITISH COLUMBIA August 2002 ©Chen Wang,  2002  in  presenting  degree freely  at  this  the  available  copying  of  department publication  of  in  partial  fulfilment  University  of  British  Columbia,  for  this or  thesis  reference  thesis by  this  for  his thesis  and  study.  scholarly  or for  her  of I  I further  purposes  gain  requirements  agree  that  agree  may  be  It  is  representatives.  financial  the  shall  not  that  the  Library  an  granted  by  allowed  the that  without  for head  DE-6  tH-^^^'^jJl  of  T h e U n i v e r s i t y o f British Vancouver, Canada  Columbia  Date  £JK-1  (2/88)  J^/Pi  . l(> ,  Co^jj^f^r  make  it  extensive of  my  copying  or  my  permission.  Department  advanced  shall  permission  understood be  for  < £ y ^ \  written  Abstract Over the past several years, a number of new satellite systems have been proposed in an attempt to provide high-speed Internet and multimedia services to businesses and home users. These proposals are driven by network operators' desire to reach end users who do not have cost effective access to other alternatives, such as fiber and cable. While the use of satellites provides the most flexible way to globally extend networks, most protocols are optimized to run on terrestrial networks. The primary differences between terrestrial and satellite connectivity are the link latency and error rates. Satellite links often suffer higher error rates and larger latency than terrestrial links. Terrestrial links also have much more available bandwidth than their satellite counterparts, making satellite bandwidth a precious resource that cannot be wasted.  A number of network applications require the use of reliable multicast protocols to disseminate data from one source to a potentially large number of receivers. Broadband satellite networks are well suited to support such applications. Although reliable multicast protocols for the Internet have received much attention, not much work on these protocols for satellite networks has been conducted. The objective of our work is to develop window-based, satellite reliable multicast transport protocols ( S R M T P s ) for bulk data transfer over broadband satellite networks. The proposed protocols guarantee reliability while achieving high throughput and maintaining low end-to-end delay. Satellite onboard processing ( O B P ) is used to split uplink and downlink channels. A different automatic retransmission request ( A R Q ) is used for error recovery in each link. O B P can detect uplink packet losses in advance and report the losses to the source, thus avoiding the uplink losses faced by all downlink users. Onboard buffering ( O B B ) is employed to recover downlink errors to reduce retransmission time. We evaluated the S R M T P ' s performance  11  iii  through simulations. Results show that SRMTP generally outperforms the existing multicast protocol, M F T P (Multicast File Transfer Protocol), in terms of network delay and system throughput. The performance is further enhanced by OBP and OBB. Based on the simulation, we contend that SRMTPs are indeed scalable, efficient reliable multicast transport protocols over satellite broadband networks.  Table of Contents Abstract  i'  List of Tables  vii  List of Figures  viii  Acknowledgment  x  Chapter 1  Introduction  1  1.1  Satellite vs. Terrestrial  2  1.2  Multicast vs. Unicast  4  1.3  Satellite Multicast  4  1.4  Quality of Service (QoS) Requirements of Multicast  5  1.5  Motivations  6  1.6  Proposed Protocol Design  8  1.7  Objectives and Contributions  9  1.8  Outline  10  Internet Multicast Protocols  11  2.1  Introduction  11  2.2  Internet TCP/IP Protocol S ui te  12  2.3  IP Multicast  13  2.4  Transport Layer Issues of Multicast  14  2.5  Reliable Multicast Protocol Design Issues  15  2.6  Broad Categories of Reliable Multicast Protocols  17  2.6.1 Sender-Initiated  18  2.6.2 Receiver-Initiated  18  Chapter 2  V  2.7  2.6.3 Hierarchical Tree-Based Receiver-Oriented  19  Existing Internet Reliable Multicast Protocols  20  2.7.1 Multicast File Transfer Protocol ( M F T P )  20  2.7.2 Reliable Multicast Transport Protocol ( R M T P )  .-.  22  2.7.3 Distributed Error Recovery Satellite Multicast ( D E R S M )  24  2.7.4 Other Satellite Multicast Protocols  26  Broadband Satellite Communications  27  3.1  Bent-pipe Satellite Relay Conventional Satellite  27  3.2  Switch-in-the-sky  28  3.3  Satellite with O B P  29  Chapter 4  Proposed SRMTPs  33  4.1  System Architecture  33  4.2  Protocol Overview  34  4.3  Header Information  36  4.4  Protocol Description  40  4.5  Window Size  45  Design of Simulation Models and Discussions of Simulation Results  47  5.1  Design of Simulation Models  47  5.2  System Configuration  49  5.3  Impact of L i n k Condition  50  5.4  Effect of Protocol Architecture  54  5.5  Effect of S R M T P Parameters  58  5.5.1 Effect of Window Size on the System Performance  58  Chapter 3  Chapter 5  5.5.2 Effect of Buffer Size on the System Performance for SRMTP_OBB  59  5.5.3 Effect of File Size on System Throughput  60  5.6  Performance Comparison of SRMTP  62  5.7  Performance Comparison Between M F T P and SRMTP  70  Conclusions  75  6.1  Summary of the Work  75  6.2  Future Work  77  Chapter 6  Acronyms  79  Bibliography  82  List of Tables Table 2.1  Multicast Applications [30]  15  Table 5.1  Simulation Parameters for S R M T P Models  49  Table 5.2  Packet Error Rate with Different B E R  51  Table 5.3  Number of Receivers which Face L i n k Deterioration for Different User Groups Under Certain Degraded Ratio  65  vii  List of Figures Figure 2.1  TCP/IP Reference Model  12  Figure 2.2  IPv4 Multicast Address Format  14  Figure 2.3  Multi-level Hierarchy in R M T P [15]  23  Figure 3.1  Satellite OBP System [9]  28  Figure 3.2  Broadband Satellite Network Model  32  Figure 4.1  Architecture of Broadband Satellite Network  33  Figure 4.2  Layered Architecture of Proposed Multicast Protocol  34  Figure 4.3  Encapsulation of Multicast Data In an IP Datagram  36  Figure 4.4  The Multicast Header  37  Figure 4.5  Status Message (SM) Packet Structure  37  Figure 4.6  Satellite to Source Acknowledgment Packet Structure  39  Figure 4.7  Flowchart of SRMTP Sender's Operation  41  Figure 4.8  Flowchart of SRMTP_NOB Satellite's Operation  41  Figure 4.9  Flowchart of SRMTP_OBP Satellite's Operation  42  Figure 4.10  Flowchart of SRMTP_OBB Satellite's Operation  43  Figure 4.11  Flowchart of SRMTP Receiver's Operation  44  Figure 4.12  Parameters Related to Window-Size Calculation  46  Figure 5.1  Network Model  48  Figure 5.2  Pseudo-Code of PCR Analysis  51  Figure 5.3  Channel B E R vs. Packet Corruption Ratio, with and without OBP  52  Effect of BER on System Delay for Bent-pipe, with OBP and OBB  53  Figure 5.4  viii  Figure 5.5  Effect of BER on System Throughput for Bent-pipe, with OBP and OBB  54  Figure 5.6  Number of Corrupted Copies of a Multicast Packet, Link BER=10"  56  Figure 5.7  Number of Corrupted Copies of a Multicast Packet, Link BER=10"  Figure 5.8  Effect of Window Size on System Throughput for SRMTP_NOB  59  Figure 5.9  Effect of Buffer Size on System Throughput for SRMTP_OBB  60  Figure 5.10  Effect of File Size on System Throughput for SRMTP_NOB  61  Figure 5.11  Network Delay of SRMTPs under Link BER of 10"  7  62  Figure 5.12  Network Delay of SRMTPs under Link BER of IO"  63  Figure 5.13  System Throughput of SRMTPs with no Degradation  Figure 5.14  System Throughput Versus Receivers with Link Degradation of 10" for SRMTP_OBB  6  Figure 5.15  System Throughput Versus Receivers with Link Degradation of 10" for S R M T P J 3 B P  6  Figure 5.16  6  67  67  System Throughput Versus Receivers with Degraded Link BER of IO" , for SRMTPJDBB  68  System Throughput Versus Receivers with Degraded Link BER of IO" , for SRMTP_OBP  69  5  Figure 5.19  66  System Throughput Versus Receivers with Degraded Link B E R of IO" , for SRMTP_NOB  5  Figure 5.18  57  64  6  Figure 5.17  6  System Throughput Versus Receivers with Degraded Link B E R of 10" , for SRMTP_NOB  70  Figure 5.20  Effect of BER on Network Delay for M F T P and SRMTPs  72  Figure 5.21  Throughput Comparison of M F T P and SRMTPs, Link BER=10"  5  7  73  Acknowledgment  I would like to express my sincere gratitude to my research supervisor, Dr. Victor C M . Leung, for his guidance, support and insight throughout this thesis work and my education at U B C . His critical reviews and many constructive suggestions were essential to the completion of this work. Without his guidance this work could not have been done. For the financial support of this work, I would also like to thank Com Dev International and the Canadian Institute for Telecommunications Research under the N C E program of the Canadian Government, and the Canadian NSERC/CSA Partnership Program for grant CSA223232-98.  Many thanks to the members of the examination committee, Dr. Vincent Wong and Dr. Robert W. Donaldson, for their time and effort. Thanks also go to Ms Kirsty Barclay, Ms Lisa Beckett and Mrs. Barbara Greenway for proofreading.  Finally, I would like to offer my appreciation for the love and encouragement from my family and friends.  Chapter 1 Introduction  Recently, the interest in broadband satellite networks has grown rapidly. T h r o u g h advances in transmission technology, low-cost earth terminals with interfaces to standard terrestrial networks have become available. The superior remote access capabilities of satellite networks enable the satellite to provide bandwidth on demand to geographically diverse user groups. This is clearly evident in the ongoing development of several large-scale, space-based networks, such as T e l e d e s i c [ l ] , Galaxy/Spaceway[2], and Astrolink[3]. Overall, these trends represent a significant departure from the traditional fixed-circuit broadcast (i.e., for telephony and television). The desire to support a diverse range of services in satellite networks implies that many features inherent in broadband networks, such as the Asynchronous Transfer Mode ( A T M ) and the Internet Protocol (IP), will also emerge in satellite networks [3][4][5][6][7].  Satellite-system infrastructure plays an important role in providing wide area connectivity. Satellite communication systems strengthen the capabilities of telecommunication networks in the following ways [6]:  •  Providing global connectivity anywhere and anytime  •  Providing cost-effective broadcast/multipoint services  •  Reaching remote, inaccessible areas  •  Providing connectivity in areas where the terrestrial infrastructure has been damaged  In the past, geostationary satellites have been used with the Internet primarily to provide backbone connections for regional computer networks. M o r e recently, very small aperture  1  Chapter I Introduction  2  terminal ( V S A T ) technology makes satellites economically interesting for linking individual enduser stations to enterprise networks, and for interconnecting local networks [5].  1.1 Satellite vs. Terrestrial  Currently, the vast majority of existing satellite systems are geostationary orbit ( G E O ) satellites, which permanently remain in the same place in the sky. A t an altitude of approximately 35,780 km (22,291 miles), satellites can receive, amplify, and retransmit radio signals for most of a hemisphere. Thus, with one relay via a satellite, a single transmitter on the ground can reach nearly half the world. With three relays it can reach the whole world [8]. The inherent properties of satellite systems lead to a number of important characteristics:  •  The ability to provide service and aggregate traffic over wide areas  •  The ability to allocate resources (e.g., bandwidth) to different users over the coverage region as needed  •  Distance-insensitive costs  •  The ability to provide coverage to mobile users operating over wide areas, including rural areas, water areas, and large volumes of air space  •  The ability to easily provide point-to-multipoint (broadcast), multipoint-to-point (data collection), and point-to-point communications  •  The ability to have direct access to users and user premises  C o m m u n i c a t i o n satellites are ideal for broadcast (point-to-multipoint) applications because of their large area coverage and their distance insensitivity. Another subtle characteristic  Chapter I Introduction  3  that is evident in this application is the quality of the link. The altitude of these satellites over their coverage regions results in a single hop communications link between the distributed earth station and the user earth station, which involves a line-of-sight uplink to the satellite, and a corresponding line-of-sight downlink from the satellite. Each link can be modeled as an additive Gaussian white noise channel, which can be designed to deliver high quality end-to-end service. This single-hop-access directly to the user, in many cases, can result in a higher quality of service than for terrestrial links, which may require many router hops (potentially congested) before the signal is delivered to the user [9].  W h i l e the use of satellites provides the most flexible way to globally extend networks, there are a number of issues that need to be addressed. The high altitude of a satellite system imposes a significant propagation delay on the transmission of the traffic, which introduces problems, especially for delay sensitive applications. In G E O satellites, delay is lower-bounded by 250 ms [8]. The satellite channel has a higher error rate than the terrestrial link does, and it suffers sporadic burst losses, especially during heavy precipitation. Some satellite networks are inherently bandwidth asymmetric [10][11], such as those based on a direct broadcast satellite downlink and a return via a dial up modem line. For purely G E O systems, bandwidth asymmetries may exist for many users due to economic factors. For example, many proposed systems offer users with small terminals the ability to download at tens of M b i t s / s ; however, due to uplink carrier sizing, uplinks are limited to rates of several hundred kbits/s or a few Mbits/s, unless a larger terminal is purchased [10].  The primary differences of terrestrial and satellite connectivity pose many challenges in designing satellite protocols because most existing protocols are optimized to run on terrestrial  Chapter 1 Introduction  4  networks. In addition, terrestrial links typically have much more available bandwidth than their satellite counterparts, making satellite bandwidth a precious resource that cannot be squandered. These characteristics may greatly influence the transport protocols and their performances [5].  1.2 Multicast vs. Unicast  M u l t i c a s t i n g is a means of one-to-many communication. The most common form of communication is one-to-one. The well-known client-server model belongs to this category. The W o r l d W i d e Web ( W W W ) is a classic example of unicast c o m m u n i c a t i o n where the client (browser) communicates with a server in order to retrieve various types of information. On the other extreme is broadcast communication, which is one-to-all, by definition. Radio and television are typical examples of broadcast communication. Multicast communication lies in between unicast and broadcast communication in the sense that multicast is a means of one-to-some communication [12].  Multicasting provides an efficient way of disseminating data from a sender to a group of receivers [13][14][15]. Instead of sending a separate copy of the data to each individual receiver, the sender sends a single copy to all receivers. Multicasting makes efficient use of bandwidth. IP multicasting [16] is an important service, which will be provided by the next generation Internet.  1.3 Satellite Multicast  Several factors currently hinder the large-scale deployment of terrestrial multicast services. These include a wide range of application requirements, various network topologies, and specific problems associated with simultaneous communication by clients with different capabili-  Chapter I Introduction  5  ties (heterogeneity). It is particularly difficult to support delivery to large groups of users.  Satellites offer a natural way of extending multicast service to large numbers of users. This is in contrast with the difficulties in providing large-scale terrestrial multicast networks, such as traversing several (potentially congested) router hops, and thus incurring packet delays. They may offer high capacity (especially when using next generation satellite systems) and also eliminate the need for a large number of intermediate routing hops [17].  1.4 Quality of Service (QoS) Requirements of Multicast  Each multicasting application has different requirements. Most real-time applications can tolerate some data loss, but cannot tolerate the delay associated with retransmissions-they either accept some loss of data or use forward error correction ( F E C ) to minimize such loss [14]. The multicasting of multimedia information receives a great deal of attention. The main objective of these multicast protocols is to guarantee quality of service by reducing end-to-end delay at the cost of reliability. However, many important applications require error-free transmissions. These applications include the distribution of software, financial information, electronic newspapers, billing records, and medical images [15]. Absolutely reliable multicasting is an important issue that needs to be addressed. Although many studies focus on reliable multicast services on Internet links [15][18][19][20][21], very little work addresses the problem of reliable multicast transport over satellite links.  Chapter 1 Introduction  6  1.5 Motivations  Today, there is no one-size-fits-all protocol that can optimally serve the needs of all types of multicast applications. Instead, most multicast protocols are designed to stress some criteria while neglecting others. The trend is to develop a range of multicast protocols suited for individual applications and network topology requirements.  There are several motivations behind the work on design reliable multicast protocols over satellite networks.  First, because of the broadcast nature and the large round trip time (RTT) of the satellite, we believe satellites are more suitable for non-real time multicast applications.  Second, most of the existing satellite-reliable multicast studies use error-free terrestrial links as a return path for acknowledgments [22][23][24], which we believe is unrealistic in many cases. For receivers in rural areas where no wire line is available, it is impossible to send acknowledgments ( A C K s ) through terrestrial links. Also, for mobile terminals, such as those in battle, it is not possible to build a fixed line with the sender. Therefore this thesis considers a full-duplex satellite system that uses satellite links for both forward and return paths instead.  Third, except for the system architecture mentioned above, most of the existing multicast protocols cannot scale to a large number of receivers [23] [24] [25] because they usually restrict the receivers to less than a hundred. However, in some applications, there maybe hundreds or even thousands of simultaneous recipients. Supporting a large group of users is also one of our motivations.  Chapter 1 Introduction  7  Fourth, based on the above analysis, our goal is to design a satellite-reliable multicast transport protocol ( S R M T P ) which can scale to a large group of receivers using a full-duplex satellite system. The only study which achieves the same design goal is the M F T P (Multicast File Transfer Protocol) [26], proposed by StarBurst. However M F T P does not have a flow control scheme. M F T P divides its protocol into two phases: first, the transportation of the entire file; second, the retransmission of lost packets after receiving N A C K s . Based on experience with Transmission Control Protocol (TCP), we assume that it is better to control flow using a windowbased scheme for multicast applications. The comparisons of the performance of S R M T P s and M F T P are presented later.  Finally, in most designs, G E O satellites are bent-pipe satellites [23][24][25][26][27]. Satellite routers relay the information on the uplink to the downlink channel without onboard processing, switching, or routing. This confines the appropriateness of the satellites from a broad system environment to that of a simple interconnection of two earth stations. The envisaged future broad system environment consists of various earth terminals with different quality of service requirements and traffic source descriptions. Therefore, the new satellite system requires onboard processing, switching, and routing, in addition to various medium access technologies [3][5]. U s i n g satellite onboard processing ( O B P ) and onboard buffering ( O B B ) to participate in the transmission may greatly improve the performance of the protocols. Our design considers both bent-pipe satellites and O B P / O B B satellites for the current and future needs of the industry.  Chapter I Introduction  8  1.6 Proposed Protocol Design  Based on the architecture of the underlying satellite system, sending A C K s through a long round trip time (RTT) link greatly affects performance because the A C K s cannot reach the sender in time. A l s o , packet collision and corruption in the return path are considered in our proposal, while most of the existing protocols simply ignore error possibility, and thus assume lossless. For a shared satellite link where all users must compete in order to send messages, collision is more rigid than corruption in the satellite channel. It is necessary to find a way to send timely acknowledgments to the sender while avoiding collision. This is accomplished by adopting a round robin T D M A in order to reduce collision.  A window-based scheme is used to control the flow of data. The idea comes from using a T C P - l i k e protocol to realize multicasting. Due to the unique properties of satellite links, the window scheme must be modified to improve performance, as T C P over satellites. The ideas of Internet multicast protocol Reliable Multicast Transport Protocol ( R M T P ) [15] are also used in the proposal. R M T P uses a hierarchical structure, divides receivers into sub-groups, and distributes retransmission responsibility over an acknowledgment tree structure. In each domain, there is a special receiver called a designated receiver (DR). The D R sends status messages to the sender. In our satellite system, satellite onboard processing ( O B P ) and onboard buffering ( O B B ) are used as D R s to enhance multicasting. Since there is only a two-layer hierarchical structure, the number of acknowledgments is very large, even when using a bitmap such as R M T P , so it is impossible to send them all to the satellite using a round robin method. A s a result, a modified status message which combines positive A C K with negative acknowledgment ( N A C K ) is used for the error recovery approach.  Chapter 1 Introduction  9  1.7 Objectives and Contributions  The objectives of the thesis are the following:  •  To develop satellite reliable multicast transport protocols ( S R M T P s ) for bulk data transfer over broadband satellite networks  •  To guarantee reliability while achieving high throughput and maintaining low end-toend delay  •  To evaluate through simulations the performance of S R M T P s for the reliable and efficient transport of bulk data to a large group of users  •  To present performance comparisons of S R M T P with O B P ( S R M T P _ O B P ) to S R M T P with bent-pipe satellite ( S R M T P _ N O B )  •  To examine the parameters' effect on throughput in the performance evaluation  •  To compare the performance of M F T P and S R M T P  •  To consider partial receivers' encounter with link degradation.  The main contributions of this thesis are as follows:  We propose a novel satellite reliable multicast transport protocol ( S R M T P ) which takes into account a full-duplex satellite system which uses satellite links for both forward and return paths, and accounts for packet corruption and collisions over the return link. This is more realistic than other studies that use error-free terrestrial return links.  We investigate S R M T P schemes and their performance in a satellite communications  Chapter I Introduction  10  system with OBP and OBB capability. A positive acknowledgment (ACK) mechanism is combined with a more general negative acknowledgment (NACK) error recovery approach for error recovery. Satellite links are split into uplink and downlink channels and different error recovery schemes are applied in each link.  1.8  Outline  The rest of this thesis is organized as follows. Chapter 2 provides an overview of the multicast protocols. Chapter 3 introduces broadband satellite communication systems. Chapter 4 presents the proposed protocols and system architecture. Chapter 5 presents the design of simulation models and discusses the simulation results. Chapter 6 concludes the thesis with a summary of the findings and provides directions for future research.  Chapter 2 Internet Multicast Protocols  2.1 Introduction  Multicasting is a means of one-to-many communication and many multicast applications can be described by the one-to-many models. These applications all involve sending the same information to multiple receivers at the same time. Multicast applications can be divided into three broad categories based on reliability and latency requirements. Interactive real-time applications, such as conferencing, have very stringent latency requirements. The typical end-to-end latency requirement for this category of applications is of the order of 100 ms. Real-time applications can tolerate some loss because of the inherent redundancy in audio and video data. On the other hand, reliable multicast applications, such as document distribution or software distribution, require 100% reliability. Latency is not as big an issue for these applications as for interactive real-time applications. The third category of applications is one-way, non-interactive real-time streaming applications, which falls between these two extremes in the sense that it has less stringent latency requirements than interactive real-time applications, while its reliability requirements are not as rigorous as those of reliable multicast applications. For example, streaming music or movies belongs to this category [12]. Some more examples of multicasting are web server replication, distribution of stock quotes and billing data, distance learning, and distributed database applications. The fundamental need of multicast applications is selective distribution. That is, the data transmitted by a sender must be received by only a subset of machines (multicast group) in the network, as opposed to by all the machines in the network [12].  12  Chapter 2 Internet Multicast Protocols  Examples: Application  Telnet, FTP, SMTP, HTTP  Transport  TCP, UDP  Network  IP, ICMP, IGMP  Link  Ethernet, FDDI  Figure 2.1 T C P / I P Reference Model  2.2 Internet TCP/IP Protocol Suite  The Transmission Control Protocol/Internet Protocol ( T C P / I P ) suite is a networking protocol suite with a combination of different protocols at various layers. Figure 2.1 shows the 4layer network system for TCP/IP. This protocol suite allows different kinds of computers, running on different operating systems, to communicate with each other over the worldwide Internet. Each layer is responsible for a particular aspect of the communication problem. Each layer delivers its services to the layer above it, and communicates with its peer at the same layer using one or more protocols of that layer. The application layer is the top layer in the T C P / I P models. It handles the details of specific network applications and user processes. C o m m o n application protocols include Telnet for remote terminal access, File Transfer Protocol (FTP) for file transfer, Simple M a i l Transfer Protocol ( S M T P ) for electronic mail, and HyperText Transfer Protocol (HTTP) for accessing W W W documents. The next layer is the transport layer. It is responsible for the end-toend flow of data between end hosts. The application layer relies on the services of the transport layer to deliver data to, and receive data from, the remote application. Transmission Control Protocol ( T C P ) and User Datagram Protocol ( U D P ) are two transport protocols in the T C P / I P  Chapter 2 Internet Multicast Protocols  13  model. T C P provides a reliable flow of data between the end hosts, while U D P promises only a best-effort datagram delivery service. The layer below the transport layer is the network layer, sometimes known as the Internet layer. The network layer is responsible for the movement of packets around the Internet. The main protocol in this layer is the IP (Internet Protocol), which handles packet routing from source to destination across the network. Other protocols include the Internet Control Message Protocol ( I C M P ) for communicating error and control messages, and the Internet Group Management Protocol ( I G M P ) for IP multicasting. The last layer is the link layer, also called the network interface layer. It handles communication over a specific physical network, such as the Ethernet.  With the T C P / I P protocol suite, the underlying architecture and communication technologies of the individual physical networks are hidden below the network layer. From the user's point of view, the Internet is a single, virtual, packet-switched network, connected by IP routers [28].  2.3 IP Multicast  Internet multicast protocols have two areas: IP multicast and transport layer multicast. IP multicast deals with the set-up of the multicast tree at the network layer for point-to-multipoint and multipoint-to-multipoint communication. Multicast routing protocols, together with the I G M P , set up the multicast tree at the IP layer of the Internet. Once the multicast tree is set up, a sender can transmit as though it is transmitting to a single destination, which is an abstract group address. The actual replication is done by the routers in the multicast tree so that the packets are eventually delivered to the group members [12].  IPv4 uses a special type of address, called the Class-D address, for multicasting. Class-D  14  Chapter 2 Internet Multicast Protocols  32 Bits J  1110  i  i  i  i  i  i  i  I  i_  Multicast address  Figure 2.2 IPv4 Multicast Address Format addresses use 1110 as the first four significant bits in a 32-bit IP address, as shown in Figure 2.2. These addresses range from 224.0.0.0 to 239.255.255.255 [16]. A n y IP packet with an address belonging to the above range is an IP multicast packet destined to a specific group of host machines. The idea in IP multicast is to decouple the sender from the receivers [28]. That is, the sender should not know the identity of the receivers, and still be able to communicate with them. On the other hand, it is the responsibility of the receivers to initiate a j o i n i n g to the desired multicast group.  IP multicast, just like IP, is a best-effort service. The network does not guarantee the delivery of packets. IP packets are treated with essentially equal weight. While IP makes an effort to deliver all packets to their destination, packets may occasionally be delayed, lost, duplicated, or delivered out of order.  2.4 Transport Layer Issues of Multicast  The transport layer deals with end-to-end issues for both real-time and non real-time traffic. The fundamental problems for non real-time reliable transport are reliability and flow control. Scalability and end-to-end latency are important for both real-time and non real-time multicast transport [12]. A variety of multicast applications are shown in Table 2.1. The network layer provides best-effort delivery service for point-to-multipoint communication, as mentioned  15  Chapter 2 Internet Multicast Protocols  Table 2.1Multicast Applications [30] Real-time  Multimedia  Data-only  Non-real-time  Video server Video conferencing Internet audio Graphics + audio Interactive gaming  Replication: Video & web server Content delivery Intranet & Internet  Stock quotes News feeds White boarding  Data delivery server-server Server-desktop DB replication SW distribution  above. The mechanisms for guaranteeing delivery are typically built into the transport layer. This thesis addresses reliable multicast protocols in this layer.  2.5 Reliable Multicast Protocol Design Issues  Reliable multicast protocols deal with the desire to offer applications that can deliver reliable data to many recipients simultaneously, and with network efficiency. Depending on the traffic characteristics and the underlying network, the multicast data distribution may provide the following different levels of reliability to meet the Quality of Service (QoS) requirements of the application [15][29]: •  Absolute reliability: all packets in a session must be delivered reliably to the receivers. The individual receivers of the multicast group do not tolerate any loss of data. The correct delivery of data is guaranteed by an Automatic Repeat Request (ARQ) based retransmission scheme, where receivers acknowledge the receipt of sent data. The sender's knowledge of all group members at the establishment of a multicast con-  Chapter 2 Internet Multicast Protocols  16  nection is needed in order to ensure reliable data transmission to all receivers. This is the form of reliability that is commonly supported by TCP at the transport layer for unicast sessions. •  Best effort reliability: reliable delivery is not fully guaranteed, and receivers may tolerate a certain packet loss rate. This is similar to that provided by the UDP based IP multicast.  •  Bounded latency: requires that each packet adheres to a specified lifetime over which the data is useful to the receiver. This is defined as an upper bound on its delivery latency. Packets arriving outside this time frame are discarded.The common application requiring bounded latency is a video stream. Each packet has a "playback" time, and any packet not meeting this deadline is discarded.  •  Most recent reliability: only the most recent data of a particular parameter is of interest. If a particular data is lost, and a new update is received before a retransmission can occur, the old data is rendered useless. Most recent reliability is a common requirement of many distributed services. One example of this service is stock updates.  Another issue which should be considered in designing reliable multicast protocols is scalability. A simple multicast data service may send data to only a small group of receivers. However, in some anticipated applications, there may be hundreds of receivers, or even thousands of simultaneous receivers per group. In the future, direct-to-home application could even address millions of simultaneous receivers. To date, very few wide area multicast applications support more than tens of thousand of receivers in a single group [17]. For wide area multicast, the main difficulty is coping with heterogeneity. The protocol should perform reasonably well, even in  Chapter 2 Internet Multicast Protocols  17  large groups, and for group members with greatly different Internet connectivity. These requirements are hard to meet, and the difficulties cannot be completely hidden behind the interface of the application. The criteria, however, often have competing aims, and no single reliable multicast protocol architecture can meet them all simultaneously. Instead, most multicast protocols are designed to stress some criteria and neglect others.  2.6 Broad Categories of Reliable Multicast Protocols  There has been an explosion of the number of reliable multicast protocols over the Internet in the last few years [12][15][18][19][20][21]. Regardless of the number of such protocols, they can be broadly categorized into different classes. The multicast data transfer can be constructed in various ways, and the existing protocol architectures use completely different techniques. A s a consequence, they differ in bandwidth consumption and the QoS they can offer to the application. Generally speaking, reliable multicast protocols over the M B o n e all use IP's best effort multicast delivery service [18][30], and provide mechanisms for at least error recovery, and possibly for flow control or congestion control as well [31].  M o s t of the existing multicast protocols evolved out of the necessity to solve specific problems. In spite of the differences in design criteria, there are a handful of unique features that can be used as criteria for grouping these apparently different protocols. One grouping criteria is "acknowledgment". Multicast protocols can be grouped into sender-initiated, receiver-initiated, and hierarchical tree-based receiver-oriented, according to acknowledgments.  Chapter 2 Internet Multicast Protocols  75  2.6.1 Sender-Initiated  Sender-initiated protocols are based on the use of positive acknowledgments (ACKs). The responsibility for reliable delivery is mainly on the sender. The sender monitors the reception state of each receiver through positive ACKs and issues repairs upon error detection. As the number of receivers increase, the system may suffer from ACK-implosion that causes severe performance degradations. Many early multicast protocols are based on this approach [32][33].  2.6.2 Receiver-Initiated  Receiver-initiated protocols are based entirely on negative acknowledgments (NACKs), shifting the burden of providing reliable data transfer to the receivers, thus avoiding ACK implosion at the source. Most of the current multicast protocols use NACK based schemes [18][26][34][35]. However, receiver-initiated protocols require infinite buffers to prevent deadlocks. Each receiver maintains the reception state and requests repairs via a NACK when an error is detected. Error detection is based on the receiver perceiving gaps in the data. It is required that individual packets be identified with either application level framing or generic transport sequence numbers, as in TCR Mixed levels of reliability can be achieved at a receiver, in receiver-initiated protocols. In sender-oriented protocols, upon the detection of errors receivers send NACK to the sender. While intermediate receivers may have received the data for which the NACK is issued, only the sender is involved in issuing repairs [26]. This approach is appropriate when receivers cannot communicate with each other. However, such an approach ultimately limits scalability due to a NACKimplosion effect at the sender for large receiver sets. It is best suited for the transmission of very  Chapter 2 Internet Multicast Protocols  19  large packets where a low ratio of NACK-to-data can be realized. This reduces the overall N A C K implosion.  U n l i k e in sender-oriented protocols, in flat receiver-oriented protocols receivers can communicate with each other to assist in error recovery [35]. Each receiver caches data for some time, for the entire session. The receiver multicasts a N A C K to the whole group, and the correctly received receiver may issue a repair to the specific receiver.  When a receiver detects an error, it is likely that other downstream and equidistant receivers also experience the error at roughly the same time. To reduce the chance of all such receivers issuing redundant N A C K s at once, each receiver sets a random timer upon error detection. When the timer expires, i f a N A C K for the missing data has not already been heard, the receiver issues a N A C K . The drawback of flat receiver-oriented protocols is that N A C K s and repairs are global in scope. They consume bandwidth for the whole group, even for isolated packet losses.  2.6.3 Hierarchical Tree-Based Receiver-Oriented Hierarchical tree-based receiver-oriented protocols are designed to support absolute receiver-initiated service. Supporting absolute reliability in a receiver-initiated approach imposes constraints on senders. Since senders are not tracking receiver status, at any point in the future a receiver may require a retransmission. Hierarchical tree-based protocols support absolute reliability by using some form of an A C K mechanism from the receivers, which allows the sender to periodically flush its buffers. This can be used in conjunction with a more general N A C K - e r r o r recovery approach, and should be used as infrequently as possible to reduce A C K implosion. These protocols require that the sender be aware of the set of receivers at any given time. A typical example in this category is R M T P [15]. Most tree-based protocols are characterized by  Chapter 2 Internet Multicast Protocols  20  d i v i d i n g receivers into sub-groups, and distributing retransmission responsibility over an acknowledgment ( A C K confirmed delivery) tree structure. This tree structure is built from a set of groups with the root of the sub-tree (a router or host within the network acting on behalf of the source). The hierarchical structure prevents receivers from contacting the source directly, enabling the protocols to scale over a large set of receivers. Successful deployment relies on the availability of enabled routers in the network.  G e n e r a l l y speaking, i f the number of recipients is s m a l l , a sender-initiated reliable approach is acceptable. If there are too many receivers, A C K implosion is a severe problem. In this case, receiver-initiated reliable schemes seem most appropriate for improving scalable performance, and with the appropriate N A C K suppression, they w i l l reduce the likelihood of control message implosion effects. To support absolute reliability, hierarchical tree-based schemes are made more appropriate by combining A C K and N A C K together.  2.7 Existing Internet Reliable Multicast Protocols  In this section, we discuss some multicast protocols specially designed for the Internet.  2.7.1 Multicast File Transfer Protocol (MFTP)  Multicast File Transfer Protocol ( M F T P ) is a receiver-initiated protocol proposed by the StarBurst Communications Corporation [26]. It is targeted to the non-real time bulk transfer of data, usually in the form of files, from one to many with reliable delivery. M F T P takes advantage of the non-real time nature of the delivery requirement to gain extra scalability and universal operation over all network infrastructures, including satellite and other asymmetric networks.  Chapter 2 Internet Multicast Protocols  21  M F T P divides a file into a sequence of fixed-size packets. E a c h packet has a unique sequence number. The packets to be sent are grouped into "blocks." The file is sent initially in its entirety in the first pass. Receivers write all data to a file, and leave appropriate space whenever they detect a packet loss. If all the packets are received correctly in a block, nothing is sent back to the sender. If one or more packets are in error or missing in a block, the receiver responds with a unicast N A C K - b i t m a p , reflecting the status (received/missed) of each data packet within the block. Receivers randomly delay the N A C K transmission to reduce the problem of implosion. The sender collects all N A C K packets, determines the set of data packets requested at least once, and retransmits those in a second pass. A g a i n , at the end of the second pass, receivers send back N A C K - b i t m a p s . This procedure may continue with a third or fourth pass, and so on, until all the receivers have completely received the file. Receivers leave the multicast group as soon as they have completed reception, causing the multicast tree to be pruned back.  M F T P is a " N A C K only" protocol. If data is received correctly in a block, nothing is sent back to the sender. If one or more packets are in error or missing in a block, receivers respond with a N A C K , which consists of a bitmap of the bad packets in the block. It is thus a selective retransmission mechanism. The protocol is very efficient with high latency networks, and is impervious to network asymmetry. It also attempts to be as scalable as possible on one-hop networks, such as satellites.  M F T P can scale very well to a large group of users i f the returning channel is error free and collision free. In this case, all acknowledgments can be sent back in a timely manner to the source without corruption and collision. For the system configuration this thesis is based on, simply using N A C K s is not enough. For a returning channel where collision and corruption exist,  Chapter 2 Internet Multicast Protocols  22  if a NACK is lost, the receiver has to wait until the next pass is complete, and then send the NACK again without any corruption. MFTP sends a NACK-bitmap to reflect the status (received/missed) of each data packet within the block, which by default consists of 1000's or 10,000's of packets, depending on the maximum transfer unit (MTU). For a large block, the NACK bitmap must be much longer than an ordinary NACK. Since large NACK-bitmaps increase NACK collisions in a high BER-shared return path in this architecture, MFTP may require several tries before the multicast packet can be correctly received; thus, it is not very suitable for this architecture. At the same time, MFTP does not provide anyflowcontrol.  2.7.2 Reliable Multicast Transport Protocol (RMTP)  RMTP is a tree-based transport-layer protocol for reliable multicasting, proposed by Sanjoy Paul in 1996 [15]. RMTP is designed with the objective of delivering large documents or software reliably to a very large number of receivers widely distributed over the Internet. The key ideas introduced by RMTP to the area of reliable multicasting are the notion of hierarchy to reduce/remove NACK/ACK implosion and to reduce end-to-end latency, and the notion of local recovery using sub-tree multicasts. RMTP groups receivers into local regions or domains. In each domain there is a special receiver, called a designated receiver (DR) (Figure 2.3). As a representative for the local region, it sends bitmap status messages (which are a combination of positive ACKs and NACKs) periodically to the DRs in the next tier of the hierarchy, thereby generating a single status message per local region. The DRs process status messages for the receivers in their domains, and retransmit lost packets to the corresponding receivers. Since lost packets are recovered by local retransmis-  23  Chapter 2 Internet Multicast Protocols  Sender  Receivers  Figure 2.3 Multi-level Hierarchy in R M T P [15]  sions as opposed to retransmissions from the original sender, end-to-end latency is significantly reduced, and the overall throughput is improved as well. A l s o , since only the D R s in the highest level of the hierarchy send their status messages to the sender (instead of all receivers sending their status messages to the sender), a single status message is generated per highest-level D R , and thus prevents acknowledgment implosion. Receivers in R M T P send their status messages to the D R s periodically, thereby simplifying the error recovery scheme. In addition, lost packets are recovered by selective repeat retransmissions, leading to improved throughput at the cost of minimal additional buffering at the receivers.  R M T P provides per-source, in-order delivery semantics. That is, R M T P receivers receive packets in sequence from the R M T P sender. Just as T C P provides a point-to-point reliable connection, R M T P provides a point-to-multipoint reliable connection. R M T P is expected to scale  Chapter 2 Internet Multicast Protocols  24  well in a wide-area network because of its multi-level hierarchy. In addition, retransmission traffic is confined to a local region. R M T P uses bitmap-positive A C K s for reliability, and a window for flow control. It avoids flooding the sender with A C K s by combining them as they flow back up the multicast tree. A n R M T P sender decreases its window when A C K s indicate that too many packets are being lost. D R s that buffer and re-send lost data do not report losses to the sender unless they run out of buffer space.  R M T P is mainly designed for Internet multicast. In the satellite systems developed in this thesis, onboard processing can be treated as a D R . The same idea underlying a D R in R M T P is used to design S R M T P s . A s well, R M T P is modified to fit satellite architecture characteristics.  2.7.3 Distributed Error Recovery Satellite Multicast (DERSM)  D E R S M is a sender-initiated, satellite reliable multicast protocol [22]. Different from the multicast protocols discussed so far, D E R S M uses positive A C K s to acknowledge the correct reception of packets. The author in [16] investigates the performance of two satellite-based reliable multicast schemes. One is with a local-error-recovery mechanism, and the other is without the m e c h a n i s m . C e n t r a l i z e d error recovery ( C E R ) a l l o w s retransmissions to be exclusively performed by the multicast source, which is also referred to as source-based recovery. Distributed error recovery ( D E R ) allows retransmissions to be potentially performed by all multicast members. The burden of recovery is decentralized over the whole group.  In the centralized error recovery satellite multicast ( C E R S M ) scheme, a satellite router s i m p l y works in a forward manner. The satellite router receives data from the sender and multicasts it to the receivers. To ensure reliability, a full memory point-to-multipoint S R A R Q  Chapter 2 Internet Multicast Protocols  25  (selective repeat automatic repeat request) protocol is employed between the sender and receivers. In the full memory point-to-multipoint S R A R Q , after a packet transmission, the sender must receive a positive A C K from only those receivers which did not acknowledge successfully during the earlier transmission attempts, before the packet can be released from the sender buffer. The sender ensures all the data packets are correctly received by all the receivers.  In the D E R S M scheme, the satellite router works in a store-and-forward manner. A l l data must be received correctly by the satellite router. The correctly-received data is then forwarded to all the receivers. The protocols applied in the source and receiver links are also SR A R Q . In the source link, a point-to-point SR A R Q scheme is applied between the transmitter and the satellite router. If a packet is received without errors, the satellite router sends an A C K to the transmitter. If a packet is correctly received from the transmitter, but there is no buffer reserved for the packet, it is simply discarded by the satellite router instead of being forwarded to the receivers, and a N A C K is sent to the transmitter. If a packet is received with errors, the satellite router sends a N A C K to the transmitter.  In D E R S M , the protocols applied in the source and receiver links are S R A R Q protocols, which limit the number of user groups. The satellite assumes the responsibility for reliable multicasting, and sends a premature A C K before receivers actually receive the packet correctly. U s i n g positive A C K s for packet recovery causes serious A C K - i m p l o s i o n , as mentioned earlier. D E R S M simply ignores the cost of the acknowledgment packets on the throughput, and assumes the feedback channel is error-free; these are all considered in this analysis.  Chapter 2 Internet Multicast Protocols  26  2.1 A Other Satellite Multicast Protocols  There are a few reliable multicast protocols designed for satellite l i n k s . G e n e r a l l y speaking, existing satellite multicast protocols assume an error-free back channel [23] or use terrestrial networks as a feedback channel [24]. Protocols in [23][25] use selective-repeat A R Q , combined with X O R (Exclusive-OR) for error recovery. Unlike forward error correction ( F E C ) , which sends the parity packets together with the information data in the first transmission, an X O R sender waits for a certain number of acknowledgments from different receivers. X O R packets are responded to by combining several N A C K s to minimize the number of retransmissions and to increase throughput. However, X O R expects the receiver to reconstruct the lost packet from a particular X O R block. T h i s may not apply to burst errors. Both methods are designed for a small user group because of the use of positive A C K s , and cannot scale to a large user group. Several other schemes are targeted for end-to-end satellite multicast protocols. These studies use the ideas of D R in R M T P to partition the heterogeneous multicast receivers into a number of small homogeneous data groups [24][25][27], and also use different communication protocols across data groups for error recovery. A s stated in [10], even the best end-to-end modifications of T C P cannot ensure good performance over satellite links. A similar conclusion can be reached for multicast protocols. Also, it is suggested that users and servers cannot all be expected to run satellite-optimized versions of satellite multicast protocols. B y splitting the connection to shield high-latency and lossy network segments from the rest of the network, one can focus on the satellite-optimized protocols in order to realize high performance.  Chapter 3 Broadband Satellite Communications The use of GEO satellites for digital communications will increase in coming years. Although the use of fiber optics is presently favored, satellite networks have a number of advantages, such as flexibility and simple broadcast facilities. Broadband satellite communications can provide communication coverage over a very wide area, and interconnections for users at remote areas. Future broadband satellite communication (SATCOM) systems will offer highspeed Internet access and multimedia information services, such as multicasting and interactive video. The implementation of future SATCOM networks can be divided into two fundamental cases: the bent-pipe satellite relay and the "switch-in-the sky" [3] [5] [9].  3.1  Bent-pipe Satellite Relay Conventional Satellite i  Today's communication satellites are basically transparent "bent-pipe" satellites [3]. In a bent-pipe satellite relay, the satellite transponder performs signal amplification and frequency translation. A satellite works in a forward manner by receiving data from the sender and forwarding it to the downlink receiver. Signal detection, decoding, and protocol translation are not performed. The satellite is essentially independent of signal format and transparent to the protocol suite.  27  28  Chapter 3 Broadband Satellite Communications  3.2 Switch-in-the-sky  Rxl  CODING [—| MOD — j | Tx 1 [(  CODING H M O D  )  Rx2  ^  Rxn \-\ dIC r j DEMOD  H CODING  MOD  Tx2  Txn  Figure 3.1 Satellite OBP System [9]  Implementation of a "switch-in-the-sky" requires substantial onboard processing (OBP). Although rare today, the use of OBP, onboard switching (OBS) and onboard routing (OBR) is expected to increase in the future, since they can provide potentially superior performance and more sophisticated networking capabilities than the basic transparent bent-pipe relay. Satellite OBP may be grouped into baseband OBP and OBS/OBR, intermediate/radio frequency (IF/RF) processing, and switching. Baseband OBP is commonly referred to as a fullyprocessed satellite. It is exemplified in the case of the satellite "switch-in-the-sky". IF/RF processing and switching correspond to a partially-processed satellite, which includes signal regeneration and RF switching. The key functions of baseband OBP include demodulation, demultiplexing, error detection and correction. Refer to Figure 3.1. The OBP satellite can demodulate the uplink signals, process the baseband signals, retrieve the routing information, and remodulate and code  Chapter 3 Broadband Satellite Communications  29  the information for the downlink transmission. The switch in Figure 3.1 can represent a packet switch, such as IP or A T M . The goal of O B P is to enhance link performance at the cost of the complexity of the satellites. Both types of satellite systems, as described above, are considered in this thesis in order to satisfy current and future needs of the industry.  3.3 Satellite with O B P  Satellite links between large earth stations are characterized by low bit-error rates ( B E R ) (<1CT ) most of the time. However, retransmission of erroneous frames are very time- consuming 9  if there is no terrestrial feedback channel. One has to take into consideration what error-control strategies are selected. In the near future, the number of small or miniature low-power stations with higher B E R s will quickly grow. Therefore, efficient error control techniques are required to ensure good performance of the satellite link.  Satellite c o m m u n i c a t i o n networks with onboard processing can provide interactive satellite communications with very small earth stations over a large area [36][37][38]. A n O B P satellite system differs from a conventional bent-pipe satellite system, and performs signal amplification and frequency conversion. In an O B P satellite system equipped with multiple highgain spot beams, the satellite performs the demodulation of various uplink carriers to their digital base-band signals, the switching of channels between beams, and the re-modulation of the arranged channels onto downlink carriers. It is thus possible to perform data buffering and A R Q retransmissions in the satellite node. This yields a link-by-link (uplink and downlink) A R Q (or O B P A R Q ) operation scenario, in contrast to a typical end-to-end A R Q operation. In a bent-pipe satellite system, however, only end-to-end A R Q (bent-pipe A R Q ) is possible. For an O B P satellite  Chapter 3 Broadband Satellite Communications  30  system with multiple satellites and inter-satellite links, the O B P A R Q operates over more than two links [38].  O B P separates the losses on the uplink from the losses on the downlink. This allows for early acknowledgment of the lost packets on the uplink, and thus avoids packet corruption faced by all downlink receivers.  The A R Q operation in a satellite system with O B P can be considered as having two separate error-control protocols communicating with each other. OBP.determines whether the information packets received from the ground transmitter can be transmitted to the ground receivers. During this decision process, the O B P performs error checking on each received information packet and responds with an A C K or N A C K to the transmitter. A successfully received data packet is stored in the onboard buffer (awaiting transmission to the ground receivers). It is emptied when an A C K is received from the ground receivers, indicating a successful reception. Both the delay and throughput efficiency can be effected drastically. In the next chapter, the throughput efficiency for this O B P satellite network incorporated with S R A R Q is studied and compared to the bent-pipe scenario.  Satellites with O B P provide additional error-control features. The satellite channel, which has to be regarded as a whole with a B E R p when using conventional satellites, is now subdivided into uplink and downlink; that is, two binary symmetric channels in cascade with B E R p and p , u  d  respectively as follows:  p =  pu + pd-  pupd ~ pu + pd  (3.1)  Chapter 3 Broadband Satellite Communications  31  B y employing separate link protocols on the uplink and downlink, instead of treating the satellite channel as one unit, O B P reduces B E R significantly. O f course, improvement depends on the chosen protocol and on the ratio pjpj.  For A R Q protocols, a satellite system with O B P may  reduce retransmission time by approximately half. A n uplink error is already detected by the satellite processor, and the erroneous frame is called for retransmission immediately. In the case of conventional satellites without their own processing power, an error is only detected by the receiving earth station. Consequently, O B P may improve throughput and shorten the delay of satellite links considerably.  To handle data traffic, it is necessary to have onboard memory on the satellite O B P node. The determination of an adequate size of the onboard buffer involves the m a x i m i z a t i o n of throughput efficiency and the minimization of delay. A satellite with O B P / O B B may work as an intelligent network node. Since intelligence is transferred from earth stations to the satellite, those stations become smaller and cheaper. This is especially true for satellite networks with numerous terrestrial stations. Additional reasons for O B P are efficiency enhancement, frequency reusage (using spot beams), error rate reduction, and response time reduction. [37][38] present analytical results which compare the throughput gain with O B P A R Q and bent-pipe A R Q .  Figure 3.2 shows three satellite A R Q protocols: (1) a conventional bent-pipe satellite with transparent payload, (2) an O B P satellite which checks the received frames and sends N A C K s due to detected erroneous or lost frames, and (3) an O B P satellite with an additional buffer to store frames until they are acknowledged by the receiving earth station.  Erroneous frames on the uplink are detected, and requests for retransmission are initiated by the receiving earth stations or the O B P satellite, respectively. Erroneous frames on the  32  Chapter 3 Broadband Satellite Communications  sender  receivers a  Y buffer  buffer  ( A ) B e n t — p i p e satellite  sender  satellite O B P  buffer  receivers  bu ffer ( B ) Satellite w i t h O B P  sender  satellite O B P  buffer  buffer  receivers  buffer  ( C ) Satellite w i t h O B B data t r a n s m i s s i o n acknowledgements  transmission  Figure 3.2 Broadband Satellite Network Model downlink are retransmitted by the sending earth station or the OBP satellite with a buffer. Frames do not need to be transmitted in the given order on the downlink.  The advantages of OBP, especially with a buffer on board the satellite, are evident, particularly for delays.  Chapter 4 Proposed SRMTPs  PEO  i^.X ' i.Mi  Figure 4.1 Architecture of Broadband Satellite Network  In this chapter, we describe the detailed design of the proposed p r o t o c o l s - S R M T P s . A system architecture that is more realistic than others in similar work is illustrated in Section 4.1. A protocol overview is given in Section 4.2. The header information of the data packet and acknowledgment packet are explained in Section 4.3. The detailed operations of S R M T P s are described in Section 4.4. Window size calculation is presented in Section 4.5.  4.1 System Architecture  Figure 4.1 represents a typical satellite-based broadband network architecture. The Internet server multicasts bulk data to a group of remote users via a G E O satellite. The remote users return feedback information to the satellite (source) through a shared return path. In order to  33  34  Chapter 4 Proposed SRMTPs  Application  Application  RMTP  RMTP SRMTP  IP  IP  PHY  PHY  Sender  Gateway  <  SRMTP >  RMTP  SRMTPRMTP IP  IP  PHY  PHY  PHY  Satellite  Gateway  Receiver  IP  <  >  Figure 4.2 Layered Architecture of Proposed Multicast Protocol address multicast protocol design over the satellite network, the satellite network is considered separately from the rest of the Internet to isolate the high-latency lossy links from other network segments.  4.2 Protocol Overview  Figure 4.2 depicts the layered architecture of the proposed multicast protocol. Gateways are employed to interconnect the satellite network to the terrestrial network and user terminals. On the users' side, the gateways may be integrated with the user terminals, or there may not be any gateway at all. This thesis focuses on the protocol's design over the links between the satellite and the gateways or user terminals. The terrestrial connection can use the existing Internet multicast protocols, such as R M T P .  The main concern in designing a reliable multicast protocol in such a configuration is to reliably multicast bulk data to a group of users, while alleviating acknowledgment-implosion and achieving high scalability.  Chapter 4 Proposed SRMTPs  35  The S R M T P s proposed in this thesis implement a reliable byte stream over the unreliable datagram service provided by IP multicast, and provide sequenced and reliable delivery of bulk data from one sender to a group of receivers via G E O satellite. These new approaches combine sender-initiated and receiver-initiated loss recovery to support absolute reliability. A C K s and N A C K s are combined to form a status message ( S M ) at the receivers' side, which is sent to the source periodically to flush the sender' buffers.  A window-based scheme is used to provide flow control. The satellite channel is isolated from the rest of the Internet. This channel has two unique properties that differentiate it from the rest of the Internet. The first property is that packets sent on the satellite channel cannot be routed out of order. The second property is that congestion is not possible, and therefore, the only reason for packet loss is transmission error. Both properties are attributable to the non-existence of any router on the channel between the uplink station and the gateways. Thus, there is no need to slow down the transmitter by shrinking its window after a packet is lost, as in T C P . Moreover, the sender does not have to probe for the network's capacity. Hence, the sender can proceed using a fixed w i n d o w size, which is optimized to realize a high data rate with respect to the delaybandwidth product of the satellite channel [39].  Using a satellite channel as the return channel increases complexity and decreases performance, as compared with using a lossless terrestrial link with negligible delay. It is necessary to account for the corruption and collision of acknowledgments sent by the receivers to the source via the satellite. The collision of the S M s , sent periodically by receivers, can be avoided by staggering transmissions across suitable repetition intervals. The interval itself should be carefully chosen so that it is long enough to allow all receivers to send their status messages without  36  Chapter 4 Proposed SRMTPs  IP datagram Multicast Segment IP Header  Multicast Header  Data  Figure 4.3 Encapsulation of Multicast Data In an IP Datagram  collision, yet not long enough to cause performance degradations. Lost SMs are recovered by the cumulative effect of subsequent SMs. OBP is employed to separate the uplink and downlink channels. For the forward channel, OBP detects the corrupted packets in advance instead of forwarding them to all the receivers. In the return channel, OBP helps suppress multiple copies of SMs from different receivers by aggregating the feedback packets and forwarding them to the source. OBB provides buffer space for some data packets in case they get lost in the downlink multicasting. OBB thus expedites the recovery of downlink packet losses.  4.3 Header Information  Three kinds of packet formats are used in the system: the forward data packet, the SM packet from users to satellite (or source for without OBP), and the acknowledgment packet from satellite to source. Packets are encapsulated in the IP multicast datagram, as shown in Figure 4.3. The Multicast header (Figure 4.4) includes the source port, the destination port, a sequence number, which is assigned by the source after breaking up the incoming file into fixed-length packets, and the checksum for reliability.  37  Chapter 4 Proposed SRMTPs  0  16  31 Destination port  Source port  Checksum  Sequence Number  Figure 4.4 The Multicast Header  0  8  16  Checksum  Low Buffer Point  No. NACK2  31  Destination Port  Source Port  NACK  24  NACK1  NACK2  NACK3  Figure 4.5 Status Message (SM) Packet Structure  The acknowledgments, issued by receivers, are unicasted to satellite. From receivers to satellite, all users share a common channel. The S M (Figure 4.5) from user to satellite (or source) includes the source port (receivers' side), the destination port (satellite' side/source' side), the low buffer point (which is the highest in-order packet received correctly so far, the N A C K No. (which refers to how many lost packets are N A C K e d in the SM), and a sequence of lost packet sequence numbers. Users send SMs in turn, using round robin T D M A . These are repeated periodically. To guarantee absolutely reliable transmission, the source must keep a trace on the information from all the receivers. Since the window scheme needs this information to advance the window in a  Chapter 4 Proposed SRMTPs  38  timely manner, every user must have a chance to submit its own status message. The simplest way to avoid contention in a commonly shared channel is to use a round robin method. Packet corruption may be another reason for information loss. A l t h o u g h it is almost negligible for short messages, packet corruption can still cause some trouble in scenarios involving the transfer of a big file to a large user group. The main point here is to ensure that the S M s are as short as possible.  Bitmap is a common method used by some Internet multicast protocols, such as R M T P and M F T P , for acknowledgments. In R M T P , receivers use a bit vector of N bits (size of the receiving window) to record the existence of correctly-received packets stored in the buffer. Each bit corresponds to one packet slot in the receiving buffer. W h i l e bitmap is very efficient in combining A C K s and N A C K s together in one acknowledgment on the Internet, it causes some specific problems over a satellite link. First, the bitmap must be long enough to cover the buffer. In a fat satellite channel where a large window may exist, the bitmap should be relatively longer than the bitmap used on the Internet. Longer packets face a higher packet loss rate, and bring higher collision. A l s o , in the scenario presented in this thesis, where no congestion exists in the forward link, the loss rate is quite low for a single user. For a packet with 1500 bytes, while B E R is 10" , the packet loss rate is around 1.19%, which means only one packet in a hundred may be 6  lost. U s i n g a bitmap brings high redundancy because the information consumes too much bandwidth. Instead of using a bitmap to indicate the status of the receiving window, a low buffer point ( L P ) is used to simplify the information. F o r transmitting bulk data, where the order of packets must be guaranteed, the low buffer point ( L P ) means all the packets beyond that point have been received correctly. For example, an L P of 100 means all the packets before 100, including 100, are received correctly. In that way, the status message is greatly simplified. The N A C K  39  Chapter 4 Proposed SRMTPs  0  16  Source Port Low Buffer Point  31  Destination Port NACK  Checksum  Figure 4.6 Satellite to Source Acknowledgment Packet Structure field is flexible. If there is no lost packet in the current buffer, the NACK No. is set to 0, and the NACKed packet sequence numbers are not sent. If there are several lost packets in the current buffer, the actual number of lost packets in the buffer is set in the NACK No., and the sequence number of the lost packets is set in N A C K 1 ~ NACKn accordingly. The maximum Nacked packet numbers in the SM should be chosen carefully according to the system configuration so that all receivers are able to submit the SM without collision, while sending as many NACKed packets as possible. The satellite can aggregate all the SMs from the receivers. If an acknowledgment is corrupted, OBP simply discards the packets; otherwise OBP updates the information from the SM which is sent by the users. OBP keeps an LP record for all users. If the LP for all users is advanced, OBP sends a positive ACK to the source. As described in Figure 4.6, this acknowledgment includes an LP, which refers to the highest packet correctly received in order, and the NACK field is set to -1, if no NACKed packet needs to be reported. As a result of the cumulative characters of the LP, later ACKs or NACKs can recover former ACKs. If a NACK from the receiver is received by OBP, OBP first aggregates the NACK to see if the NACK for the same packet has been received within a certain time boundary. If so, OBP ignores the NACK,  Chapter 4 Proposed SRMTPs  40  otherwise, S R M T P _ O B P sends the N A C K to the source. In S R M T P _ O B B , O B P searches the O B B to see i f the lost packet has been saved there. If so, O B P remulticasts the data to the receivers. However, i f the packet is not in O B B , satellite O B P issues a N A C K to the source asking for retransmission of the lost packet.  4.4 Protocol Description  We d e v e l o p e d three w i n d o w - b a s e d S R M T P s c h e m e s , n a m e d  SRMTP_NOB,  S R M T P _ O B P and S R M T P _ O B B . S R M T P _ N O B uses a bent-pipe satellite channel, whereas S R M T P _ O B P employs O B P , and S R M T P _ O B B adds onboard buffers to the S R M T P _ O B P scheme.  In the S R M T P operation, the sender accepts an incoming file, breaks it up into fixed-size packets (except for the last packet), assigns each data packet a sequence number, and sends the packets until the sender's window is full. Then it stops and waits for acknowledgments. The corrupted acknowledgments are simply discarded. The sender retransmits the lost packets after a N A C K is received. When a data packet has been A C K e d by all receivers, it is deleted from the sender's buffer, thus making room for the sender to send new packets. Figure 4.7 presents the flowchart of the sender in S R M T P .  The main differences between the three S R M T P schemes are in the satellite operation. In S R M T P _ N O B (Figure 4.8), the satellite multicasts the packets it receives from the source to receivers without error detection. If the packet is corrupted in the uplink, all the downlink receivers encounter packet corruption. A s with the return channel, the corrupted S M is also forwarded to the source without any processing. Figure 4.9 shows the flowchart of the satellite operation in  Chapter 4 Proposed SRMTPs  Init  Wait Incoming data  ACK/NACK arrives  Divide to packets  Figure 4.7 Flowchart of SRMTP Sender's Operation  Init  „  wait  «  Packet a r r i v e s — L ^ ^ S M  arrivers  Multicast  Forward to  packet  source  Z Z 1  Figure 4.8 Flowchart of SRMTP_NOB Satellite's Operation SRMTP_NOB.  42  Chapter 4 Proposed SRMTPs  Init  Wait  Packet arrives  SM arrives Yes  Discard Cancel timer  ^"^^  Retransmission?  Aggregate SM  TNO Multicast packet  Discard packet  Send NACK to Source  Set timer  Figure 4.9 Flowchart of SRMTP_OBP Satellite's Operation In SRMTP_OBP (Figure 4.9), the satellite performs error detection on each packet upon receiving it from the source. If the packet is correct, the satellite multicasts the packet to all the receivers. Once a lost packet is detected, the satellite OBP sends a NACK to the source and starts a timer that is cancelled when the requested retransmission is received. When the timer expires, the OBP sends another NACK to the source and restarts the timer. Corrupted SMs from the receivers are simply discarded by the OBP. Correctly received SMs are aggregated by the OBP. If a packet is correctly received by all the receivers, the OBP sends a positive ACK to the source and clears its buffer. This positive ACK contains a low buffer point, which means the highest packet  43  Chapter 4 Proposed SRMTPs  Init  Wait Packet arrives  SI .'! a r r i v e s 1  Yes a: e e l tamer  •w  Discard  S t o r e pic in buffer  Send A C K Source  to  Dis card packet  Send M A C K Source  to  Set t i m e r  Figure 4.10 Flowchart of SRMTP_0BB Satellite's Operation received in order by the receivers. Lost ACKs from satellite to sender can be recovered by later ACKs. If a packet is lost/corrupted, as indicated in the SM, the OBP sends the NACK to the source to request retransmission of the packet. Further NACKs for the same packet received by the OBP over an appropriate time interval are treated as redundant, and thus suppressed. In SRMTP_OBB (Figure 4.10), onboard buffers are added on the OBP. Except for the same functions as the SRMTP_OBP, the satellite saves the correctly received packet from the source in the OBB if the buffer is not full. While an effective NACK is received after aggregating the SM, OBP searches the OBB and retransmits the lost packet if it is in the buffer. If the packet is  44  Chapter 4 Proposed SRMTPs  Init  Figure 4.11 Flowchart of S R M T P Receiver's Operation not in the buffer, O B P sends the N A C K to the source asking for the retransmission of the packet.  The receivers (Figure 4.11) take the responsibility of reordering the correctly-received packets. Once a packet is received correctly, i f it is in order, it is sent to the upper layer. Otherwise, it is put in the buffer. The corrupted packet is discarded upon receiving leaving the hole in the receiving buffer. Each receiver periodically sends an S M to the OBP/source. At timeout, the receiver inspects the receiving buffer to find the lowest in order packet that has been received so far, together with the holes in the receiving buffer which indicate the missing of packets. SMtransmissions from different receivers are staggered over the SM-repetition intervals.  45  Chapter 4 Proposed SRMTPs  4.5 Window Size  The satellite channel is often called "a fat channel" for its large round trip time (RTT) and high bandwidth-delay product, obtained by multiplying the bandwidth (in bits/sec) by the R T T (in second). The bandwidth-delay product is the number of bits in transit from the sender to the receiver before an acknowledgment of the first bit can be received.  For a bandwidth-delay product of 10 Mb/s * 0.54 sec = 5.4 M b in the simulation configuration, the sender has to transmit a burst of 5.4 Mbits, in order to keep going full speed until the first acknowledgment comes back. It takes this many bits to fill the pipe. To achieve good performance, the sender and receiver's windows must be at least as large as the bandwidth-delay product, although preferably somewhat larger, since the sender and receiver need some time to process the packets. Theoretically, window size can be calculated using the following equation (4.1), for an error-free channel:  W=  (RTT  + Tsm + Tx) x Bandwidth  The periodic S M interval is defined as T , sm  (4.1)  w h i c h is linear to the number of users.  Transmission time includes both the processing and queuing times in the sender, satellite, and receivers, and is defined as T . Figure 4.12 describes the relationship of these parameters. x  Chapter 4 Proposed SRMTPs  Figure 4.12 Parameters Related to Window-Size Calculation  46  Chapter 5 Design of Simulation Models and Discussions of Simulation Results In the previous chapter, design details of S R M T P s are presented. In order to evaluate the performance of S R M T P and compare it w i t h the e x i s t i n g M F T P , s i m u l a t i o n models are constructed using O P N E T . Performances are evaluated using the O P N E T analysis configuration. O P N E T is a vast software package with an extensive set of features designed to support general network modeling and to provide specific support for particular types of network simulation projects. O P N E T provides a comprehensive development environment that supports the modeling of communication networks and distribution systems. Both the behavior and performance of modeled systems can be analyzed by performing discrete event simulations. The O P N E T environment incorporates tools for all the phases of a study, including model design, simulation, data collection, and data analysis.  5.1 Design of Simulation Models  The simulation models of this thesis are developed based on the satellite system architecture presented in Chapter 4. Figure 5.1 presents the network model of a satellite system. The source and satellite are modeled as queueing models. Each has two F I F O queues for original packets and retransmission packets. The retransmission queue has a higher priority than the original. For investigating the satellite transport protocol performance, it is usually sufficient to experiment with delay and error simulators, rather than with detailed emulators of the transmission channel [10]. In our model we consider G E O satellite links with a 540 ms R T T between earth  47  48  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  t q 3  k—•  ^  Receiver  Receiver  Figure 5.1 Network Model  stations, a 10 M b / s data rate for the forward link from the sender to receivers, and a data rate of 1 Mb/s on the return link shared by all receivers. Uplink and downlink satellite links are assumed to have a fixed B E R ranging from 10" ~ 10" , while part of the forward downlink may face some 6  9  degree of degradation. The loss of packets on the forward uplink affects all the receivers, while the loss of packets on the forward downlink affects individual receivers independently. The network traffic is assumed to be large file transfers. A l l users share a return link to unicast acknowledgments to the satellite. Contention exists in the shared link; thus, for continued traffic in a return channel, round-robin is chosen to avoid traffic collision. A dedicated satellite channel is used for multicasting, thus the possibility of congestion is ignored.  The system forward delay includes the following: queueing delay in the source {t j), q  satellite (t ) and receiver {t )\ data processing delay in the source, satellite, and receiver (/2  q3  separately; and propagation delay (t ) from the source to satellite and from satellite to receiver pl  (t 2)- The system backward delay includes only the propagation delay from receiver to satellite, p  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  49  and from satellite to sender. Here, transmission delay is ignored since the acknowledgment packet is very short.  5.2 System Configuration  For the simulation test, the following parameter values are used: Table 5.1  Simulation Parameters for S R M T P Models  Simulation Parameters Multicast file  5 Mbytes  Bandwidth of the forward channel  lOMbit/s  Bandwidth of the return channel  1 Mbit/s  Round trip time  540 ms  Window size  1.2 Mbytes  Satellite buffer size (OBB)  1.2 Mbytes  Uplink BER  10" - IO"  Downlink BER  10" -10"  Number of users  1 ~ 1000  SM interval  300 ms  Packet size  1500 bytes  Maximum no. of NACKs in a SM  16  6  6  9  9  The S R M T P schemes are evaluated by multicasting a 5 M b y t e file to a number of users ranging from 1 to 1000. The window size of the source and the receivers is 1.2 Mbytes in order to realize the highest throughput. The packet size is chosen as 1500 bytes. The size of the O B B for S R M T P _ O B B is the same as the window size. The S M interval is chosen as 0.3 seconds to allow the m a x i m u m user group to send S M s in turn, without c o l l i s i o n . This interval can be less for smaller user groups, as long as each user has time to send an S M . However, for simplicity, a fixed  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  50  interval is used regardless of the size of the user group. The maximum number of N A C K s in an S M is set to 16. This number is sufficient to represent all the lost packets in a window for the considered link condition.  System performance is evaluated in terms of system throughput and network delay. Network delay is defined as the total time the system needs to reliably multicast a file to all the users in the group. Throughput is defined for the entire system as follows:  SystemThroughput  = NumberofUsers  X FileSize/NetworkDelay  (5.1)  For each simulation, fifty simulation runs are conducted with the same simulation parameters, but with different random seeds. The average of the results from all runs in each simulation is then presented.  5.3 Impact of Link Condition  This section presents the effects of packet loss due to transmission errors over the satellite links. Satellite links are usually designed with a low clear sky B E R . However, the B E R may increase substantially during heavy precipitation. A s s u m i n g independent occurrences of bit errors, the packet error rate ( P E R ) can be calculated from B E R as follows:  (5.2)  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  5J  Table 5.2 shows the packet error rate for various B E R values. Table 5.2Packet Error Rate with Different B E R  BER  lO"  PER  1.2*10"  10  9  lO"  1.2* 10"  4  5  10"  lO"  1.13*10"'  6.98*10"'  10"  7  -8  5  6  1.2*10"  3  1.19*10"  2  4  To determine the effects of the channel B E R in the satellite links on S R M T P s performance, the packet corruption ratio ( P C R ) is analyzed as the channel B E R increases, and is compared with the simulation results. P C R is defined by Equation 5.3, which divides the total number of corrupted packets in the transmission by the total packets sent by the sender. Equation 5.3 is presented as follows:  PCR - ~LCorruptedPackets/TotalPackets  (5.3)  A pseudo-code description of the P C R analysis is given in Figure 5.2.  PER= 1 -(1 -  BER) '" '' '; p  kl  Siu  corruptPackets = TotalPackets * PER; while ( corruptPackets > 1 )  I corruptSum = corruptSum + corruptPackets; corruptPackets = corruptPackets * PER;  1  PCR = corruptSum / TotalPackets;  Figure 5.2 Pseudo-Code of P C R Analysis  The P C R considers overall packet loss rates in the multicasting process. Compared to P E R , which is the indicator of the packet loss rate in one transmission, P C R cumulates the loss possibility in multiple transmissions until the packet is finally correctly received. Hence, P C R is  52  Chapter 5 Design of Simulation Models and. Discussions of Simulation Results  Channel B E R  Figure 5.3 Channel B E R vs. Packet Corruption Ratio, with O B P and without O B P slightly higher than P E R .  Simulations with and without O B P are performed with different link B E R s . Simulation and analytical results are compared in Figure 5.3. P C R increases lineally as the channel condition deteriorates. Results in Figure 5.3 show that with and without O B P , analytical results calculated by Equation 5.3 are close to the simulation results. While channel B E R is less than 10~ , the P C R 7  is very small, less than 0.1% in both cases. While the B E R is IO" , the P C R jumps to around 1%. 6  It is clearly evident that as the channel condition worsens, the P C R increases substantially, and thus, system performance degrades correspondingly.  Throughput and delay are measured as a function of B E R for all three S R M T P s . Figure 5.4 displays the overall network delay experienced by multicasting to 500 users under different channel conditions. A s expected, as link conditions deteriorate, delay increases, especially when  53  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  40  35  30  cT  <D <fi ^25  a> Q  | 20 z  15  10  i fo"  10"  9  10" Link BER  8  7  10"  6  10"  5  Figure 5.4 Effect of B E R on System Delay for Bent-pipe, with and O B B B E R increases beyond 10" . The delay increase is not that significant as B E R increases from 1(T 6  9  to IO" in the case of S R M T P _ N O B . However, as B E R increases from 10" to 10~ , the delay 6  6  5  increases from 12.7 seconds to 39.91 seconds, which is 2.14 times the increase.  The impact of channel conditions on system performance is presented more clearly in the plotting of the system throughput against channel B E R (Figure 5.5). The graph corresponds to the delay summaries in Figure 5.4. A s seen in Figure 5.5, for S R M T P _ O B B , while the B E R increases over a decade from 10  to 10 , the throughput decreases by 11.4%. H o w e v e r , as the B E R  increases over a decade from 10" to 10" , the throughput decreases by approximately 42.21%. 6  5  The conclusion to be drawn here is that S R M T P s work well while link conditions are relatively good. Fortunately, most of the time, the satellite link is expected to perform well, better than 10~ . 7  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  54  Figure 5.5 Effect of B E R on System Throughput for Bent-pipe, with O B P and O B B  5.4 Effect of Protocol Architecture  This section is devoted to the results and discussion of the effect of protocol architecture on performance. F i g u r e s 5.4 and 5.5 compare p r o t o c o l performance under v a r y i n g l i n k conditions. While the B E R is equal to or lower than 1(T , bent-pipe and O B P have approximately 8  the same performance. A s the B E R increases on the link, P C R increases, as demonstrated in Figure 5.3. The loss of packets increases, especially for downlink users. With onboard buffering, lost packets can be retransmitted from the satellite instead of from the source, greatly reducing transmission time. For a 10 Mbit/s bandwidth link, over a 10~ satellite link, using S R M T P _ O B B 6  results in a delay of approximately 9.37 seconds, whereas using S R M T P _ N O B results in a roughly 12.7 second delay. The delay becomes noticeably worse for S R M T P _ N O B as the B E R increases past 10" . B y 10" , the delay for S R M T P _ N O B is nearly 39.9 seconds, while the delay 6  5  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  55  of SRMTP_OBB is only 16.23 seconds. With OBP, system delay can be decreased by 37% over a bent-pipe satellite. OBB can decrease delay by a further 35%, as compared to OBP. The throughput of SRMTP_NOB is approximately 98.4% of SRMTP_OBP, versus 78.77% of SRMTP_OBB at a low BER of 1(T . SRMTP_NOB is down to 62.64 Mbytes/sec, 8  while SRMTP_OBB is still at 154.1 Mbytes/sec at the high BER of 1CT . It is clear that OBP 5  greatly improves system performance under poor channel conditions. OBB can improve perfor-7  mance further. Under good channel conditions, where the uplink BER is less than 10" , OBP does not have a significant advantage over bent-pipe satellite, while OBB still shows a 19% decrease in the transmission time. -7  Although the PCR seems much lower while the BER is less than 10 , which it is in most of the cases in satellite networks (Figure 5.3), it still has a significant influence in multicast applications where a large group of receivers exist. Figure 5.6 shows how many of the receivers may encounter packet loss, for a single packet multicasted to an increasing number of receivers, while the link BER is 10" . 7  From Figure 5.6, it is clear that without OBP, if the number of receivers exceeds 400, more than one user is likely to receive a corrupted copy of the same packet. As the group of users increases to 1000, three of them may receive a corrupted copy of the same packet. While more than one receiver loses the same packet, retransmission by multicasting is very efficient, since sending one retransmission recovers all losses for receivers at the same time. With OBP, the number of corrupted packet copies greatly decreases, as compared to being without OBP with the same user group. For a packet multicasting to 800 receivers, one of the users may encounter a  56  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  2.5  * v -e-*-  Without OBP (analytical) With OBP (analytical) Without OBP (measured) With OBP (measured)  i  1.225  1.22  V  1000 0' 0  100  200  300  400 500 600 Number of Users  700  800  900  1000  Figure 5.6 Number of Corrupted Copies of a Multicast Packet, L i n k B E R = 1 0 packet loss while using O B P , whereas two of the receivers may encounter a packet loss without O B P . It is clear that O B P reduces the number of corrupted packet copies dramatically. In fact, O B P can reduce packet error by close to half the rate without O B P . This is because O B P hides the uplink losses from end receivers by not forwarding the corrupted uplink packets to them. Figure 5.7 shows the result of B E R being 10~ . There are more corrupted packets here than compared to a 6  B E R of 10" . This time, while the number of users is greater than approximately 50 for without 7  O B P , and approximately 100 for with O B P , more than one receiver may have lost the packet. As the user group increases, more receivers may encounter packet loss for the same packet. While more than one user loses the packet, retransmitting one packet may recover the packet loss for a number of receivers. The efficiency improves with the number of receivers.  A s the link condition worsens at 10 , the difference between with O B P and without O B P  57  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  x • •v -e-*-  Without O B P (analytical) With O B P (analytical) Without O B P (measured) With O B P (measured)  20  0  100  200  300  i t 400 500 600 Number of Users  i 700  800  900  1000  Figure 5.7 Number of Corrupted Copies of a Multicast Packet, L i n k B E R = 1 0 becomes more dramatic. A s seen in Figure 5.7, for a thousand receivers, the number of corrupted packet copies reaches 24.7 for without O B P , whereas the number of corrupted packet copies is 12.27 for with O B P . In such a case, for every single packet, there are nearly 25 receivers that lose the same packet among a thousand receivers without onboard processing, and nearly 13 receivers that lose the same packet among a thousand receivers with onboard processing.  O B P separates the system into an uplink part and a downlink part. With the employment of OBP, a different error recovery scheme can be used to improve system performance. With O B P , uplink channel errors can be detected in advance. However, O B P cannot be used to alleviate any downlink errors. One method proposed involves the use of onboard buffering. With satellite O B B , packets from the sender which are received correctly by satellite are kept on the satellite buffers. If a buffered packet is lost in the downlink channel, satellite O B P can retransmit the packet rather than asking the source for retransmission. Therefore, the retransmitting delay can be reduced by  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  58  half of that without O B B . It is easy to conclude that multicasting to a large group of users may produce more benefits than when compared to a small group, because retransmitting a lost packet can benefit all receivers who encounter loss at the same time.  5.5 Effect of SRMTP Parameters  In the last section, the impact of satellite channel conditions and protocol architecture on system performance is analyzed. In this section, the effects of some key S R M T P parameters are analyzed.  5.5.1 Effect of Window Size on the System Performance  Measuring varying window size provides information about the behavior of applications running under tested scenarios. It is established that window size can affect system performance. As discussed in the previous chapter, window size can be calculated by Equation 4.1 for an errorfree channel. Theoretically, window size is established at 1 M b y t e in the system configuration. Figure 5.8 shows the impact of the window size on the perceived network delay of S R M T P _ N O B , while the channel condition varies from 1CT ~ 10~ . Changes in w i n d o w size have a strong 6  9  influence on network delay. This change indicates a situation where large window sizes provide better channel utilization on high delay links as more data can be sent without having to wait for the arrival of acknowledgments, thus resulting in a continuous segment flow. For high transmission rates with large windows, the host becomes more and more utilized. Simulation results reveal that w i n d o w size s h o u l d be no less than 1.2 M b y t e s i n an error prone channel. The delay decreases as the window size increases, until it reaches 1.2 Mbytes for all conditions. Since our  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  59  120  0.6 0.8 1 Window Size (Mbytes)  Figure 5.8 Effect of Window Size on System Throughput for SRMTP_NOB main goal is to reach the highest throughput for a group of users, all of the parameters used in the simulations are set to values that maximize throughput. As depicted in Figure 5.8, the optimal choice, with delay considerations, is a window size of 1.2 Mbytes.  5.5.2 Effect of Buffer Size on the System Performance for SRMTP_OBB  Next, the satellite onboard buffer size is analyzed for SRMTP_OBB as to how it may affect system performance. Figure 5.9 presents the simulation results from the multicast of a 5 Mbyte file to 500 users under varied channel conditions. The OBB size has a significant effect on throughput in the SRMTP_OBB scenario. As the buffer size increases, system throughput increases gradually, since lost packets can be recovered from the satellite instead of from the source. Whereas the onboard buffer is equal to or greater than the window size, all downlink lost packets can be retransmitted by satellite, resulting in the shortest delay. Thus, there is no useful  60  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  600  Link BER: 1E--9 -e- Link BER: 1E--8 - * - Link BER: 1E--7 - i - Link BER: 1E--6  I  0  0  —  I  —  ,  —  0.2  I  —  I  —  0.4  I  —  ,  —  I  —  I  —  I  —  I  —  ,  —  ,  —  0.6 0.8 1 1.2 Satellite OBB Buffer Size (Mbytes)  I  —  I  —  1.4  I  —  1.6  Figure 5.9 Effect of Buffer Size on System Throughput for S R M T P _ O B B purpose for a buffer that is larger than the window size.  5.5.3 Effect of File Size on System Throughput  T h i s s e c t i o n presents the effects o f the f i l e s i z e on the s y s t e m throughput for S R M T P _ N O B under different channel conditions. Figure 5.10 shows the dependence of system throughput on the size of the file, multicasted to 500 users in S R M T P _ N O B . The window size is set to 1.2 Mbytes, according to previous discussions. While the file is less than a full window, the entire transfer can be accomplished in a single window. From Figure 5.10, it is clear that throughput starts out as much lower when the file is relatively small. This is to be expected because a smaller amount of data is initially in transit, and propagation delay is much larger than the transmission time, resulting in low channel utilization. A s the file size increases, the throughput is  61  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  500 450  £ .o  350  2  -  300  E a)  200  "  150 100 50 0 0  1  2  3  4  5  File (Mbytes)  6  7  8  Figure 5.10 Effect of File Size on System Throughput for S R M T P _ N O B increased under all channel conditions until the file reaches 1.2 Mbytes, which is also the window size. Since the file is greater than 1.2 Mbytes, the throughputs decrease for a certain amount, then start to grow again. For larger files, the throughput improvement is negligible. This is because for a fat satellite channel with large R T T , where the file size is less than the window size, the channel cannot be used efficiently. Only part of the transmission pipe is filled at any instant in time. When the multicasted file is equal to the window size, the throughput reaches a peak. When the file is a little bit greater than the window size, the file must be sent in more than one full window. Since the sender must wait until it receives some positive acknowledgments to send new packets, the transmission time increases, as compared to not having to wait for the acknowledgments. A s the file increases further, throughput increases again. After the file size is greater than two to three windows, the influence of the file size is not very significant. The throughput of a 5 Mbyte file transfer is 413.99 Mbytes/s, namely 94% of a 8 M b y t e file for a link B E R of 10" , while the 9  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  62  9.5 9 8.5 8 O  7  c  >.  ra Q  ' 6.5 6 5.5 <  5 4.5^ 0  100  200  300  400  500  600  700  800  900  1000  Number of Receivers  Figure 5.11 Network Delay of S R M T P s under Link B E R of IO"  7  throughput of a 5 Mbyte file transfer is 197.89 Mbytes/s, which is 96% of a 8 Mbyte file for a link of 10" . In conclusion, to achieve good performance, the file size should be at least twice as large 6  as the window size to eliminate the effect on system performance. In our simulations, we choose to multicast a 5 Mbyte file to get the maximum throughput.  5.6 Performance Comparison of SRMTP  The advantages of O B P and O B B have been discussed in the previous chapters, whereas the following experiments evaluate the performance of each scheme in S R M T P s .  Figure 5.11 shows the overall network delay of sending a 5 Mbyte file to a varying number -7  of receivers for the proposed protocols in a satellite link with a B E R of 10  . A s the number of  receivers increases, the delay increases. This is evident because as the receivers increase, more  63  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  ;l  0  I  I  I  1  I  I  I  I  I  100  200  300  400  500  600  700  800  900  =J 1000  N u m b e r of R e c e v i e r s  Figure 5.12 Network Delay of S R M T P s under L i n k B E R of 10"  6  packets may be lost, creating more demand in packet retransmission. However, delays do not increase lineally as the user numbers increase. This is clearer in Figure 5.12,where the link B E R is 1(T . While the link B E R is 10" , for S R M T P _ O B B , only when there are more than 800 receivers 6  7  in a group does one of the users receive a corrupted packet for every packet. In other words, there is only one or no users who receive the corrupted packet for a single packet, as discussed in Figure 5.6. Thus, the delay increases as the receivers increase, in most cases. However, as the link B E R decreases to 10" , for O B B , more than one receiver loses the same packet when more than a 6  hundred receivers are in a group. When the end receiver group is greater than a hundred, retransmitting one lost packet may benefit all the users that lose the same packet. In such a case, delay increases slowly after the receivers exceed a certain number. Figure 5.13 displays the overall throughput experienced when multicasting a 5 Mbytes file using S R M T P s . The graph corresponds to the network delay summaries in Figure 5.11. Figure 5.13 shows that throughput improves as  64  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  700  600  | 500 If}  - * - SRMTP-OBB - e - SRMTP-OBP - t - SRMTP-NOB  Link [3ER: 1E-7  1.400 "5  Q.  SZ  I 300  sz r-  E CD  £200  100 200  400 600 Number of Users  800  1000  Figure 5.13 System Throughput of S R M T P s with no Degradation the number of users increases. It can be seen that the protocol scales very well. A s the receivers increase, retransmitting a lost packet may recover all the downlink receivers who have encountered the same packet loss.  It is clear that for all user groups S R M T P _ O B B has a higher throughput than the other two cases. S R M T P _ O B P has better performance than S R M T P _ N O B . A l s o , it is clear that as the number of users grows, the throughput grows almost lineally. The results clearly show that the multicast protocol is superior to unicast, as delay does not increase linearly with the number of users. Furthermore, O B P is better than bent-pipe satellites because it can independently recover uplink losses. O B B is even better than O B P because it expedites the recovery of downlink losses.  Although for most of the time satellite link conditions are very g ood, there are still some times where links may deteriorate, for example during heavy precipitation. For an application  65  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  Table 5.3Number of Receivers which Face L i n k Deterioration for Different User Groups Under Certain Degraded Ratios ""•^JJser group  1  50  100  200  300  400  500  600  700  800  900  1000  0.01  0  0  1  2  3  4  5  6  7  8  9  10  0.05  0  3  5  10  15  20  25  30  35  40  45  50  0.1  0  5  10  20  30  40  50  60  70  80  90  100  0.2  0  10  20  40  60  80  100  120  140  160  180  200  ratio  such as multicast, where many receivers scattered across a large area are involved, having some of the receivers face link degradation is very reasonable. Next, more scenarios are analyzed where some of the users face channel degradation.  In the first scenario analyzed here a certain ratio of receivers encounter a higher link B E R of 10" , whereas the rest of the receivers' link B E R , as well as the uplink B E R , is still 10" . 6  7  Table 5.3 presents a detailed number of users who face link degradation, while the degradation ratio is either 0.01, 0.05, 0.1 or 0.2.  Figure 5.14 plots how the system preforms for S R M T P _ O B B while part of the links have a higher B E R than others. It is clear that as the degraded ratio increases, the system performance worsens. When the degraded ratio is 0.01 for a thousand users, ten of them have channel degradation. Though performance is reduced a little bit, this is still very close to being without degradation. W h i l e the degraded ratio is 0.2, which means 1/5 of the users face channel deterioration, performance is the worst. A s the degraded ratio increases from 0.01 to 0.2, the number of users who encounter link degradation increases by about 20 times. However, the performance degradation is much less compared to the link degradation. For a thousand users, the system throughput is reduced by 15.75%, while the degraded ratio increases from 0.01 to 0.2. We reach the conclusion  66  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  700  0  200  400  600  800  1000  Number of Users  Figure 5.14 System Throughput Versus Receivers with L i n k Degradation of 10 SRMTP_OBB  for  that multicast is a power method for transmitting, even while some of the channel conditions encounter channel degradation.  Figure 5.15 presents similar results for S R M T P _ O B P in the same simulation conditions. A s the degraded ratio increases, the users who meet the channel decadence increases, and the system performance decreases.  Last, S R M T P _ N O B for the same parameters is simulated, and the results are shown in Figure 5.16. A g a i n , the performance is very similar to the above two scenarios, except that the overall performance is lower.  The second scenario analyzed here is a higher link degraded B E R of 10" , where the 5  degraded ratios of the receivers are the same as before.  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  600  0  100  200  300  400  500  600  700  800  900  1000  Number of Users  Figure 5.15 System Throughput Versus Receivers with Link Degradation of 10 for SRMTP_OBP  600  0  100  200  300  400  500  600  700  800  900  1000  Number of Users  Figure 5.16 System Throughput Versus Receivers with Degraded Link BER of 10" , for SRMTP_NOB 6  68  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  700  600  —i— -e-*— -v-  Degraded Ratio: 0 Degraded Ratio: 0.01 Degraded Ratio: 0.05 Degraded Ratio: 0.1 Degraded Ratio: 0.2  500 Degraded BER: 1 E - 5  a. 400  300  200  100  100  200  300  400  500  600  700  800  900  1000  Number of Users  Figure 5.17 System Throughput Versus Receivers with Degraded L i n k B E R of 10 , for SRMTP_OBB Figures 5.17, 5.18 and 5.19 show the throughput versus the number of receivers with varying degraded ratios in the satellite downlink. A l s o , as the number of receivers increases, the throughput increases. However, the throughput decreases substantially once a degraded user exists. In Figure 5.17, S R M T P _ O B B is presented again for a degraded B E R of 10" , and the 5  degraded ratios are 0.01, 0.05, 0.1 and 0.2, separately. In a case where the degraded ratio is 0.01, when the user group is 100, only one receiver encounters channel downgrading. The throughput decreases by about 58.4%, as compared to without degradation. A s the user number increases to a thousand for the same degraded ratio, ten of the receivers are confronted with channel degradation. The decrease of the system throughput is reduced to 38.2%. It is clear that as the user number increases, and hence, the degraded receivers increase, performance reduction is relieved. W h i l e the degraded ratio continues to increase,  69  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  600  Number of Users  Figure 5.18 System Throughput Versus Receivers with Degraded Link BER of 10" , for 5  SRMTP_OBP the performance degradation is relatively smaller than compared to being without any degradation to having a very small amount of degradation. For a thousand users, as the degraded ratio increases from 0 to 0.01, the performance decreases by 38.24%. While the ratio increases from 0.01 to 0.05, throughput decreases 14.5%. Increasing the degraded ratio from 0.05 to 0.1 leads to a 4.22% decrease in system throughput. The throughput decreases by only 4.06% as the result of the further increase of the degraded ratio from 0.1 to 0.2. Similar results can be achieved from SRMTP_OBP and SRMTP_NOB in the same system configuration. For SRMTP_OBP, while the degraded ratio is 0.01 for a thousand users, performance decreases by 43.94%. For SRMTP_NOB, while the degraded ratio is 0.01 for a thousand users, the performance decreases by 46.02%.  It is evident that as the degraded ratio increases, the system performance continues to  70  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  600  0  100  200  300  400 500 600 Number of Users  700  800  900  1000  Figure 5.19 System Throughput Versus Receivers with Degraded Link B E R of 10  , for  SRMTP_NOB decrease, however, not as much as before. The results demonstrate once again that multicast is an effective method. S R M T P s work well even while some of the users face channel fading.  5.7 Performance Comparison Between MFTP and SRMTP  So far, we analyzed all the proposed protocols and evaluated their performances in different situations. The following experiments compare the performance of the existing protocol with SRMTPs.  A s discussed in Chapter 2, even though there are a few satellite reliable multicast protocols [22][23][24], most of them simply assume an error free return channel and ignore the impact of the return channel transmission delay. Furthermore, these schemes are targeted to small user groups. M F T P is the only satellite reliable multicast protocol that targets a large user group  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  71  and uses satellite channel for feedback information [26]. Thus, M F T P is chosen for comparison with the proposed S R M T P s .  M F T P breaks the data to be sent into "blocks." If the data is received correctly in a block, nothing is sent back to the sender. If one or more packets are in error or missing in a block, the receiver responds with a N A C K , which consists of a bitmap of the block. The file is sent initially in its entirety in the first pass. The repairs are sent in the second pass. This is repeated until all the repairs are received by all the receivers. M F T P is designed for a very reliable channel where the B E R is better than 10~ [30], resulting in 70% of the receivers receiving the file error-free in the 10  first pass. M F T P works well under very good link conditions.  M F T P is evaluated under the same system configuration, except that the return channel has the same bandwidth as the forward channel, which is ten times more than the proposed protocols demand. This is because M F T P uses a random delay to submit N A C K s . The collision of the return channel is too high i f the return bandwidth is assigned to be the same as our system configuration. It is almost impossible to submit the N A C K s to the source for a large user group while the link B E R is 10" , which is the nominal B E R for the simulation. In order to decrease the 7  collision which occurs in the returning channel, M F T P usually assigns return channel 1/4 of the forward bandwidth for every 200 receivers. M F T P definitely consumes more bandwidth from the returning channel than S R M T P s .  F i g u r e 5.20 compares the network delay o f M F T P and the proposed protocols for multicasting a 5 M b y t e file to 500 users under varying link conditions. A t the low B E R , the performances of all protocols are almost the same. A s channel conditions deteriorate, the differ-  72  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  Link BER  Figure 5.20 Effect of B E R on Network Delay for M F T P and S R M T P s ences between M F T P and the proposed protocols become more significant. Generally speaking, S R M T P s outperform M F T P in most conditions. F o r a very poor link, such as 10~ , M F T P 5  performs better than S R M T P _ N O B . However, the other two S R M T P s still have shorter network delays than M F T P . This is because, for a B E R of 10" , P E R is high-up to 11.2%. For each user, 5  there are nearly 90 packets in a window (of 800 packets) which are corrupted. Since the maximum number of N A C K e d packets in an S M is set to be 16, it is impossible to inform the source of all the losses in the receivers in one S M . Receivers must wait until the next turn to send more N A C K e d packets. On the other hand, M F T P , as described in Chapter 2 uses bitmap to reflect the status of the block. If there is no packet lost in a block, no N A C K is sent. Once there is a loss in a block, the N A C K is sent. The length of the N A C K does not vary with the lost packets. That is why for a low B E R , M F T P needs more time than S R M T P s , since even for a single loss, the N A C K is much longer compared to S R M T P s , and collision is higher. In order to avoid S M collisions,  73  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  700  600  SRMTP-OBB SRMTP-OBP SRMTP-NOB MFTP  500 Link BER: 1E-7 400  300  200  100  100  200  300  400 500 600 Number of Users  700  800  900  1000  Figure 5.21 Throughput Comparison of M F T P and S R M T P s , Link BER=10"  7  S R M T P s use the round robin method to submit S M , and the S M is considerably shorter than the M F T P ' s N A C K . A s the link B E R increases to 10" , the N A C K length is still the same for M F T P , 5  although N A C K e d packets increase. For S R M T P s , several S M s are needed to report all the loss in the receiving buffer. Therefore, more time is needed to multicast the whole file to all the receivers. However, with O B P and O B B , performance is still better than for M F T P , as the lost packets on the uplink are not forwarded to the end users. Once an S M is received correctly by the satellite OBP, the lost packets are retrieved from the O B B , and can be retransmitted by the O B P instead of from the original source. Consequently, the overall network delay is still shorter than M F T P .  Figure 5.21 shows the comparison of the system throughput versus the varying receivers in the M F T P and the S R M T P s . W h e n the user number is 100, our proposed protocols S R M T P _ O B B , S R M T P _ O B P and S R M T P _ N O B increase the throughput to 39.4%, 23.6%, and 21.32% of the M F T P , respectively. A s the user group increases to 500,  SRMTP_OBB,  Chapter 5 Design of Simulation Models and Discussions of Simulation Results  74  S R M T P _ O B P and S R M T P _ N O B increase the throughput to 4 3 % , 33.4%, and 27.55% of the M F T P , respectively. S R M T P _ O B B , S R M T P _ O B P and S R M T P _ N O B increase the throughput to 43.98%, 36.82% and 32.3% of the M F T P , respectively, for a thousand users.  The main concept behind this scheme is for S R M T P s to use window-based schemes, which send the receiver status in a timely manner while M F T P sends N A C K s only when packet loss occurs. If the acknowledgments' collision or corruption are not considered in the return channels, then the sender can always receive acknowledgments in time, and retransmit the lost ones. However, in our system configuration, N A C K s may collide or be corrupted. If the acknowledgments cannot reach the sender, the receiver must wait until the next retransmission finishes, and then send the N A C K s once again. Hence, the overall time the system needs for multicasting increases. S R M T P s achieve high performance at the cost of more return traffic.  Chapter 6 Conclusions Broadband satellite networks are ideal for providing broadband Internet access to users in rural areas which do not have a high-speed terrestrial infrastructure. The broadcast nature of satellite downlink, and the importance of efficient channel utilization in satellite networks, combine to present a unique application of multicasting for data delivery to many users simultaneously. However, the inherent nature of satellites provides some challenges in design protocols. Although there are many concerns about Internet reliable multicast protocols, relatively fewer works are related to satellite reliable multicast protocols. This thesis focuses on design satellite reliable multicast protocols over a pure G E O satellite system, and considers both satellite systems employing bent-pipe transponders and O B P / O B B , in order to satisfy the current and future needs of industry. T h e thesis develops novel, reliable bulk data transfer protocols, S R M T P s , for broadband satellite networks that employ dynamic and independent uplink/downlink error recovery with satellites' O B P and O B B . Also, effective buffer management, window flow control schemes, and error recovery schemes are incorporated. The system models are implemented using O P N E T , and the system performances are analyzed with some discussion.  6.1 Summary of the Work  The primary contribution of this thesis is our proposal of S R M T P s that can to reliably multicast bulk data to a group of users using a satellite channel. The proposed protocols multicast bulk data via a full-duplex satellite system that uses satellite links for both forward and return paths, and takes into consideration packet corruption and collision over the return link. It generally outperforms existing multicast protocols, such as M F T P . In addition, satellite onboard  75  Chapter 6 Conclusions  76  processing ( O B P ) and onboard buffering ( O B B ) are considered to enhance multicasting. O B P improves system performance by detecting uplink errors in advance, while O B B is used to decrease downlink retransmission in order to improve system performance.  Throughput performance of three S R M T P s , namely S R M T P _ N O B , S R M T P _ O B P , and S R M T P _ O B B are analyzed and compared. With O B B , performance is the best of a l l , while though lesser, performance with O B P is better than without it. The effect of chosen S R M T P parameters, such as window size, buffer size, and file size are also inspected. System throughput is heavily dependent on window size for satellite systems with a large RTT. It is determined that window size should be no less than the bandwidth product in order to achieve high performance. The O B B buffer size can further improve performance as the buffer size increases until it reaches the window size. File size also has an effect on system throughput. Multicasting large files is more efficient than multicasting small files via a fat satellite channel.  O B P can separate the uplink channel and downlink channel. With O B P , packet loss can be detected in advance. O B P is designed to recover uplink errors. W h i l e channel conditions are good, S R M T P _ N O B and S R M _ O B P show almost the same performance, which means there is no specific reason to use O B P for ideal channels. A s channel conditions worsen, O B P reveals its power by reducing acknowledgment time.  O B B is designed to recover d o w n l i n k errors. B y buffering packets, packets lost by downlink receivers can be retrieved from the onboard buffer. O B B can reduce the retransmission time by retransmitting lost packets from satellite O B P instead of from the original source.  The proposed protocols are evaluated further with part of the receivers' encounter link  Chapter 6 Conclusions  77  fading. The proposed protocols work well, while the degraded BER is one decade bigger than the nominal BER. While the degraded BER is a hundred fold larger than the nominal BER, the throughput decreases considerably even with a very small percentage. However, as the percentage grows, the decrease becomes limited. The performances of the existing multicast protocol of MFTP and SRMTPs are analyzed and compared. SRMTPs show better performance for most cases, and enhance throughput, especially for large user groups. Based on the performance of the protocols, it is observed that SRMTPs generally outperform existing multicast protocols, such as MFTP. Comparing the different satellite network configurations, SRMTP_OBB gives the best performance, followed by SRMTP_OBP and SRMTP_NOB. Based on the simulation, SRMTPs are indeed scalable, efficient and reliable multicast transport protocols over satellite broadband networks.  6.2 Future Work  To further extend the work of this thesis, the following possible directions for future research are suggested. 1. In this thesis we work on the assumption that all receivers have the same data rate. In reality, some receivers may be faster than others. The implementation and experimentation of the protocols in a dynamic user group are highly desirable for validating the results presented here. 2. SRMTPs are satellite-optimized protocols, which should be used between the proxy and the gateway/user. In practice, receivers may be distributed in a heterogeneous network environ-  Chapter 6 Conclusions  78  ment. R T T for different users is also varied according to time. The evaluation of S R M T P s ' performance in varied R T T is also a necessity.  3. In the simulation, an automatic retransmission request ( A R Q ) is used for error recovery. O B P separates the uplink and downlink channels so that different A R Q s can be used in each link. Further work w h i c h combines different forward error correction ( F E C ) schemes is highly recommended. The key advantage of packet F E C is its ability to provide a repair, which may satisfy a number of uncorrected loss patterns. A s such, it is a powerful technique for constructing protocols designed for wide-scale multicasting, and works equally well in highly asymmetric or receive-only satellite networks. The disadvantages of packet F E C are processing overhead and delays associated with coding and decoding, and the selection of appropriate F E C codes for the data requirements and actual loss patterns. Failure to select an appropriate code may result in either a high proportion of clients failing to complete the transfer, or at the other extreme, large amounts of unnecessary network traffic. In contrast, repair by retransmission has a low processing overhead, but scales poorly to large groups that suffer uncorrected packet loss. It also relies upon feedback, and care is needed to prevent an implosion of repair requests when multiple receivers experience loss. A combination of the two schemes is possible and may have merit.  4. S R M T P s are designed to be tailored over a pure satellite channel to best suit the characteristics of the underlying link. Due to the fact that future broadband satellite networks will offer Internet connections v i a satellite networks, integrating the S R M T P with Internet multicast protocols is vital to further work.  Acronyms ACK  Acknowledgment  ARQ  Automatic Retransmission Request  ATM  Asynchronous Transfer Mode  BER  Bit Error Rate  CERSM  Centralized Error Recovery Satellite Multicast  DERSM  Distributed Error Recovery Satellite Multicast  DR  Designated Receiver  DSL  Digital Subscriber Line  FDDI  Fiber Distributed Data Interface  FEC  Forward Error Correction  FTP  File Transfer Protocol  GEO  Geosynchronous Earth Orbit Satellite  HTTP  HyperText Transfer Protocol  ICMP  Internet Control Message Protocol  IF/RF  Intermediate/Radio Frequency  IGMP  Internet Group Management Protocol  IP  Internet Protocol  LP  Low Buffer Point  MFTP  Multicast File Transfer Protocol  79  Acronyms  SO  MTU  M a x i m u m Transfer Unit  NACK  Negative Acknowledgment  OBB  Onboard Buffering  OBP  Onboard Processing  OBR  Onboard Routing  OBS  Onboard Switching  PCR  Packet Corruption Ratio  PER  Packet Error Rate  QoS  Quality of Service  RMTP  Reliable Multicast Transport Protocol  RTT  Round Trip Time  SATCOM  Satellite Communication  SR A R Q  Selective Repeat A R Q  SM  Status Message  SMTP  Simple M a i l Transfer Protocol  SRMTP  Satellite Reliable Multicast Transport Protocol  SRMTP_NOP  Satellite Reliable Multicast Transport Protocol without O B P  SRMTP_OBP  Satellite Reliable Multicast Transport Protocol with O B P  SRMTP_OBB  Satellite Reliable Multicast Transport Protocol with O B B  TCP  Transmission Control Protocol  Acronyms  81  TPDU  Transport Protocol Data Unit  UDP  User Datagram Protocol  VSAT  Very Small Aperture Terminal  WWW  World Wide Web  XOR  Exclusive-OR  Bibliography [I]  M. Sturza, "The Teledesic Satellite System," in Proc.  1994 IEEE Nat. Telesyst. Conf.,  pp.123-126, 1994. [2]  E. Fitzpatrick, "SPACEWAY System Summary,"  Space Commun.,  vol. 13, no. 1, pp7-  23, 1995. [3]  J. Farserotu, "A Survey of Future Broadband Multimedia Satellite Systems, Issues and Trends,"  [4]  IEEE Communications Magazine,  vol. 38, Issue 6, pp. 128-133, June 2000.  L. Goldberg, "The Internet in Space: Problems and Solutions," Computer, vol. 30, pp. 15-16, Feb. 1997.  [5]  H. D. Clausen and H. Linder, "Internet Over Direct Broadcast Satellites," IEEE mun. Magazine,  [6]  vol. 37, pp. 146-151, June 1999.  P. Chitre and F. Yegenoglu, "Next-generation Satellite Networks: Architectures and Implementations,"  [7]  Com-  IEEE Comm. Magazine,  vol. 37, pp. 30-36, March 1999.  I. Akyildiz and S. Jeong, "Satellite ATM Networks: A Survey,"  IEEE Commun. Mag.,  vol. 35, Issue 7, July 1997, pp. 30-43, 1997. [8]  T. Pratt and C. W. Bostian,  [9]  L. S. Golding, "Satellite Communications Systems Move into the Twenty-first Centry," ACM  [10]  Wireless Network,  Wiley, 1986.  vol. 4, Issue 2, pp. 101-107, 1998.  T. R. Henderson and R. H. Katz, "Transport Protocols for Internet-compatible Satellite Networks,"  [II]  Satellite Communications,  IEEE J. Sel. Areas in Commun.,  vol. 17, pp. 326-344, Feb. 1999.  N. Ghani and S. Dixit, "TCP/IP Enhancements for Satellite Networks," IEEE mun. Mag., vol. 37, Issue 7, pp. 64-72, July, 1999.  82  Com-  Bibliography  [12]  83  P. Sanjoy, Multicasting  on the Internet and its Applications, K l u w e r academic Publish-  ers, 1998. [13]  E . Henriksen and G . Aas, " A Transport Protocol Supporting Multicast File Transfer Over Satellite Links," Proc. Computers and Commun. Conference,, pp. 590-596, 1992.  [14]  H . Linder and I. Miloucheva, " A Forward Error Correction Based Multicast Transport Protocol for Multimedia Applications in Satellite Environments," Performance, Computing, and Commun. Conference, I P C C C 1997, pp. 419-425, 1997.  [15]  S. Paul, "Reliable Multicast Transport Protocol ( R M T P ) , " IEEE J. Selected Areas Comm., vol. 15, pp. 407-420, Apr. 1997.  [16]  S. Deering, "Host extensions for IP multicasting," IETF, Internet Requests for Comments R F C 1 1 1 2 , August 1989.  [17]  M . W. Koyabe and G . Fairhurst, "Reliable Multicast V i a Satellite: a Comparison Survey and Taxonomy," Int. J. Satell. Commun., vol. 19, pp. 3-28,  [18]  J. P. Macker, "The Multicast Dissemination Protocol ( M D P ) Toolkit," Proc. IEEE, MILCOM  [19]  2001.  1999,  vol. 1, pp. 626 -630,  1999.  C . Hanle, "Feasibility Study of Erasure Correction for Multicast File Distribution Using the Network Simulator ns-2 " Proc. IEEE, MILCOM  98, vol. 3, pp. 1060-1066,  1998. [20]  J.Gemmell and J. Gray, "Feast Multicast File Distribution," IEEE Network, vol. 14, Issue 1, pp.58-68, 2000.  [21]  R. Talpade and M . H . Ammar, "Single Connection Emulation (SCE): A n Architecture for Providing a Reliable Multicast Transport Service," Proc. of the 15th International Conference on Distributed Computing Systems, pp. 144 -151,  1995.  Bibliography  [22]  84  J. He and K. R. Subramanian, "Performance Evaluation on the Satellite Based Reliable Multicast With and Without Local Recovery," Universal Multiservice Networks, E C U M N 2000, pp. 311-318, 2000.  [23]  U . Quernheim and R. Vermohlen, "A New ARQ-scheme for Multicast Satellite Communication," Satellite Commun. -ECSC-3, pp. 11-15, 1993.  [24]  K . Asai and N . Osawa, "Reliable Multicast File Transfer on the Inter-university Satellite Network," Proc. Communication Technology, WCC-ICCT  2000. vol. 2, pp. 1137-  1140,2000. [25]  C. K. Tan, "Reliable IP Multicast Services Over Satellite Links," Networks, ICON 2000, pp. 411-415, 2000.  [26]  K . Miller and K. Robertson, "StarBurst Multicast File Transfer protocol (MFTP) Specification," IETF, lETF-Draft  [27]  <draft-miller-mftp-spec-03.txt>, July 1998.  G. Cao and Y. Wu, "Reliable Multicast Via Satellites," Proc. International Conference on Information Technology: Coding and Computing, pp. 183-188, 2001.  [28]  A . S. Tanenbaum, Computer Networks, 3rd version, Prentice hall, 1996.  [29]  J. P. Macker and J. E. Klinker, "Reliable Multicast Data Delivery for Military Networking," Proc. MILCOM' 96, pp. 399-403, 1996.  [30]  C. K. Miller, "Reliable Multicast Protocols: A Practical View," Local Computer Networks, 1997', Proc. 22nd Annual Conference, pp. 369-378, 1997.  [31]  H . Eriksson, " M B O N E , The multicast backbone," Comm. ACM, vol. 37, no.8, pp707720, May 1993.  [32]  I. Gopal and J. Jaffe, "Point-to-Multipoint Communication over Broadcast Links," IEEE Trans. Comm., vol. 32, pp!034-1044,Sept. 1984.  Bibliography  [33]  85  D. Towsley, "An Analysis of a Point-toMultipoint Channel Using a Go-Back-N Error Control Protocol," IEEE Trans, on Communications, 33:282-285, March 1985.  [34]  A . Koifman and S. Zabele, " R A M P : A Reliable Adaptive Multicast Protocol," Proc. vol. 3, pp. 1442-1451, 1996.  IEEE INFOCOM,  [35]  S. Floyd and V. Jacobson, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing," IEEE/ACM  Transactions on Networking,  vol. 5, no.  6, Dec. 1997. [36]  U . Quernheim, "Satellite Communication Protocols - A Performance Comparison Considering On-board Processing," Electrotechnics, 1988. Proc. on Area Communication, EUROCON  [37]  88, pp. 269 -272, 1988.  A . Chen and C. Chang, "Performance Evaluation of A R Q Operations With OBP and Inter-satellite Links: Delay Performance," VTC 2001 Fall. IEEE VTS 54th, vol. 4, pp. 2346-2350, 2001.  [38]  A . Chen and Y. Yao, "ARQ Performance In a Satellite Communications System With Inter-satellite Links," Proc. Communication Technology, WCC - ICCT2000, vol. 2, pp. 1126-1132, 2000.  [39]  I. Minei and R. Cohen, "High-speed Internet Access Through Unidirectional Geostationary Satellite Channels," IEEE J. Sel. Areas in Commun., vol. 17, pp. 345-359, Feb. 1999.  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0065182/manifest

Comment

Related Items