Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Dynamic congestion control methods to improve performance of TCP split connections over satellite networks Wu, Lijuan 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-0612.pdf [ 3.37MB ]
Metadata
JSON: 831-1.0065348.json
JSON-LD: 831-1.0065348-ld.json
RDF/XML (Pretty): 831-1.0065348-rdf.xml
RDF/JSON: 831-1.0065348-rdf.json
Turtle: 831-1.0065348-turtle.txt
N-Triples: 831-1.0065348-rdf-ntriples.txt
Original Record: 831-1.0065348-source.json
Full Text
831-1.0065348-fulltext.txt
Citation
831-1.0065348.ris

Full Text

DYNAMIC CONGESTION CONTROL METHODS TO IMPROVE PERFORMANCE OF TCP SPLIT CONNECTIONS OVER SATELLITE NETWORKS by L I J U A N W U B . E . , Tianjin University, China, 1993 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES Department of Electrical and Computer Engineering We accept this thesis as. conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA October 2002 © Lijuan Wu, 2002 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of The University of British Columbia Vancouver, Canada Date DE-6 (2/88) Abstract Satellites play important roles in global telecommunications. However, the performance of Transmission Control Protocol (TCP) for reliable data transfer over the Internet suffers significant degradation over satellite networks due to high bit error rate and the long latency of satellite links. Among the methods proposed for alleviating the impact of satellite link characteristics on TCP performance, the split TCP connection separated by performance enhancement proxies between the satellite and terrestrial Internet segments proves to be attractive for improving end-to-end TCP performance while keeping the TCP configurations in end systems unchanged. In this thesis, we propose a dynamic TCP congestion control mechanism for the satellite segment in a split TCP connection scenario. This scheme uncouples the TCP congestion control and error recovery operations, which benefits error-prone channels, and allows immediate congestion feedback from underlying layer, which benefits long delay channels. We model a satellite network with two gateways, which is widely studied in the literature, and contribute a new system architecture with a single gateway, which employs a medium access control protocol for very small aperture terminals accessing a shared satellite uplink. Different from other approaches, the random early detection queue is deployed in the gateway. Based on these two models, the performance between the proposed mechanism and other ubiquitous TCP versions is compared under a number of network scenarios. Simulation results show that our proposed mechanism improves TCP performance significantly, and is more robust when the traffic load is heavy. Table of Contents Abstract " Table of Contents iii List of Tables vi List of Figures vii Acknowledgments ix Chapter 1 Introduction 1 1.1 Background 2 1.1.1 Features of Broadband Satellite System 2 1.1.2 The Internet Protocol Architecture 5 1.1.3 TCP Limitations over Satellite Networks 6 1.1.4 Possible Solutions 9 1.2 Objectives 10 1.3 Outline of the Thesis 12 Chapter 2 TCP Fundamentals 13 2.1 TCP Overview 13 2.2 TCP Implementations 16 2.2.1 TCP Reno 16 2.2.2 TCP NewReno 18 2.2.3 TCP S A C K 18 2.2.4 TCP Vegas 19 2.3 TCP Options 22 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks 25 iii 3.1 A Modified Internet Architecture 25 3.2 Performance Enhancement Proxy (PEP) 26 3.2.1 The Concept of PEP 26 3.2.2 TCP Split Connection 29 3.3 Interworking 31 3.3.1 TCP Set Up and Tear Down 32 3.3.2 Interworking Congestion Control 34 3.4 Random Early Detection Queue 35 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways 39 4.1 System Architecture 39 4.2 Proposed Dynamic S A C K Mechanism (DSACK) 39 4.3 Simulation Results 42 4.3.1 Single Connection Case 44 4.3.2 Multiple Connections Case 50 4.4 Summary 52 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway 53 5.1 Sy stem Architecture 53 5.2 The M A C Protocol and Characteristic 54 5.3 Proposed Dynamic TCP Vegas Mechanism (DVegas) 57 5.4 Simulation Results 58 5.4.1 Impact of Uplink Bandwidth 59 5.4.2 Impact of Controlling Parameters on RTT 61 5.4.3 Impact of Traffic Load 63 iv 5.4.4 Impact of Buffer Capacity 63 5.4.5 Impact of BER 64 5.5 Summary 66 Chapter 6 Conclusion and Future Works 67 6.1 Summary of Findings 67 6.2 Future works 68 Bibliography 70 Appendix A. List of Abbreviations and Acronyms 75 Appendix B. NS2 Simulation Models 78 List of Tables Table 2.1 S A C K option usage 18 Table 3.1 Performance enhancement proxy functions 27 Table 4.1 Events and action 42 Table 4.2 Simulation parameters for two-gateway model 43 Table 4.3 Difference between three schemes 44 Table 5.1 Simulation parameters for one-gateway model 58 Table 5.2 Number of packets dropped 63 vi List of Figures Figure 1.1 Internet protocol architecture 5 Figure 1.2 TCP data communication between end hosts 6 Figure 2.1 IP datagram and TCP segment 14 Figure 2.2 TCP header 14 Figure 3.1 Modified system architecture 26 Figure 3.2 Difference between TCP spoofing and TCP splitting 29 Figure 3.3 General system architecture 30 Figure 3.4 Datagram of TCP set up and tear down 33 Figure 3.5 Flow control between satellite networks and terrestrial networks 36 Figure 3.6 The packet mark/drop probability of RED queue 37 Figure 4.1 Two-gateway system architecture 40 Figure 4.2 Congestion control architecture 41 Figure 4.3 Throughput of single connection without bit error 45 Figure 4.4 Congestion window without bit error 46 Figure 4.5 Average queue length without bit error 47 Figure 4.6 Impact of bit error rate on single connection throughput 48 Figure 4.7 Congestion window when BER=10"6 49 Figure 4.8 Average queue length when BER=10"6 50 Figure 4.9 Throughput of multiple connections without bit error 51 Figure 4.10 Impact of bit error rate on multiple connections throughput 51 Figure 5.1 One gateway system architecture 54 Figure 5.2 Frame structure 56 vii Figure 5.3 Impact of V S A T uplink bandwidth on throughput 60 Figure 5.4 Impact of V S A T uplink bandwidth on round trip delay 60 Figure 5.5 Impact of R T T controlling parameter on throughput 62 Figure 5.6 Impact of R T T controlling parameter on round trip delay 62 Figure 5.7 Impact of traffic load, buffer capacity and bit error rate on throughput 65 Figure 5.8 Impact of bit error rate on throughput (BER= 10 6) 66 Figure B . l Network interface stack 78 Figure B.2 Structure of class SatNode 79 viii Acknowledgments I would like to extend my sincere gratitude towards my supervisor, Dr. Victor C M . Leung, for his guidance and constant source of inspiration throughout my graduate studies at the University of British Columbia (UBC). I would like offer my appreciation to Fei Peng for her continuous support. Last but not the least, I would like to thank the helpful staff of the Department of Electrical and Computer Engineering at UBC. This work is supported by grants from Com Dev International and the Canadian Institute for Telecommunications Research under the N C E program of the Canadian Government, and by the Canadian NSERC/CSA Partnership Program under grant CSA223232-98. ix Chapter 1 Introduction Global Internet communication has experienced explosive growth since 1990 and plays an increasingly important role. The availability of high-speed Internet access at a reasonable cost will greatly empower people, institutions and corporations, and enhance their social-economic well-being. Whereas high-speed Internet access technologies, such as cable modem and digital subscriber loop are becoming popular, they mainly benefit densely populated urban areas where they can be economically deployed. For geographically remote or underdeveloped regions, creating such an infrastructure is time-consuming and expensive. The use of geostationary earth orbit (GEO) and low earth orbit (LEO) satellites for offering high-speed Internet access provides an attractive, and sometimes the only, alternative. Moreover, with the advent of the World Wide Web (WWW), broadband Internet access tends to be highly asymmetric in traffic usage, with users downloading much more information than they generating. This type of traffic pattern matches well with satellite networks, where it is much cheaper to receive data at broadband rates than to transmit at such a rate. With these merits, satellite offers the promise of a rapidly deploy-able communication infrastructure for providing high-speed Internet access. Active research is ongoing to make the high-speed Internet access over satellite networks functional and cost-effective. The efforts for improvement involve both satellite and terminal hardware, as well as protocol architecture. With years of development, satellites have evolved from simple space repeaters to much more powerful devices with other capabilities, such as on-board processing (OBP) and switching functions. Since satellite channels are characterized as high bit error rate (BER) and long propagation delay, protocol suite must adapt to these special channels to work efficiently. For this reason, the success of delivering high-speed Internet access 1 Chapter 1 Introduction also depends on the appropriate design of underlying protocols that can fit into the satellite environment. Although some research work has evolved to deal with these issues, how these satellite systems are best configured for connectionless Internet services, and how they affect the end-to-end performance of these Internet services, is not widely studied. Much work remains to be done to assess the impact of Internet access via satellite on the end-to-end transport performance of various applications, identify interworking and performance issues, and develop practical solutions to enable cost effective and efficient use of satellites to access all types of Internet applications and services. In this thesis, we concentrate on the application of satellite systems to provide broadband Internet access, and focus on in particular, improving the performance of reliable Transmission Control Protocol (TCP) by employing split-connection proxies over high B E R high latency paths. We first describe the fundamental characteristics and technological trends of both satellite communication and the present-day Internet. 1.1 Background 1.1.1 Features of Broadband Satellite System A satellite communication system, distinguished by its global coverage, inherent broadcast capability, bandwidth-on-demand flexibility, and the ability to support mobility, is an excellent candidate for providing broadband integrated Internet services to globally scattered users. Using steerable spot beam antennas and regenerative transponders with on-board signal processing and switching, future generation satellites wil l be capable of supporting broadband Internet services using very small aperture terminals (VSATs) located at users' premises. Currently, Internet access service is available for asymmetric connections employing a high-speed Chapter 1 Introduction satellite link for network-to-user traffic and a slow-speed dial-up link for user-to-network traffic [1]. A n all-satellite solution using satellite links for both traffic directions capable of efficiently supporting asymmetrical and symmetrical traffic load is useful for some applications and necessary for others, such as high quality video conferences. We concentrate on such system topology in order to satisfy the current and future needs of industry. The most cost-effective solution for satellite coverage is the GEO whereby a satellite is located at the fixed location approximately 22,300 miles above the equator. A few GEO satellites, if properly designed, can seamlessly cover the entire surface of the earth, making it extremely appealing to aeronautical and maritime users, and to those in remote areas lacking a terrestrial communication infrastructure. However, GEO satellite channels are characterized by a high BER, long propagation delay, large bandwidth-delay product and are highly asymmetric, which has some adverse effect on Internet Protocol suite [2-5]. • Transmission Errors: Reduced signal to noise ratio (SNR) is a major concern in satel-lite transmissions, since signal strength falls proportional to the square of the distance. Measurements show that uncoded satellite channels can have BER values around 10"6 [6], much higher than cable or fiber links. Using legacy equipment and many existing transponders [7], which are optimized for analog voice and video services, the BER may be as high as 10"4 in the worst case, and 10"7 on average. In a digital satellite com-munication system [8], the normal BER should be in the order of 10"8 or less for clear sky operations. However, it may be degraded a few decades during various random at-mospheric or space conditions, such as rain attenuation. 3 Chapter 1 Introduction • Latency: Latency is composed by propagation delay, transmission delay and queueing delay. In the broadband GEO satellite case, the propagation delay is the dominant part. The speed of light dictates a one-way delay of approximately 250 milliseconds on a typical "hop" comprising of a GEO satellite uplink and downlink. Therefore, the round trip time (RTT) may be as high as 500 milliseconds. This long delay causes a large bandwidth-delay product, which means that a large number of packets must be kept "in flight" to fully utilize the satellite link. • Asymmetry: TCP performance not only depends on characteristics of links and traffic load in the direction of data transfer, but also depends on that of the reverse path [9]. Satellite networks exhibit asymmetry in several manners. Some are inherently band-width asymmetric, such as those networks employing a broadcast satellite downlink and a slow-speed dial-up link; while others may have many subscribers to share a common satellite link because of economic issues. For example, very small aperture terminals, can offer end users with very high downlink bandwidth, likely up to tens of Mbps, but only a limited uplink bandwidth not faster than several hundred Kbps or a few Mbps, due to uplink carrier sizing. • Congestion: Based on the fact that efficient utilization of satellite links requires statis-tical multiplexing, the congestion likely occurs at the link between the earth and satel-lites. With onboard switching or routing, a well designed satellite system should be able to avoid congestion on the satellite by properly scheduling transmissions in the ground stations. However, congestion may still occur at the gateway when there is too much traffic for the link or satellite onboard capacity. During congestion M A C may fail to receive reserved bandwidth, and packets are backlogged in the uplink buffers. Chapter 1 Introduction In this thesis, we investigate the impact of these satellite link characteristics on end-to-end TCP performance and propose a feasible solution. 1.1.2 The Internet Protocol Architecture The term of "the Internet" refers to a wide collection of packet switching networks that are tied together through the common use of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. Figure 1.1 illustrates a popular view of Internet protocol architecture. The Internet suite of communication protocol follows a four-layer model, as described in [10]. This protocol stack allows different kinds of computers, running on different operation systems, to communicate with each other over the world wide Internet. Each layer of TCP/IP protocol suite has its own responsibility. The link layer deals with all hardware related issues, such as the physical interface between different types of media. The network layer handles packet routing within the Internet. The transport layer transfers a flow of data between two end hosts for the application layer above. The application layer handles the details of the particular application and user process. Application Transport Network Link e.g. FTP, HTTP, Telnet TCP, UDP IP PPP, Ethernet Figure 1.1 Internet protocol architecture. 5 Chapter I Introduction IP is commonly used as a network layer protocol to route packet as a datagram by its addressing and routing mechanism. Since IP only provides a connectionless, best effort service, it does not guarantee reliability or in-order delivery for each packet. The packet may be lost or destroyed by the media, such as by network hardware failure, or packets delayed by dynamic network routing. It is the responsibility of the TCP, which is the ubiquitous transport protocol, to provide a reliable flow of data between two end hosts if the application requires reliable transmis-sion. The application can ignore all the details of data reliability issues, and only consider particu-lar uses like HyperText Transfer Protocol (HTTP), File Transport Protocol (FTP) and so on. Figure 1.2 shows the TCP data communications between two remote TCP hosts and all the protocols involved. Host Network node • Network node n Host Host-host Interface Application Transport Physical/LinkH-Network Physical/LIiiW Network Physical/LlnH Host-n etwork Interface Network-n etwork interface Application Transport Network Physical/Link] Host-network interface Figure 1.2 TCP data communication between end hosts. 1.1.3 TCP Limitations over Satellite Networks TCP are proposed to provide reliable end-to-end transmission over a number of network topologies and many different kinds of physical media, without knowledge of the underlying link characteristics. To achieve this purpose, the congestion control mechanisms of TCP are designed 6 Chapter 1 Introduction to be very conservative. However, these conservative mechanisms guarantee the reliability by sacrificing efficiency in some cases, especially when more and more new network topologies and media with distinctive characteristics are added to the Internet. In order to balance the demands of higher efficiency and good adaptability, the Internet Engineering Task Force (IETF) working groups propose many options to enhance the TCP service. TCP employs a window based scheme to control the flow rate from sender to receiver. It also uses a cumulative positive acknowledgment with a retransmission scheme for error recovery. By adapting to the end-to-end delay and packet error rate, TCP error recovery and congestion control mechanisms perform well in low bit error rate terrestrial networks. However, communica-tions over satellites are quite different from these traditional networks. The inherent characteris-tics of satellite links often result in a significant degradation of TCP throughput. A severe limitation of TCP that is particularly troublesome to satellite links with a non-negligible packet error rate lies in its inability to distinguish between network congestion loss and transmission error loss. Raw satellite links are more noisy than wireline media. Bit error rates of the order of 10"6 or more are often observed, even under good weather conditions. Furthermore, errors on satellite links tend to be bursty by nature. TCP is a loss sensitive protocol, using packet loss to control transmission behavior. Therefore, packet corruption is incorrectly interpreted by TCP as congestion to be mitigated by reducing the transmission window, thus severely limiting throughput. When a packet loss is encountered, the lost packet is retransmitted and the rate of sending is reduced. Many studies [11 , 12] confirm that noisy satellite links lead to great TCP performance degradation since measurable BER values prematurely trigger the window reduction mechanism, even i f the network is uncongested. In addition, TCP uses a cumulative acknowledg-7 Chapter 1 Introduction ment scheme, and so can discover only one segment loss every round trip. Thus i f multiple segments are lost in one window of data, throughput is reduced sharply. TCP uses a closed-loop positive feedback mechanism to determine its transmission rate. To avoid congestion in the network, every connection starts with a slow start phase, in which the congestion window is initialized to one segment, and is increased by one segment for every new acknowledgment received. When the congestion window size is beyond a threshold, or a packet is lost, the congestion avoidance phase is started, and the window size is increased by one segment every time a complete window of data is acknowledged. Due to the low initial window, TCP slow start takes up to several seconds for the congestion window to grow large enough to effectively utilize the link bandwidth. This is a problem in the satellite environment where the round trip delay is as long as 500ms, especially those short-lived connections that suffer from low through-put. Some studies [13] show that a connection with smaller RTT can capture most of the network bandwidth at the expense of a long-delay channel. A different problem is seen during the congestion avoidance phase. In this phase the window grows by only one segment every RTT, so window growth is much slower than in slow start. Thus, i f the congestion window reduction is premature when congestion avoidance is entered, the satellite link can be under-utilized for prolonged periods of time. Most data transferred over a satellite link can thus complete without having attained a window large enough for optimal link utilization. This problem is more serious when the link condition is poor, which causes congestion avoidance to be entered too early. Furthermore, the header of each segment contains an offered window, which represents the largest amount of data that the destination permits the remote end to send without receiving further permission. This offered window is 8 Chapter 1 Introduction represented by a 16-bit field, which restricts its value to 64 kilobytes. Some implementations limit the maximal window size to 32 kilobytes, and many popular implementations default to a window of 8 kilobytes. Since TCP can not send more than one window of data per RTT, the maximal throughput attainable by a connection over a GEO satellite link may be restricted to 128 Kbps. 1.1.4 Possible Solutions In light of the above problems, many researchers have proposed solutions to improve TCP performance over satellite networks. The possible solutions can be classified into three categories: link level solutions [14], end-to-end solutions [15-19], and TCP performance enhancement proxy (PEP) [20] solutions. These solutions are not mutually exclusive; so it is likely that all three kinds of solutions may be used together in a network. As link error rates are a major concern in satellite networks, link level solutions include link layer techniques like forward error correction (FEC) and automatic repeat request (ARQ) mechanisms to mitigate the problem of data corruption. One well-known FEC coding scheme is convolution code. Many advanced coding techniques also exploit bit interleaving to reduce the effects of burst error. In many situations, deploying these mechanisms can ensure that most losses seen by TCP are in fact due to congestion. However, increased coding complexity can slow down satellite modems and reduce bandwidth efficiency due to data redundancy. Many end-to-end solutions are proposed to elaborate current TCP versions, or as extensions to TCP. A number of them are adopted as TCP options or enhancements by IETF [15-19] since they begin to recognize the importance of satellite as a means of providing Internet access. We discuss these options further in the next chapter. It is worth mentioning that the effectiveness of these solutions is limited by the fact that not all given end systems support these 9 Chapter 1 Introduction kinds of extensions. The TCP PEP approach is attracting much attention nowadays as an effective solution for satellite networks. In this approach proxies are deployed in the network to separate links or groups of links with highly dissimilar characteristics. The advantage of the TCP PEP is that it acts on behalf of end systems without changing their configurations. The proxy services are customized specifically to compensate for specific link characteristics that would otherwise cause poor performance. This allows for the simplification of the protocols used in the end-user terminal, at the expense of additional complexity in the network. Since the proxies are designed to take advantage of local network characteristics, we can obtain closer-to-optimal performance than with the end-to-end approach. Both the link layer solution and end-to-end solution can be combined with this method to enhance TCP performance. Split-connection proxies belong to this class of solutions. 1.2 Objectives The overall goals of the thesis are to investigate the end-to-end performance issues that arise when TCP split connections are employed in satellite networks to provide high-speed Internet access, and to develop novel solutions to address these issues. We propose a dynamic congestion control mechanism implemented as the proxy service for the satellite segment in a split TCP connection scenario. The aim is to uncouple the TCP congestion control and error recovery operations over the satellite channel. To combat the shortcoming of long propagation delay, our mechanism allows immediate congestion feedback from underlying layers at the PEP. This thesis focuses on the performance of different TCP implementations and one new proposal over a satellite link. In order to have a better TCP throughput, optimization of TCP parameters for 10 Chapter 1 Introduction a heterogeneous network under different conditions are considered. In this thesis, two system architectures are fully presented, and different proposals are employed to deal with specific characteristics. The objectives of the thesis are as follows: To improve TCP performance over satellite networks by deploying split connection proxies, and proposing a new dynamic congestion control mechanism. • To separate the TCP congestion control and error recovery mechanisms, which benefit error-prone channels. To realize the immediate feedback from the underlying layer, which benefits long la-tency channels. • To investigate the impact of bit error rate, traffic load, uplink bandwidth and some TCP options on TCP throughput and delay over satellite networks. This work is different from others in the following ways: • It considers a network architecture employing satellite for Internet access, which is configured with a number of VSATs, and employs a medium access control (MAC) protocol for multiple subscribers to access satellite links. • It compares the performance of the different TCP versions under different traffic loads to reveal their advantages and disadvantages. • It employs a random early detection (RED) queue in the gateway, which can achieve high throughput. 11 Chapter 1 Introduction 1.3 Outline of the Thesis In Chapter 2, an overview of basic TCP operations and different TCP implementations are presented and discussed. Chapter 3 provides a general system architecture and modified protocol stack of satellite communication employing split connection proxies. The basic algorithm of random early detection queue is given. Chapter 4 demonstrates the performance of the proposed mechanism and presents the simulation result of different TCP implementations in a satellite network environment over a two-gateway model. The simulation results and performance analysis of different TCP implementations in satellite network environments employing a single gateway scenario are given in Chapter 5. Finally, Chapter 6 summarizes all the findings and provides suggestions for future work. 12 Chapter 2 TCP Fundamentals The Transmission Control Protocol (TCP) [21, 22] is a transport protocol used by many Internet applications (such as web, file transfer, electronic mail and tele-learning), for end-to-end reliable data delivery. In this chapter, we describe the basis of a TCP operation, focusing on those aspects that are most relevant to satellite links. Then we discuss four different TCP implementa-tions: TCP Reno, TCP NewReno, TCP Selective Acknowledgement (SACK) and TCP Vegas. Finally, we introduce TCP options used to enhance TCP service over a satellite channel. 2.1 TCP Overview TCP provides a byte-stream, connection-oriented, reliable end-to-end data service for applications, guaranteeing in order delivery. In order to achieve all of these requirements, a lot of mechanisms are incorporated in TCP. In terms of byte-stream service, a TCP sender accepts a stream of data from an application in an arbitrary size, and the TCP receiver sends the identical stream to its application layer. TCP data and acknowledgment (ACK) are carried in a TCP segment, then encapsulated into an IP datagram, as shown in Figure 2.1. The TCP header carries the important identification and other control information. The format of the TCP header is illustrated in Figure 2.2. The byte-stream information is contained in the sequence number field, which is the byte number of the first byte being transmitted in the payload. The acknowledgment number field contains a cumulative acknowledgment, indicating the destination has received all the data up through but not including that byte. TCP's flow control is provided by each end advertising a window size. This is the number of bytes that the receiver is willing to accept. The total length of the TCP header is 20 bytes, except for the options. 13 Chapter 2 TCP Fundamentals IP Datagram TCP Segment IP Header TCP Header TCP Data Figure 2.1 IP datagram and TCP segment. 10 15 16 Source Port Number Destination Port Number Sequence Number Acknowledgement Number H L E N Reserved Flags TCP Checksum Window Size Urgent Pointer Options (if any) 31 20 Bytes H L E N : Header Length Figure 2.2 TCP header. In terms of connection-orientation, TCP needs to exchange specially labelled segments (using the flags field) to establish, terminate and reset a connection. To establish a TCP connec-tion, a three-way handshake mechanism with a clock-based sequence number is required to set up a unique end-to-end connection between two remote hosts. The handshake mechanism also brings parameters to negotiate initialization information, such as window size and options. To terminate an active connection, each side can send a FIN segment to another when it finishes transmission; the other side responds with an A C K for FLN. 14 Chapter 2 TCP Fundamentals In terms of reliability, TCP provides several error recovery operations. The basic error recovery mechanism for TCP is a retransmission time out (RTO) algorithm. After a TCP sender transmits a segment, a timer located at the sender waits for an interval of RTO for the receiver to A C K the data. If no A C K is received by the end of RTO, the data is retransmitted and a new timer is set based on the new time-out value. The RTO for a segment is based on the estimated round-trip time (RTT) and RTT variance of the connection. The subsequent time-out intervals for the same segment are doubled each time; this process is known as exponential backoff. By combining with the accumulated positive acknowledgment and TCP checksum, it can easily find damaged, lost or duplicated segments. The formula list below shows how to calculate the RTO [10]: Err = M-A A <--A+ g • Err D<^D + h-(\Err\-D) RTO = A + 4-D where M i s the measurement of RTT, A is the smoothed RTT (an estimator of the average) and D is the smoothed mean deviation. Err is the difference between the measured value just obtained and the current RTT estimator. Both A and D are used to calculate the next RTO. The gain g for the average is set to 1/8. The gain for the deviation is h, and is set to 1/4. The higher gain for the deviation makes the RTO go up faster than RTT changes. TCP also employs two other mechanisms to prevent network congestion, namely slow start and congestion avoidance. TCP maintains two variables known as the congestion window (cwnd) and slow start threshold (ssthresh) to switch between these two schemes. The congestion window is initialized to one segment upon connection startup, and represents the amount of data that may be outstanding at any time. The slow start threshold is the parameter determined at the 15 Chapter 2 TCP Fundamentals connection setup, usually initialized as the receiver advertised window. The scheme of slow start is used upon the start of the connection in order to rapidly probe for available bandwidth. During slow start, the value of the congestion window opens exponentially by adding one TCP segment each time it receives an A C K , until the congestion window reaches the slow start threshold or a TCP segment loss occurs. Then it enters the congestion avoidance scheme. During this phase, the congestion window is increased by at most one segment per RTT, to make the window size grow linearly. Finally, i f any retransmitted segment is lost (which may indicate serious congestion), the TCP sender is forced to take a time-out, which involves retransmitting the missing segment, reducing the congestion window to one segment and resuming the slow start. For satellite connec-tions, this time-out period and the following slow start may take several seconds during which the system experiences very poor throughput. 2.2 TCP Implementations Different TCP versions have evolved over years since the standard TCP (TCP Tahoe) [23] was first implemented in Unix 4.3 BSD in 1988. TCP Reno was proposed in 1990 on the basis of TCP Tahoe with a new error recovery scheme [24]. There are some other TCP Reno variances, such as NewReno [22] and TCP S A C K [18]. TCP Vegas is recently proposed in [25]. In this section, we focus on TCP Reno, TCP NewReno, TCP S A C K and TCP Vegas. 2.2.1 TCP Reno TCP Reno has four basic schemes to control the congestion window: slow-start, conges-tion avoidance, fast recovery and fast retransmit. We discussed slow start and congestion avoidance before. The fast recovery is aimed to detect segment loss more quickly without trigger-ing a time-out; the fast retransmit is aimed to prevent the communication path from going empty 16 Chapter 2 TCP Fundamentals after a fast retransmit, thus avoiding the need to slow start to refill the path. With fast retransmit, after receiving a small number (usually 3) of duplicate A C K s for the same TCP segment, the sender infers that a segment is lost, and retransmits the segment without waiting for a retransmission timer to expire. With fast recovery, once the threshold of duplicate A C K s is reached and the sender retransmits the lost segment, TCP Reno reduces its congestion window by one half. Instead of a slow start, the Reno sender uses the additional incoming duplicate A C K to clock out subsequent outgoing segments because a duplicate A C K means that one segment goes out of networks. Fast retransmit and fast recovery benefits the situation in that a single segment is dropped from a window of data. However, when two or more segments are dropped in an RTT, Reno can still suffer performance problems. The advantage of TCP Reno lies in its adaptive retransmission and congestion control mechanisms. However, TCP Reno has no mechanism for detecting incipient congestion or preventing segment loss because of the essential nature of lost segments in the congestion control mechanism adopted. This occasionally becomes a problem because a segment may be lost due to TCP sender's too large window size. It assumes segment loss is caused by link congestion, which is the case in the wired link, but it is not suitable for the wireless link or satellite link when the B E R is relatively high. A satellite link is a long-fat channel; this worsens the situation when segment loss is due to error corruption. After the sender cuts its window in half due to error, the congestion window increases only linearly, not exponentially; the long RTT harms its perfor-mance much more seriously than in a wired network. Therefore, TCP Reno's performance degrades significantly when segment loss is caused by transmission error. Another major shortcoming of TCP Reno is that TCP Reno can retransmit at most one lost segment per RTT, and 1 7 Chapter 2 TCP Fundamentals has to cut its congestion window several times when multiple segments lost from the same window of data. Two major enhanced versions to TCP Reno are NewReno and S A C K . 2.2.2 TCP NewReno TCP NewReno inherits slow start, congestion avoidance and fast retransmit mechanisms from TCP Reno. The difference lies in fast recovery. In fast recovery, TCP NewReno just cuts its congestion window half once when it encounters two or more segment loss in the single window of data. It does not end its fast recovery i f it detects another segment lost in the same window. 2.2.3 TCP SACK The S A C K option allows multiple segments recovery in a single window per RTT. The S A C K option field contains a number of S A C K blocks, they represent a group of non-contiguous segments that have been received and queued. The first block in S A C K is required to report the receiver's most recently received segment, and the additional S A C K blocks repeat the last reported S A C K block. Due to the limited space for the TCP header, the S A C K option has room for at most four blocks. TCP S A C K option does not change the original acknowledgement field. We use an example to illustrate the usage of S A C K option. Table 2.1 SACK option usage. Triggering Segment A C K First Block Second Block Third Block 0-1023 1024 1024-2047 lost 2048-3071 1024 2048-3071 3072-4095 lost 4096-5119 1024 4096-5119 2048-3071 5120-6143 lost 6144-7167 1024 6144-7167 4096-5119 2048-3071 18 Chapter 2 TCP Fundamentals TCP S A C K implementation preserves the basic congestion control schemes of TCP Reno. However, TCP S A C K allows the sender to explicitly retransmit those omissions and significantly reduce unnecessary retransmissions. Thus, TCP becomes robust in the presence of out-of-order segments, and uses the retransmit time-out as the last recovery resort. Results show that TCP S A C K performs very well in a long-delay environment with moderate losses, retransmitting all lost segments within the first RTT after fast recovery is triggered. Some studies [26, 27] state that S A C K feature reduces time-outs and is not overly aggressive when competing with non-SACK options. Average throughput improvements are measured from 15% to 50% over various terrestrial Internet settings. Nevertheless, under an extreme link error rate (10"6), even TCP S A C K is unable to prevent excessive time-outs, and average TCP throughput is below 15% [11]. Another issue concerning the S A C K option is that it requires the modification to both source and destination protocol stacks. 2.2.4 TCP Vegas TCP Vegas is based on the modification of TCP Reno, and three major modifications are congestion avoidance, fast retransmission and slow start in order to improve throughput and recover from segment loss more efficiently. The main difference between Reno and Vegas lies in how to estimate the available bandwidth. Reno treats the segment loss as an indicator of network congestion, while Vegas calculates the expected and actual throughput based on the measured round trip time to control transmitting rate. In TCP Vegas, a fine grained timer is used to record RTT for each segment that is sent out. TCP Vegas uses the average recorded RTT to accurately determine the amount of data segments 19 Chapter 2 TCP Fundamentals that the sender can send out. In the congestion avoidance phase, TCP Vegas tracks changes in the throughput (more precisely, changes in the sending rate) and adjusts the congestion window according to the following formula: cwnd + 1; diff< a/baseRTT cwnd = I cwnd; a/baseRTT < diff< §/baseRTT cwnd-\; diff>$/baseRTT diff = expect rate - actual rate > 0 by definition expect rate = data in transit/base RTT actual rate = (next sent sequence number - segment timed)/averageRTT where averageRTT is the currently observed average RTT, baseRTT is the minimal value of measured RTTs, and a and (3 are thresholds that determine the extra buffers the sender can take given the current condition in the connection path. By default, the respective values of a and p are fixed as 1 and 3. TCP Vegas also employs some other algorithms to differentiate itself from Reno. One is when a duplicate A C K is received, Vegas checks to see if the difference between the current time and the timestamp recorded for the relevant segment is greater than the time-out value. If it is, then Vegas retransmits the segment immediately without waiting for three duplicate A C K s . Another is during slow start. The increasing rate of the congestion window in a slow start phase is half of TCP Reno. The algorithm compares the throughput of the same congestion window to check whether the throughput is increasing or not. It is noteworthy that the Vegas slow-start scheme allows for the exponential growth of the congestion window only for every other RTT, which may degrade performance over satellite links due to the long delay. The throughput performance of TCP Vegas in wired networks has been investigated 20 Chapter 2 TCP Fundamentals widely, but this is not the case for satellite networks. It is shown [28, 29] that the performance of TCP Vegas is inferior to TCP Reno over long delay channels. In this thesis, we present simulation results to reveal the conditions of this disadvantage. A Network Simulator [30] is used as the simulation tool, which already implements the TCP Vegas mechanism. After carefully reviewing the code, we found there are some points that are not mentioned in the original TCP Vegas behavior proposed in [25]. Readers can refer to [31] for details. I present some important unconformable parts, which may be used to explain the sim-ulation results in the following chapters. When TCP Vegas enters congestion avoidance from a slow start, the congestion window shrinks one eighth. When TCP Vegas enters fast recovery stage, i f the segment is lost for the first time, the congestion window is cut only by one quarter instead of one half. If the segment is lost the second time or more, the congestion window is cut by one half. In some cases, a serious problem occurs when TCP Vegas resets its baseRTT. TCP Vegas resets its baseRTT when there is only one segment transferred in the last RTT or the calculated average RTT is less than the current baseRTT. When there are several segments lost in the same window, sometimes the reset causes baseRTT to change to a very small value. This problem may severely hurt the throughput because the actual RTT is much larger than baseRTT, and cannot open its congestion window. In the implementation of this thesis, we add another judgement when resetting baseRTT. We reset baseRTT only when the baseRTT is larger than the propagation delay, which is the major part of the overall delay. 21 Chapter 2 TCP Fundamentals 2.3 TCP Options Except for the S A C K option we introduced before, there are some other options which are defined by IETF. The IETF creates an informational standard that recommends which standard-ized TCP options should be used over satellite networks [32]. The options used by the source and destination have to be negotiated when the TCP connection is set up. Many of these can be applied to satellite networks. These options are as follows: • Window Scale [15]: TCP's protocol syntax originally only allowed windows up to the size of 64 kilobytes, which limits maximal goodput to roughly 1 Mbps. This value is insufficient for satellite bandwidth-delay products. The window scale option allows the effective size of the offered window to be increased to 30 bits by introducing a scaling factor, which significantly increases the amount of data which can be outstand-ing on a connection. This is particularly critical in the case of satellite links, which re-quire large windows to realize their high data rates. However, increased window size can result in sequence number wrap around. • Selective Acknowledgments (SACK) [18]: Selective acknowledgments allow for mul-tiple losses in a transmission window to be recovered in one RTT, significantly reduc-ing recovery time when the RTT is large. • Time Stamp [15]: Large round trip delay variables can yield inaccurate RTT estima-tions, which inevitably reduce the efficiency of TCP's loss detection mechanism. The proposed time stamp option solves this problem by associating a sender-side time stamp with each segment. The receiver echoes back these timestamps, and provisions are given for handling non-contiguous segments. The time stamp option is important 22 Chapter 2 TCP Fundamentals for TCP over satellite networks considering the large delay variability. The time stamp can protect against sequence number wraparound, which is a problem caused by win-dow scale option. • Larger Initial Window [17]: Since the slow start phase relies on the returning A C K to increase window size, there is a direct dependency between RTT and bandwidth effi-ciency. The IETF approved an experimental proposal [16] which is allowed to in-crease the initial value of the congestion window to four segments instead of one. • Path M T U Discovery [16]: This option allows the TCP sender to probe the network for the largest allowable message transfer unit (MTU). Using larger MTUs is more ef-ficient, and helps the congestion window to open faster in a long-delay environment. M T U can yield good benefit i f the maximal segment size is not known a priori. How-ever, some studies state that larger segments are more prone to corruption loss, so it maybe harmful to satellite link where the BER is considerable. • TCP for Transactions (T/TCP) [19]: The goal of T/TCP is allow each transactions, for example, each request/response sequence, to be efficiently perform as a single incarna-tion of a TCP connection. This reduction can be significant for short-lived connection over satellite networks. Using these options requires significant changes to both sender's and receiver's protocol suites. Some of the options require additional complexity and state information at the TCP layer, and so may not have been implemented, for example, on small embedded systems. Furthermore, some of these options are very hard to configure correctly on any given system. For example, the window scaling factor can only be negotiated at the connection setup when neither host has an estimate of the connection RTT; unless some additional mechanisms are used to determine the 23 Chapter 2 TCP Fundamentals RTT, the hosts can only guess at an appropriate scale factor. These options do not address some of the important problems pointed out in the previous section, such as the high penalties imposed by the congestion control algorithms for corruption-induced segment loss on connections using satellite channels. 24 Chapter 3 TCP Performance Enhancement Proxies for Sat-ellite Networks Chapter 2 introduced the methods to improve TCP performance in the context of TCP itself. However, the effectiveness of those solutions is limited by backward compatibility of current given systems. In this chapter we introduce another method: employ TCP performance enhancing proxies (PEPs), more specifically, split connection proxies, over satellite networks. We provide an overview of the modified Internet configuration and the concept, implementation requirement and interworking problem of the TCP PEP. Finally, we present the basic working algorithm of a random early detection (RED) queue. 3.1 A Modified Internet Architecture We have discussed that TCP performance degrades significantly over some specific network topology, such as those with a high BER, highly asymmetric, and high latency satellite link. Often these problems arise from inadequacies in the layered communication protocol suite; in many situations, each layer cannot function independently, but depends on other layers in a complicated way. For example, the transport layer may depend on link layer parameters, such as B E R and delay, or the network layer is affected by the stability of individual links, and so on. Even the application layer is not independent of the link layer, for instance, telnet applications require a short round trip time. If a network is homogeneous or nearly so, then layered protocol design yields efficient and good results. For example, Internet protocols work well in a terrestrial network with low or medium delay, low BER and low failure rates. However, a layered protocol design may perform poorly in a network with significantly different characteristics, this is the case in TCP over 25 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks satellite links. This observation suggests a way to modify the Internet for better performance: partition the network by proxies into parts that are homogeneous or nearly so, and apply the layered protocol design to each pair of proxies. Figure 3.1 shows this kind of modified architec-ture. N4 Figure 3.1 Modified system architecture. The proxies P[ to P 4 are located at the edge of different networks to perform protocol conversions. By employing a different protocol stack, these proxies isolate the host of H j through H 2 from special link-layer characteristics of N 5 . Proxies may use a proprietary protocol within N 5 to carry out some transport level function, and to perform a translation so that the changes are transparent to the end systems. For example, much TCP performance degradation arises from the interweaving of its error recovery and congestion control mechanisms, and the proxies may try to handle congestion control on a local basis, thus uncoupling these two schemes. One such kind of proxies is the performance enhancement proxy. 3.2 Performance Enhancement Proxy (PEP) 3.2.1 The Concept of PEP A PEP is used to improve the performance of Internet protocols on network paths where 26 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks native performance suffers from some characteristics of a link or subnetwork on the path [20]. The advantage of a PEP is that it acts on behalf of the end system without changing each end host configuration. At the same time, the proxy services are customized specifically for various characteristics of a link to compensate for poor performance. Both the link layer solution and end-to-end solution can be combined with this method to enhance TCP performance. In principle, a PEP implementation may function at any protocol layer, but in practice, a PEP most commonly functions at the application layer or transport layer. Those proxies operating at the application layer need to understand the context of specific application. Others operating at the transport layer or below, only deal with problematic link characteristics, and ignore the knowledge of how an application works. Table 3.1 summarizes the various proxy functions used to improve performance in wireless and satellite links [33 ] . Table 3.1 Performance enhancement proxy functions Proxy Type Functions Application Proxy Web caches, pre-fetching, relay mail transfer agents Content transformation Application protocol transfer (e.g. HTML<-> HDML) Transport Proxy TCP ACK handling (e.g. ACK spacing) Compression, header suppression TCP performance enhancement (e.g. split connection, spoofing protocol) Web caching and prefeching are two basic mechanisms for reducing access latency at the application layer. Reference [34] proposes to establish the collaboration between proxy clients and web severs so that cache coherence and prefeching mechanisms can be combined into one effective mechanism to reduce the number of requests, as well as the corresponding connection time. The Smart Proxy Approach (SPA) [35] is an example of installing a proxy server at both the sender and receiver to provide web service across satellite links. The SPA uses a sender proxy to 27 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks implement parsing, caching, and pre-fetching an HTTP document, and uses a receiver proxy to implement caching such a document. As a result, the web transfers achieve tremendous speed up. Most of the proxy functions at the transport layer are targeted for degraded TCP perfor-mance over a specific network topology. In heterogeneous networks, almost all TCP applications suffer similar shortcomings, which arise from the limitations of the TCP itself. In addition, TCP is the only end-to-end connection-oriented protocol used in the Internet. Thus, many proxy functions have been proposed to improve the TCP performance over lossy and slow wireless or satellite links. There are three main functions completed at the transport layer: A C K handling, compression and header suppression, and TCP performance enhancement proxy. A C K filtering [9], which smooths out the A C K flow in the reverse path, is an well-known A C K handling method to reduce burstiness of TCP segments due to back-to-back arriving of TCP A C K s . Another example of A C K handling is the snoop protocol [36], which caches TCP segments locally and retransmits the lost TCP segments locally i f necessary, thus improving the TCP performance over a lossy link. Payload or TCP/IP header compression [37] may be applied to individual packet to reduce the amount of traffic over networks. There are two kinds of TCP PEPs that are proposed in the literatures over satellite links: TCP spoofing proxies and TCP split connection proxies. The difference between TCP spoofing and TCP split connection proxies is shown in Figure 3.2. Although they both break the end-to-end semantic of TCP, spoofing proxies just locally acknowledge TCP segments in order to reduce the RTT for the sender perceived; while split connection proxies partition one TCP connection into multiple separated connections. Reference [38] shows that TCP spoofing benefits the large file transfers and the throughput from the sender's point of view. However, it shows that spoofing 28 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks allows data to accumulate at the "spoofer", creating a second bottleneck and increasing the number of dropped packets, thus degrading the overall TCP performance. In this thesis, we focus exclusively on the TCP split connection proxies, which is commonly used over satellite links. Hostl Satellite Gateway Host2 Hostl Satellite Gateway Host2 Hostl Satellite Gateway Host2 End to end TCP TCP spoofing TCP splitting Figure 3.2 Difference between TCP spoofing and TCP splitting. 3.2.2 TCP Split Connection The split TCP connection approach employs a PEP to partition an end-to-end TCP connection into satellite and terrestrial segments. The idea behind the split connection is to isolate the long propagation delay and lossy links from other well-behaved parts of the network, in a way transparent to applications. The terrestrial segment would conform to the standard TCP protocol to guarantee compatibility with all Internet hosts. Protocol stack used between proxies may be customized to match the features of a satellite link. Figure 3.3 illustrates the split connection architecture as applied to the networks via satellite. In this configuration, the satellite provides access to the wired Internet through the earth station Gj. Gj is a PEP, which interconnects the satcom network to the outside Internet network, and employs a full protocol stack for protocol conversion. Considering both economic and techni-cal issues, a number of very small aperture terminals (VSATs) are located at the customer 29 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks premises. The satellite hosts can be connected to the VSAT directly, as with H b or composed of a subnet, as with H 2 to H n . G E O satellite Satellite host's server Proxy G l )ther clients Wide-are a Internet Other servers Satellite host H2 Satellite subnet Figure 3.3 General system architecture. The end-to-end TCP connection between the server and satellite host is broken into two separate connections by the proxy The connection splitting is achieved by isolating the end hosts from characteristics of the satellite link through a proxy. For instance, having a proxy acknowledge data on behalf of remote hosts reduces the connection round trip time perceived by hosts. The use of such proxies allows the end hosts to implement very simple versions of TCP, as they only communicate over a relatively simple network. It also allows the proxy to optimize the data transfer, taking into account the nature of the satellite link. In this thesis, we consider two situations: (1), where multiple hosts connect to the Internet through a subnet satellite proxy G 2 ; and (2), where multiple satellite gateways compete for satellite links. A number of protocols adapted to satellite links are considered in earlier work. Reference 30 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks [39] employs a larger initial window and S A C K option to enhance TCP performance over the satellite link. Reference [40] uses TCP Reno enhanced with timestamp, window scaling and S A C K options on the satellite link. It also uses forward A C K (FACK) congestion control and an increased value for the initial window at the startup. Reference [41] introduces a congestion avoidance mechanism modified from TCP Vegas with a proposed send ahead mechanism to accelerate TCP throughput. However, these schemes are unable to distinguish between different reasons of packet loss because they are all based on the current TCP version. Another well-known proposal of TCP split connection is the satellite transport protocol (STP) [7], which is optimized for high latency, and asymmetric links with high error rates. STP can correctly differentiate between congestion packet loss and transmission errors. STP uses negative acknowledgement ( N A C K ) to speed up packet loss recovery. The main drawbacks of STP are that it requires a customized implementation that is incompatible with TCP implementations, and that it still needs to wait one RTT after a congestion is detected before the congestion control mechanism becomes effective. The architecture of the above methods employs either a dedicated satellite channel or terrestrial dial-up link on the reverse path. In this thesis, we contribute a new system model in which the reverse link is shared by a number of VSATs, which communicate with the satellite directly over a shared uplink. 3.3 Interworking The end-to-end TCP semantic is partitioned into two or three different TCP connections by PEPs, which are completely transparent to user applications. Therefore, there is no need to reconfigure any host on a network in order to take advantage of the enhancement, except for the proxy itself. The problem of interworking and the congestion control mechanism between satellite networks and terrestrial area should be handled. 31 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks Since a TCP source requires A C K s for clocking out new segments, we must ensure that the TCP source can receive a stream of A C K s i f the satellite link is not congested. In short, we want to decouple the A C K clock, which is supposed to provide flow control by representing the state of congestion in the network, from the link delay, which is a characteristic of the link. One way to do this is to have the proxy acknowledge data segments as soon as it receives one. TCP is running on the top of IP, which is a connectionless network protocol. The proxy implementation should be robust to routing changes and reordering of packets in the networks. One way to achieve this is to ensure the sequence numbers used by a TCP connection and its cascading TCP connections are identical. If this information cannot be acquired because of routing changes, the proxies should at least be capable of simply forwarding all subsequent packets on that connection. Therefore, TCP needs to establish synchronization at the moment a connection is set up. 3.3.1 TCP Set Up and Tear Down To meet the above requirements, the proxy may utilize the information carried by the S Y N segment to exchange sequence numbers. Similarly, proxies should preserve the port numbers as many services use them as an authentication mechanism. The proxy must not return a S Y N A C K to the host before the remote host has responded, in case the remote host is non-functional. Therefore, the proxy must only return a S Y N A C K after the remote host has accepted the connec-tion. A similar statement might be made about the FIN sent to indicate a half-duplex close on a connection. Suppose we want to set up a TCP connection between a satellite host's server and H l s as shown in Figure 3.3. The procedure used to perform connection splitting setting up and tearing down is illustrated in Figure 3.4. 32 er 3 TCP Performance Enhancement Proxies for Satellite Networks Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks Whenever the proxy Gj sees a connection request (i.e. a S Y N segment), it intercepts the request and originates a similar connection request with customized protocol or mechansims. When all downstream connections are completed, an acknowledgment (a S Y N A C K ) is returned to the host that originated the original request. Once the connection is set up, the proxy intercepts all data on that connection, returns an acknowledgment to the sender bearing the address of the destination, and buffers the data for downstream transmission. When a proxy receives a FIN segment, it forwards the FIN to the end host and waits for the A C K . When a FIN is received for both directions of a TCP connection, all the resources for the corresponding connection segments are freed to minimize resource usage. 3.3.2 Interworking Congestion Control As mentioned before, proxies acknowledge TCP segments locally. Thus, the end host does not perceive the long delay over the satellite network. However, i f this is not controlled properly, it raises another issue. The sender may clock out TCP segments so fast that they may consume too much buffer in the proxy. The simplest way to achieve flow control between satellite networks and terrestrial networks is to use a "back-pressure" mechanism. The method we employ uses TCP advertised window in A C K segments to control the upstream sending rate. Proxy maintains two buffers for each direction of a TCP split connection: transmit buffer and receive buffer. The transmit buffer stores data that is ready to transmit to the downstream or those has been transmitted but waiting for acknowledgments. When A C K s arrivals, those segments correctly received by destination are eliminate from transmit buffer. The receive buffer stores those out-of-order segments, or those in order segments come from the upstream waiting to be sent downstream when the transmit buffer 34 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks is full. We place a fixed constraint on the total size of these two buffers. Thus, the available buffer space shrinks when new segments arrive from the upstream, and opens when acknowledgments come from the downstream to free up the space. We record the available buffer size in the advertised window field of A C K segments' header to notify the upstream how much data it can send in maximum. When the traffic load of a satellite link is light, segments can be sent out in time, leading to the buffer is almost empty. As a result, the advertised window is large, and upstream TCP sender can speed up the data transmission. On the other hand, when satellite link is congested, TCP segments are backlogged in the transmit buffer, and accumulated in the receive buffer when transmit buffer is full. As a result, the advertised window is reduced, and upstream TCP sender has to slow down the data transfer accordingly. Through this method, congestion indications are propagated back to the sending host eventually. Server Proxy Upstream i 1 r Advertised Window i i i 1 Downstream Figure 3.5 Flow control between satellite networks and terrestrial networks 3.4 Random Early Detection Queue One of the novel features of our approach is that we deploy a random early detection (RED) queue at the proxy. The R E D queue algorithm can detect incipient congestion of the network and manage the queue in a more active manner. One of the main goals of the RED queue 35 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks is to simultaneously achieve high throughput and low average delay [42], and avoid global synchronization and bias against bursty traffic by controlling the average queue size. A n RED queue is characterized by a set of parameters, the most important ones being two thresholds: minth and maxlh, used to switch between different queue management algorithms. The RED queue also maintains an estimate of the average queue length, using a low-pass filter with an exponentially weighted moving average (EWMA), as shown below: avg = q_w • q_int + (1 - q_w) • avg where q_yv determines the time constant of the low-pass filter, q_int is the instantaneous queue length at the time measurement, and avg stands for the average queue length. In our implementation, we use a gentle RED algorithm [43]. When the average queue size is less than the minimal threshold minlh, no packet is marked. When the average queue length falls between the minth and maxth, the system randomly marks the incoming packets with the probabil-ity pa, until the maximal probability maxp is reached. It begins to randomly drop the incoming packets with increasing probability from maxp to 1.0 when the average queue length exceeds the maxlh, and is less than 2*maxth. When the average queue size is greater than 2*maxth, every arriving packet is dropped. The reasons for switching from marking to dropping packets at some point are for adding robustness in case there are misbehaving flows not using conformable end-to-end congestion control. That is, if a flow does not respond properly to marking, then it might drive the queue to high enough congestion levels, in which the system begins dropping packets rather than marking packets. Readers can refer to [44] for suggested values of these parameters. The probability of marking pb varies linearly from 0 to maxp, and the probability of 36 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks droppingpb varies linearly from maxp to 1.0, as shown in Figure 3.5. The final packet marking or dropping probability pa increases slowly since the last marked or dropped packets, which ensure that the gateway does not wait too long before marking a packet, using the formula listed below: pa<-pb/(\-count-pb) maxp min<h maxih 2xmax,h Average queue length Figure 3.6 The packet mark/drop probability of RED queue. where count define the number of packets since last marking or last dropping. If the marking is used to notify the congestion, the RED queue must be co-operative with senders and receivers that support Explicit Congestion Notification (ECN) [45]. If the receiver gets a marked TCP segment, it will echo back this mark by setting echo-flag in the header of the subsequent A C K s . When the sender receives these A C K s , it realizes that the network is congested, and cuts its window by one half. The original purpose of E C N is to detect the conges-tion in the network path and quench the sending rate of the TCP sender. It can partially differenti-ate the congestion loss and transmission error since it can get explicit congestion information. However, i f a packet is lost and TCP is not in the fast retransmit/fast recovery, or the E C N action 37 Chapter 3 TCP Performance Enhancement Proxies for Satellite Networks phase (ECN ensures the congestion window cut happened once per RTT), TCP wi l l cut its congestion window, even the packet loss is caused by transmission error. In this case, TCP cannot differentiate whether this packet loss is due to error or congestion. Therefore, the proposal in [46] exploits the implicit information provided by E C N to further distinguish the cause of packet loss. If one of the duplicate A C K s contains E C N , TCP assumes the packet loss is caused by congestion and cuts its congestion window. Otherwise, TCP assumes the packet loss is caused by transmis-sion error and keeps its congestion window. Another shortcoming of E C N is that it takes one RTT for the sender to react to the congestion, because the E C N needs to be echoed back by the receiver. The effectiveness of E C N over satellite networks is therefore limited due to the very long RTT, which can be more than 500 ms in GEO satellite systems. 38 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways In this chapter, we first introduce the system architecture with two gateways, which is widely studied in the literature [39, 40, 7]. Next, we describe the dynamic congestion control mechanism based on TCP S A C K proposed over a splitting connection scenario. Finally, we show the features of the proposed mechansims and compare the performance of our proposal with different TCP versions in a single flow case and multiple flows case through simulation. 4.1 System Architecture Figure 4.1 illustrates the system architecture we use in this chapter. The satellite network provides an intermediate link in the end-to-end connection. We consider a simple bent-pipe satel-lite that relays packets received from the uplink to the downlink without demodulation or error-checking. There are two gateways, each of them is located at the edge of the satellite network. The TCP split connection is achieved by configuring the gateway as a proxy for the remote host, thus isolating the host from the characteristics of the satellite link. When one of the end hosts requests to set up a TCP connection, its proxy intercepts this request and sets up a cascading TCP connec-tion for it over the satellite link to the opposite proxy, which in turn sets up another cascading TCP connection to the corresponding end host. The proxies are responsible for local acknowledgments and local retransmissions on behalf of end hosts over each of the terrestrial and satellite segment. The proposed dynamic TCP mechanism is applied to the proxies only. 4.2 Proposed Dynamic SACK Mechanism (DSACK) In the split connection scenario, the proxies act as both a virtual receiver and a virtual sender of the cascading TCP connections. Thus, they have access to local information concerning 39 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways Figure 4.1 Two-gateway system architecture, underlying queue conditions. We adopt the same algorithm as the RED queue, but use this infor-mation in a completely different way. By exchanging information locally between the TCP and MAC layers, the proxies can react to the RED marking and dropping immediately. Therefore, the proxies can control network congestion and prevent queue overflow much more efficiently with-out the long RTT delay. We use service primitives to exchange information between the TCP layer and MAC layer. Figure 4.2 shows the exchange procedure. To query the status of the underlying queue, the TCP layer sends a request message to the MAC layer, which then responses the value of average queue length. When a TCP packet is "marked" by the RED algorithm the MAC layer generate a congestion signal to notify the corresponding TCP layer. Because the "marking" is random, the signal will exist until TCP takes action, even the sequential packets are not marked by the RED algorithm. The TCP layer can clear this signal only after it takes appropriate actions. 40 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways Proxy Receive Buffer Transmit Buffer Clear i ^  Request Notification 1 i r i Response 1 maxlh m i n i h TCP Layer Queue M A C Layer Figure 4.2 Congestion control architecture. In detail, when a packet arrives at the queue, if it is marked by the probability determined from the RED queue algorithm (the probability calculation is shown in Section 3.4), the M A C queue generates a signal to the corresponding TCP layer. These congestion notification signals enable immediate feedback, which benefits the long-delay satellite link. Because TCP is ACK-clocking protocol, its window growth or reduction is done after receiving an A C K . When an A C K arrives, no matter it is a new A C K or a duplicate A C K , TCP first checks the congestion notification signal set by the M A C layer. In the presence of the conges-tion signal, TCP enquires the current average queue length. If average queue length is less than maxlh, it cuts its congestion window by one fourth; and if average queue length is larger than maxth, it cuts its congestion window by one half. When TCP cuts it congestion window, it records the maximin sequence number it send out to ensure it just cut once in single window of data even it receives more than one congestion signal. Otherwise, it allows its window to grow as in the original TCP mechanism. The congestion signals are the only reason for TCP to cut its congestion window. In this way, congestion control and error recovery schemes are separated. 41 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways We use table 4.1 to illustrate the event and the action taken. Table 4.1 Events and action. Events Action A TCP packet is "marked" by the RED queue. The congestion signal is generated. When TCP receives an ACK segment, (including new ACK or duplicate ACK) 1. TCP checks the congestion signal occur or not. 2. If not, increase the congestion window as original TCP scheme. 3. If the signal is present, send the request message to the MAC layer query the average queue length. If the average queue length is less than maxlh, cut the congestion window 1/4; otherwise, cut the congestion window 1/2. When the congestion occurs at the proxy, the congestion signal causes the TCP to slow down its transmission rate. The packets begin to accumulate in the transmit buffer. When the transmit buffer is full, the upstream incoming packets accumulate in the receive buffer. The adver-tised window size becomes smaller and smaller. Since the TCP congestion window is the minimal value of the congestion window and advertised window, upstream TCP source has to slow down its transmission rate eventually. Our proposal includes two important mechanisms: congestion control with immediate feedback and wireless error identification. In satellite networks, when the link error is high and multiple packet losses occur within one window of data, the throughput degradation is still large. We propose to adopt the TCP S A C K option for quick recovery from high link errors. We also adopt the window scale option to allow for a large window size in the satellite segment. We call the combined mechanism D S A C K . 4.3 Simulation Results The simulation in this thesis uses Network Simulator version 2.1b9a (NS2) [30]. The satel-lite network interface stacks and structure of satellite nodes are illustrated in Appendix B. We set 42 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways up the splittcpsink module, which is the receiver of the upstream TCP connection and forwards the data to the downstream TCP connection if the congestion window allows. The proposed D S A C K mechanism only applies to the satellite network segment. For split D S A C K and split SACK, two terrestrial network segments use the normal TCP Reno. The interworking problem is described in Section 3.3.2. The system configurations evaluated include a single TCP connection and multiple TCP connections between satellite hosts. In the single TCP connection scenario, we further demon-strate the advantage of the proposed mechanism through the TCP congestion window and under-lying queue occupancy. The TCP throughput is defined as the number of data bits received (not including TCP/IP headers), divided by the time used to finish the transmission. The file transport protocol (FTP) is used as the application data source. The simulation parameters are listed in the table below. Table 4.2 Simulation parameters for two-gateway model. Parameter Item Parameter Value Bandwidth for terrestrial link 10 Mbps Propagation delay for terrestrial link 50 ms Bandwidth for gateway over satellite 2 Mbps Propagation delay for satellite link 250 ms Packet length for downstream (including TCP/IP headers) 1024 Bytes Offered window size for terrestrial link 64 KB Offered window size for satellite link 32768 KB RED queue buffer capacity 125 packets Minlh for RED queue 5 packets Maxlh for RED queue 15 packets maxp for RED queue 0.1 q_w for RED queue 0.002 43 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways We simulate the TCP end-to-end SACK, where both end hosts support the S A C K option, and compare it with the split SACK, where the S A C K option is supported by the proxies only. The corresponding results are denoted as the end-to-end S A C K and split S A C K in the graphs. Results for the dynamic SACK, incorporating both the immediate feedback and error identifica-tion mechanisms, are denoted as the split D S A C K in the graphs. Table 4.3 Difference between three schemes. Difference End-to-end S A C K Split S A C K Split D S A C K End hosts use SACK option Y N N Proxies use the SACK option N Y Y Window scale option N Y Y ECN-capable end hosts Y Y N 4.3.1 Single Connection Case First, we compare the performance of different TCP versions and proposed mechanism with and without bit error. We further demonstrate the advantages of our proposed mechanism through the TCP congestion window, average RED queue length and the separation of the effect of two schemes: immediate feedback and error identification. Figure 4.3 shows the throughput of a single TCP connection versus the file size without bit error. A l l three curves show that the throughput is increasing with the file size because the impact of the slow-start is decreased. If the transmission is long, the slow-start only takes up a small part of the overall transmission time and most of the data is transmitted in the congestion avoidance phase, thus efficiently utilizing the available bandwidth. For the end-to-end SACK, the perfor-mance does not change much after the file size is larger than 1 M B due to the limited offered win-dow size (64K). Our split D S A C K significantly outperforms the split S A C K when file size is 44 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways larger than 100 K B ; in this case, the queue occupancy is too small for the congestion control mechanism to take effect. For example, when file size is 10MB, the throughput of the split D S A C K improves about 35% as compared to the split S A C K and improves about 138% as com-pared to the end-to-end S A C K . F i l e S i z e ( K B ) Figure 4.3 Throughput of single connection without bit error. Why and how does this happen? Figure 4.4 illustrates the congestion window comparison of these three schemes over the satellite segment when file size is 10MB. The figure is truncated at 70 seconds for the end-to-end S A C K . We can see that the end-to-end S A C K enters congestion avoidance too early due to the offered window size. It takes seventy seconds to reach the window size while the split S A C K and D S A C K only use several seconds. On the contrary, the split S A C K enters congestion avoidance too late. At this moment, the network is very congested and the average queue length reaches thirty, which is almost twice that of maxth. Thus, it has to cut its congestion window several times. The split D S A C K enters the congestion avoidance just at the time when the average queue length is a little larger than minth. This is the point where the 45 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways immediate feedback takes action. We can see this effect more clearly from Figure 4.5, which shows the corresponding average queue length. The average queue length overshoot for the split S A C K is three times more than the split D S A C K because of the long delay loop over the satellite link. This may also cause queue overflow when there are multiple flows transmitting at the same time. Dur ing the congestion avoidance stage, the congestion window o f the split D S A C K oscillates in a much smaller range than the split S A C K . This is because when the split D S A C K detects the incipient congestion, it cuts one fourth of its congestion window, while the split S A C K cuts one half, so its congestion window fluctuates within a big range. For most of the time, the average queue length of the end-to-end S A C K is kept at zero, which cannot fully utilize capacity. 5 o a> o> c o O 2 5 0 2 0 0 1SO 100 20 3 0 4 0 5 0 S i m u l a t i o n T i m e ( s ) Figure 4.4 Congestion window without bit error. We investigate the impact of different B E R s over the satellite channels to T C P perfor-mance. The file size used in the simulation is 10 M B . To evaluate individual impact, we run simu-lations for the immediate feedback mechanism and error identification mechanism separately. With immediate feedback, the congestion signal is generated as we discussed before, but T C P 46 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways 30 25 h E n d t o e n d S A C K S p i l t S A C K S p l i t D S A C K u c a 20 h u u O 15 a> 10 \ 5 O 10 20 30 40 S i m u l a t i o n T i m e (s) O 50 70 Figure 4.5 Average queue length without bit error, only checks the congestion signal when it receives a new A C K , and cuts the congestion window according to average queue length. If T C P receives a duplicate A C K , it enters fast transmit and fast recovery as usual and ignore congestion signals. We denote this scheme as the split immedi-ate feedback in the graph. In the error identification mechanism, T C P are ECN-capable and employs R E D queue. The E C N marks are echoed back after an R T T in the satellite segment. To account for the shortcomings of E C N (the shortcomings of E C N are described in Section 3.4), T C P cuts the congestion window in one half, if one of duplicate A C K s contains echo-flag. If non duplicate A C K contains echo-flag, T C P assumes the packet loss is caused by error and takes no action. This method is denoted as the split error identification. From Figure 4.6, we can see that the split S A C K is better than the end-to-end S A C K thanks to local retransmissions for error recovery. Even though the split S A C K can recover sev-eral packet losses within an RTT, the performance degrades sharply when the B E R reaches 10"6. On the other hand, the impact of the B E R on the D S A C K throughput is much smaller because it 47 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways can check the status of the underlying queue to distinguish between congestion loss and transmis-sion error. When the BER is IO"6, the split D S A C K is five times better than the split S A C K and more than seven and half times better than the end-to-end SACK. 2200-2000 -1800 -1600^ Jg- 140C;J-^ 1200-3 J= 100tfH 3 S aoo -. e i — 600 -4O0 -200 l V a 10"8 1 0 7 10"6 Bit Error Rate (BER) Figure 4.6 Impact of bit error rate on single connection throughput. We can see the effect of different mechanisms more clearly from the split Immediate Feedback and split Error Identification curves. Both of these mechanisms can improve TCP per-formance to some degree; however, their respective performance stays lower than the proposed DSACK. For example, the throughput of the split Immediate Feedback degrades significantly when the BER is higher than IO"8. When the BER is IO"6, the split Error Identification yields almost the same throughput as the split D S A C K , while the Immediate Feedback performs poorly. The reason that the Immediate Feedback offers little advantage at 10"6 B E R is easy to explain. Because the Immediate Feedback cannot distinguish a transmission error from congestion loss, it cuts its window continuously and makes the average queue length only exceed the minth once; this means the Immediate Feedback takes effect only once during the simulation. However, when the 48 - 0 - S p l i t D S A C K - O - S p l i t E r r o r I d e n t i f i c a t i o n S p l i t I m m e d i a t e F e e d b a c k - * - S p l i t S A C K Chapter 4 TCP Dynamic SACK for Networks with Two Gateways BER is as low as IO"8, the split Immediate Feedback can raise the throughput by about 34% as compared to the split S A C K . The Immediate Feedback keeps taking actions to prevent possible network congestion. In short, the performance of the split D S A C K is a result of the combined effect of these two schemes. Sometimes one scheme may dominate the whole result of the simula-tion. For instance, the Split Error Identification is more effective when the B E R is high. Figures 4.7 and 4.8 reveal more detailed information when the B E R is equal to 10~6. The figures are truncated at 160 seconds for the end-to-end S A C K and split S A C K . We can see that congestion windows of the end-to-end S A C K and split S A C K are kept at a very low level. This is because they cut their congestion windows continuously when they encounter packet loss, even i f they have just recovered from the last window of packet loss. Queue occupancy is also maintained at a very low level, except at the startup, as Figure 4.8 shows, and thus cannot fully utilize the available bandwidth. On the other hand, the split D S A C K can maintain its congestion window at a much higher level, and reduce its window only when congestion occurs at the networks. For these three schemes, time-out events are unavoidable when the retransmission packets are lost. 2 5 0 2 0 0 1 S O CO . _ _ o 100 cn c o O 5 0 i 1 1 E n d t o e n d S A C K S p l i t S A C K S p l i t D S A C K -1 1 1 1 t Si -- -h 1 2 0 4 0 6 0 8 0 1 0 0 S i m u l a t i o n T i m e ( s ) 1 2 0 1 4 0 1 6 0 Figure 4.7 Congestion window when BER=lO"6. 49 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways 30 E n d t o e n d S A C K S p i l t S A C K S p l i t D S A C K V O 5 O 140 160 Figure 4.8 Average queue length when BER=l0 6. 4.3.2 Multiple Connections Case Figure 4.9 illustrates the total TCP throughput versus the number of TCP connections over an error-free channel. The number of connections varies from 10 to 40. Each connection simulta-neously transmits a 200 K B file, which approximates the typical size of HTTP objects [47]. The general trend shows that the overall throughput improves with an increasing number of TCP con-nections. Note that owing to the immediate feedback, the packet losses in the split D S A C K due to congestion are much less than that of the split SACK. Therefore, the performance of the D S A C K is better than both the end-to-end S A C K and the split SACK. We completed similar simulations of the single flow case over a range of the BER from 10"6 to 10"9. The results for 20 TCP connections simultaneously transmitting 200 K B files are shown in Figure 4.10. Evidently, the proposed D S A C K method yields the highest throughput compared to the other two methods over the entire range of BER values, especially when the BER is high. For instance, when the BER is 10"6, the throughput of the split D S A C K is 28% higher than 50 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways 2000 1800 S p i l t D S A C K S p l i t S A C K E n d t o e n d S A C K 20 25 30 Number of C o n n e c t i o n s 40 Figure 4.9 Throughput of multiple connections without bit error. the split S A C K , and 36% higher than the end-to-end SACK. 1000 u 10 10 10 Bit Error Rate (BER) 10 Figure 4.10 Impact of bit error rate on multiple connections throughput. 51 Chapter 4 TCP Dynamic SACK for Networks with Two Gateways 4.4 Summary In this chapter, we have proposed a novel dynamic congestion control method for TCP split connection proxies applied to satellite networks. The mechanisms include an immediate feedback scheme to prevent queue overflow, which improves TCP performance over long-fat satellite channels, and an error identification mechanism to separate TCP's congestion control and error recovery operations, which improves TCP performance in the presence of transmission errors. The key feature of the DSACK is the local congestion notification signalling from the MAC layer to the TCP layer in the proxies based on current buffer occupancy. We presented simulation results to verify that the proposed DSACK offers significant improvements for TCP performance. 52 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway In this chapter, we first introduce a system architecture with a single gateway, in which a large number of very small aperture terminals (VSATs) share an uplink satellite channel using an appropriate medium access control (MAC) protocol. Then we describe the dynamic congestion control mechanism based on TCP Vegas proposed over a satellite link. Finally, we compare the performance of our proposal with different TCP versions and investigate the impact of reverse bandwidth, BER, traffic load, and underlying buffer capacity on TCP throughput. 5.1 System Architecture Considering the satellite link capacity is scarce and expensive for use as a thin route access technology for the Internet, a number of satellite hosts sharing a satellite channel is quite normal. Very small aperture terminals (VSATs) are designed for this purpose. VSATs can scatter to a large number of locations to access the same satellite channel. By the beginning of 1999, about 300,000 two-way VSATs were in operation throughout the world [48]. Figure 5.1 illustrates the system architecture of satellite-based Internet access. A number of VSATs are located at the subscriber premises, which enable end hosts to access the Internet via satellite. In order to efficiently share satellite bandwidth and avoid unnecessary collision, the VSATs employ a MAC protocol to access a shared uplink. In the split TCP configuration, one proxy sits at the gateway connecting the satellite network to local web servers or the global Internet, while the other proxy is located at each of the VSATs. When an end host wants to set up a TCP connection with the server, the gateway intercepts this request and set up a cascading TCP connection. The gateway is granted fixed bandwidth in a dedicated uplink channel, which is the 53 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway From VSAT to Satellite R Data R Data Minislot Data Slot F/D F/D F/D F/D F/D 250 ms R: Reservation F/D: Fixed or Demand Figure 5.2 Frame structure. requests are discarded for simplicity. Third, a packet on behalf of which a reservation is made may get transmitted even before its reservation is honored, either via a free assigned slot or via a demand assigned slot reserved by some antecedent packet of the same station. In order to fully utilize the precious bandwidth, each VSAT station keeps counting the number of reservations that are yet to be honored for it. The counter is incremented by the number of slots requested each time a reservation is made, and is decremented by one whenever it receives a demand assigned slot. Thus, the number of reservations made is equivalent to (packets queued in the station - value of counter). One important feature of the C F D A M A protocol is the access delay. The heavier the traf-fic load, the longer the time for end hosts to access the satellite channel. When traffic load is light, the access delay increases almost linearly. With the increasing traffic, the access delay rises sharply. The phenomena is more obvious when the number of hosts is large. Different from the two-gateway model, we have to take account this feature in the single gateway model. Both TCP Reno and TCP S A C K use the RTT in an implicit way while TCP Vegas uses the RTT as one of its controlling parameters, as discussed before. This is why we apply the dynamic congestion control 56 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway scheme to TCP Vegas. 5.3 Proposed Dynamic TCP Vegas Mechanism (DVegas) In the system topology in Figure 5.1, there are two bottlenecks in the satellite network. One is the downstream RED queue, and the other is the multiple access uplink shared by a number of VSATs. In the split connection scenario, the gateway acts as both end-points of the cascading TCP connections. Therefore, it has full knowledge of the conditions of the underlying queues. At the same time, TCP Vegas keeps an estimate of the RTT. Thus, we can utilize this information to optimize the throughput and delay more effectively. We use service primitives to exchange the information between the TCP layer and underlying layer. The exchange procedure is the same as we illustrated in Figure 4.2. The conges-tion signal generation and the action taken by TCP for TCP Vegas is the same as what DSACK does. Different from that approach, we use the following scheme to control RTT. TCP Vegas uses two thresholds, a and p, to control the congestion window. TCP DVegas dynamically adjusts these two thresholds according to both the average queue length and the observed RTT. In our approach, when the average queue length is less than the minth, and the ratio of averageRTT to baseRTT is less than 1.1, we increment a and P with factor (baseRTT/ averageRTT)/!. When the average queue length is larger than the maxth, or the ratio of averageRTT Xo baseRTT is larger than 1.2, we multiply a and p with factor (baseRTT/ averageRTT)/!. The lower bounds for a and p, 1 and 3, respectively, are the same as the default values in Vegas. This dynamic control of the congestion window is aimed at achieving both high throughput and low latency. 57 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway 5.4 Simulation Results We use Network Simulator version 2.1b9a [30] as the simulation tool. The satellite net-work interface stack and structure of satellite node are illustrated in Appendix B. As well as the splittcpsink module we mentioned before, we implement the C F D A M A protocol over the satellite link. Similar to before, DVegas is used only over satellite parts. We compare the performance of different TCP versions: TCP Reno, TCP SACK, TCP Vegas and the proposed TCP DVegas. The TCP versions we compared are all ECN-enabled to support RED queue. The implementation includes 100 VSATs at the customer side. The TCP throughput is defined as the received data bits divided by the simulation time. The table below list the simulation parameters used in the following experiment, except as otherwise noted. Table 5.1 Simulation parameters for one-gateway model. Parameter Item Parameter Value Bandwidth for terrestrial link 10 Mbps Propagation delay for terrestrial link 50 ms Bandwidth for gateway over satellite 6 Mbps Packet length for downstream (including TCP/IP headers) 1024 Bytes Packet length for upstream (including TCP/IP headers) 128 Bytes Propagation delay for satellite link 250 ms Bit error rate (BER) io- 7 RED queue buffer capacity 375 packets Minlh for RED queue 15 packets Max,h for RED queue 45 packets maxp for RED queue 0.1 q_w for RED queue 0.002 Simulation time 300 s 58 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway Because the implementation includes 100 TCP connections terminating at the VSAT side, long-live traffic is not suitable for this topology. We set up the following traffic to test the proposed mechanism. The server transmits a series of 200KB files with exponentially distributed waiting time between transmissions to each VSAT. This traffic model approximates WWW traffic [51]. The traffic load increases as the inter-arrival time is reduced. 5.4.1 Impact of Uplink Bandwidth We investigate the impact of the uplink bandwidth (from VSAT to proxy) on the TCP throughput as well as the round trip delay (satellite segment only). The downlink bandwidth (from proxy to VSAT) is 6 Mbps. The uplink bandwidth changes from 1Mbps to 6Mbps, and the RED buffer capacity is increasing accordingly, which is equal to the bandwidth-delay product (the delay used here is propagation delay, which is the dominant in satellite communications). In addi-tion, the thresholds for the RED queue are proportionally increasing. For example, when the uplink bandwidth is 2Mbps, the buffer capacity is equal to 125 packets and the minth and maxth is 5 and 15 packets, respectively. If the uplink bandwidth is 4Mbps, the buffer capacity is equal to 250 packets, and the minlh and maxth is 10 and 30 packets, respectively. The inter-arrival time between each file transmission is 20 seconds. Figures 5.3 and 5.4 show the TCP throughput and RTT delay. The throughput of the four schemes degrade significantly when the uplink bandwidth is less than 3Mbps because TCP Reno and SACK cannot get enough ACK to open their congestion window as soon as possible. There is a trade-off when bandwidth is only 1Mbps. TCP DVegas and Vegas sacrifice throughput for low RTT, while TCP Reno and SACK keep their throughput but their RTT is raised sharply. This is because TCP Vegas and DVegas use the RTT as a parameter to control their window growth. 59 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway Except for this point, the throughput performance of DVegas is 14% better than Reno, and 7% better than TCP Vegas. The RTT for DVegas is a little bit higher than Reno and SACK when bandwidth is larger than 4Mbps because the ratio between averageRTT to baseRTT is less than 1.2. Thus, the ratio does not take action to reduce thresholds of a and p. 5 6 0 0 5 4 0 0 5 2 0 0 5 0 0 0 4 8 0 0 4 6 0 0 4 4 0 0 i 4 2 0 0 ' 4 0 0 0 3 8 0 1 -0- DVegas O Vegas - # - SACK •H— Reno 2 . 5 3 3 . 5 4 4 . 5 Uplink Bandwidth (bps) 5 . 5 6 X 1 0 B Figure 5.3 Impact of VSAT uplink bandwidth on throughput. en a. .a 3 O 0 . 9 0 . 8 5 . 0 . 7 5 0 . 6 5 0 . 5 5 2 . 5 3 3 . 5 4 4 . 5 U p l i n k B a n d w i d t h ( b p s ) DVegas - © - Vegas SACK Reno 5 . 5 6 6 X 1 0 Figure 5.4 Impact of VSAT uplink bandwidth on round trip delay. 60 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway 5.4.2 Impact of Controlling Parameters on RTT TCP DVegas sacrifices throughput for low RTT because TCP DVegas uses the RTT explicitly as a controlling parameter. We run the simulation to investigate its effect on TCP throughput and round trip delay. The first mechanism used is the same as TCP DVegas, except that the change of thresholds a and p is only according to the average queue length of the RED queue, no matter how the RTT changes; we call this DVegas-NC. The second mechanism used is the same as TCP DVegas except that the ratio to change thresholds a and p is modified from 1.1 and 1.2, respectively, to 1.05 and 1.15; we call this DVegas-rttl.05, which is tighter than what we used in the above situation. The third one is the DVegas we have described before; we called it DVegas-rttl.l. Figures 5.5 and 5.6 present the simulation results of throughput and RTT with different RTT control parameters. The RTT for three schemes become smaller with the increasing of uplink bandwidth because more slots are available for them to transmit ACKs. We can see that DVegas-NC achieves highest throughput and highest RTT, especially when uplink bandwidth is limited. DVegas-rttl.05 and DVegas-rttl.l show no difference when bandwidth is 1 and 2Mbps. This is because compared to the RTT control parameter, the minth and maxth may dominate the changing of a and p. After this point, the values of minth and maxth become larger, and the RTT control parameter takes action. From this simulation scenario, we can see that the proposed mechanism is very flexible for using over a satellite link. If delay is the main concern, some throughput can be sacrificed to achieve low delay. If throughput is the main concern, one can achieve higher throughput with a larger RTT. 61 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway 0.95 Figure 5.6 Impact of RTT controlling parameter on round trip delay. 62 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway 5.4.3 Impact of Traffic Load We investigate the effect of traffic load on TCP throughput. The following simulation is done under the condition that all parameters are the same as in Table 5.1. The interarrival time for transferred files ranges from 40 seconds to 15 seconds, and VSAT uplink bandwidth is 6Mbps. When the load is heavy, TCP DVegas, Vegas and S A C K outperform TCP Reno, as Figure 5.7(a) shows. This is because TCP Reno needs more time to recover from dropped packets, while S A C K can recover quicker using selective A C K . TCP Vegas drops only half the packets com-pared to Reno due to congestion, and the immediate feedback mechanism in DVegas results in very few dropped packets. Table 5.2 shows that the number of packets has been dropped for each situation. When the load is light, TCP Vegas is worst due to its conservative congestion control mechanism, that is, a double slow start, and small thresholds a and p. In short, TCP DVegas per-forms well over all traffic loads, and is especially robust when traffic is heavy. . Table 5.2 Number of packets dropped. TCP 15 s 20 s 25s 30 s 35 s 40 s Reno 3099 1536 982 429 308 567 Sack 2947 1511 1511 903 551 616 Vegas 1590 86 0 0 0 0 DVegas 12 0 0 0 0 0 5.4.4 Impact of Buffer Capacity We compare TCP throughput on different RED buffer capacities and different thresholds. This time we run the simulation when the RED buffer capacity is 125 packets, and the minth and maxlh is 5 and 15, respectively. Compared with Figure 5.7(a), although the throughput of all four mechanisms degrade 63 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway slightly, as shown in Figure 5.7(b), the throughput of TCP Reno and SACK is more sensitive to the underlying buffer capacity than TCP Vegas and DVegas. For instance, when the interarrival time is 15, TCP SACK degrades about 2.5% while TCP DVegas only degrades about 1.3%. 5.4.5 Impact of BER We test the impact of the BER on TCP performance in a scenario where 20% of the VSATs experience 10"6 BER, while the rest experience 10"7 BER. The other simulation parameter is the same as the Table 5.1. Compared to Figure 5.7(a), Figure 5.7(c) shows that the overall throughput does not suffer much degradation due to the adaptive congestion mechanism of TCP. Other TCP connections take bandwidth from those suffering degradation. However, Figure 5.8 shows that the proposed DVe-gas significantly improves the performance of those TCP connections suffering from a higher error rate. Because DVegas separates the mechanism of congestion control and error recovery, those who suffer a higher BER can still achieve the high throughput if the network is not con-gested. Vegas is better than Reno because Vegas just cuts its window by one fourth if the packet is lost for the first time, as we mentioned before. We put these three figures together for comparison. 64 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway 6 0 0 0 D V e g a s V e g a s 2 5 3 0 I n t o r a r r i v a l T i m e ( s ) (a) Impact of traffic load on throughput (buffer capacity = 375) 4SOO O D V e g a s O V e g a s —*— S A C K I S 2 6 3 0 I n t e r a r r i v a l T i m e ( s ) (b) Impact of buffer capacity on throughput (buffer capacity = 125) 6 0 0 0 £ jfl 4 0 0 0 D V e g a s V e g a s 2S 3 0 I n t e r a r r i v a l T i m e (a ) (c) Impact of bit error rate on overall throughput (where 20% VSATs are experienced BER=106) Figure 5.7 Impact of traffic load, buffer capacity and bit error rate on throughput. 65 Chapter 5 TCP Dynamic Vegas for Networks with Single Gateway 1 2 0 0 r 1 1 0 0 -Q. 1 0 0 0 -JQ , • — a. 9 0 0 = — cn 3 O 8 0 0 -1— 7 0 0 -6 0 0 -5 0 0 L O DVegas O Vegas - * - SACK Reno 15 20 25 30 Interarrival T i m e (s) 35 40 Figure 5.8 Impact of bit error rate on the throughput (BER=106). 5.5 Summary This chapter presents the simulation results of the proposed mechanism as compared to other widely used TCP versions in all kinds of network scenarios. The results show that TCP DVegas is a simple, efficient and flexible mechanism over satellite networks. Its scheme is easy to implement even when the end hosts are not ECN-capable nodes. The performance of DVegas outperforms other TCP versions in almost all cases shown. The flexibility of the proposed mechanism lies in that it can achieve high throughput or low round trip time through adjusting parameters. 66 Chapter 6 Conclusion and Future Work Performance enhancement proxies draw considerable interest from the network community as an effective approach to improve TCP performance over the satellite link and wireless link. In this thesis, we demonstrated the feasibility of implementing a transparent split connection proxies over a geostationary satellite link to enhance TCP performance. Such proxies are easy to incorporate into existing networks and improve the performance of existing TCP implementations by a large factor in the presence of a satellite link. This thesis focuses on the performance evaluation of TCP Reno, TCP SACK, TCP Vegas and proposed dynamic congestion control mechanism. It also studies the effect of traffic load, bandwidth asymmetry, bit error rate and TCP parameters on TCP performance. 6.1 Summary of Findings A dynamic TCP congestion control method, which mitigates TCP's shortcomings while keeping its merits, is proposed for split connection proxies over satellite networks. The novel mechanisms include an immediate feedback scheme to prevent network congestion, which benefits long latency channels, and an error identification scheme to uncouple TCP's congestion control and error recovery operations, which benefits error-prone channels. Simulation results show that the proposed mechanism is efficient, flexible, and easy to implement over satellite networks. Compared to RED queue, the dynamic congestion control scheme can achieve better performance, and reduce the complexity of network configuration. The throughput performance of different TCP implementations in network with satellite links interconnected with Internet has been thoroughly analyzed and compared. In the two-gateway environment, we confirm that split connection is significantly beneficial to long-live 67 Chapter 6 Conclusion and Future Work traffic without bit error rate. However, in presence of the serious error rate, it can not utilize bandwidth efficiently because TCP throughput oscillates with the congestion window. The proposed mechanism, which separate error recovery from congestion control, solves this problem effectively and achieves five to seven times throughput improvement. We also contribute a new system architecture, single gateway model, for multiple subscribers to access the shared satellite channel by employing a MAC protocol, CFDAMA. Under this model and the proxies, the performance of the different TCP versions under different traffic loads are investigated to reveal their advantages and disadvantages. We also investigated the impact of asymmetric bandwidth and different BERs on TCP performance over satellite links. The results obtained from testing the proposed mechanism show significant throughput improve-ments under a wide range of conditions. The simulation results show that the dynamic congestion control method is robust when traffic load is heavy. 6.2 Future Work Our proposed mechanism can be employed not only in GEO satellite networks, but also in any network that benefits from the deployment of the split connection or cascading TCP, such as LEO satellite networks, cellular or ad-hoc wireless networks. Because GEO satellite networks have some special characteristics, such as the long-fat channels, many of the new features we proposed in this thesis are aimed to attack these problems. However, other networks with proxies may have quite different characteristics. For example, the wireless channels in cellular or ad-hoc wireless networks would not have such a long delay, but they may encounter a much higher BER. Thus, our mechanism needs further modification to adapt to them, which can be done in future research work. 68 Chapter 6 Conclusion and Future Work Recent months have been increasing deployment of next-generation Internet protocols such as IPSEC and IPv6 in the Internet. These protocols change some of the characteristic of Internet traffic, and some of the information available to network nodes about end-to-end traffic. The impact of these changes on proxy architectures is also an important aspect for future study. 69 Bibliography [1] H. D. Clausen and B. Nocker, "Internet services via direct broadcast satellites," IEEE Int'I Performance, Computing and Communications Confi, pp. 468-475, Phoenix, Feb. 1997. [2] R. C, Durst, G. J. Miller and E. J. Travis, "TCP extensions for space communications," Proc. 2ndACM/IEEE MobiCom Conf, pp. 15-26, Nov. 1996. [3] C. Partridge and T. J. Shepard, "TCP/IP performance over satellite links," IEEE Network, vol. 11, no. 5, pp. 44-49, Sept.-Oct. 1997. [4] J. S. Stadler and J. Gelman, "Performance enhancement for TCP/IP on a satellite channel," IEEE Proc. MILCOM98, vol. 1, pp: 270-276, Boston, Oct. 1998. [5] C. Barakat, E. Altman and W. Dabbous, "On TCP performance in a heterogeneous network: a survey," IEEE Communications Magazine, vol. 38, no. 1, pp. 40-46, Jan. 2000. [6] Allman et al., "Ongoing TCP research related to satellite," RFC 2760, Feb. 2000. [7] T. R. Henderson and R. H. Katz, "Transport protocols for Internet compatible satellite network," IEEE Journal on Selected Areas in Communications, vol. 17, no. 2, pp. 326-344, Feb. 1999. [8] M. Filip and E. Vilar, "Optimum utilization of the channel capacity of a satellite link in the presence of amplitude scintillations and rain attenuation," IEEE Transactions on Communications, vol. 38, no. l,pp. 1958-1965, Nov. 1990. [9] H. Balakrishnan, V. Padmanabhan and R. Katz, "The effects of asymmetry on TCP performance," Proc. 3rdACM/IEEE MobiCom Conf, pp. 77-89, Berkeley, Sept. 1997. [10] W. R. Stevens, TCP/IP Illustrated Volume 1- The protocol, Addison-Wesley, Reading, MA, Oct. 2000. [11] R. Goyal et al, "Traffic management for TCP/IP over satellite ATM networks," IEEE Communications Magazine, vol. 37, no. 3, pp. 56-61, Mar. 1999. 70 Bibliography [12] M . Allman et al, "An application-level solutions to TCP's satellite inefficiencies," Proc. Is' Int'I. Workshop Satellite-based Information Services, Rye, Nov. 1996. [13] T. V. Lakshman and U . Madhow, "The performance of TCP/IP for networks with high bandwidth-delay products and random loss," IEEE/ACM Transactions on Networking, vol. 5, no. 3, pp: 336-350, Jun. 1997. [14] D. A . Eckhardt and P. Steenkiste, "Improving wireless L A N performance via adaptive local error control," Proc. 6th Int'l Conf on Network Protocols, pp. 327-338, Austin, Oct. 1998. [15] V. Jacobson, R. Braden and D. Borman, "TCP extensions for high performance," RFC 1323, May 1992. [16] J. Mogul and S. Deering, "Path M T U discovery," RFC 1191, Nov. 1990. [17] M . Allman, S. Floyd and C. Partridge, "Increasing TCP's initial window," RFC 2414, Sept. 1998. [18] M . Mathis, J. Mahdavi, S. Floyd and A. Romanow, "TCP selective acknowledgment options," RFC 2018, Oct. 1996. [19] R. Braden, "T/TCP—TCP extensions for transaction, functional specification," RFC 1644, Jul. 1994. [20] J. Border, M . Kojo, J. Griner, G. Montenegro and Z. Shelby, "Performance enhancing proxies intended to mitigate link-related degradations," RFC 3135, Jun. 2001. [21] M . Allman, V. Paxson and W. Stevens, "TCP congestion control," RFC 2581, Apr. 1999. [22] Floyd, S. and T. Henderson, "The NewReno modification to TCP's fast recovery algorithm," RFC 2582, Apr. 1999. [23] V. Jacobson, "Congestion avoidance and control," Computer Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988. 71 Bibliography [24] V. Jacobson, "Modified TCP congestion avoidance algorithm," end2end-interest mailing list, ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail, Apr. 30, 1990. [25] L. S. Brakmo and L. L. Peterson, "TCP Vegas: end to end congestion avoidance on a global Internet," IEEE Journal Selected Areas in Communications, vol. 13, no. 8, pp. 1465-1480, Oct. 1995. [26] K. Fall and S. Floyd, "Simulation-based comparisons of Tahoe, Reno, and SACK TCP," Computer Communication Review, vol. 26, no. 3, pp. 5-21, Jul. 1996. [27] R. Bruyeron, B. Hemon and L. Zhang, "Experimentations with TCP selective acknowledgment," Computer Communication Review, vol. 28, no. 2, pp. 54-77, Apr. 1998. [28] S. Horan and R. Wang, "Internet-type protocol testing in a simulated small satellite environment," Proc. IEEE Aerospace Conf, vol. 2, pp. 977-989, Big Sky, Mar. 2001. [29] Y. Thing, E. Yan, and S. K. Dao, "A measurement of TCP over long-delay networks," Proc. ofINFOCOM'99,pp. 1556-1563, New York, Mar. 1999. [30] The Network Simulator ns-2, http://www. isi.edu/nsnam/ns. [31] U. Hengartner, J. Bolliger and T. Gross, "TCP Vegas revisited," 19th Annual Joint Conf. of IEEE Computer and Communications Societies, vol. 3, pp. 1546-1555, Tel Aviv, Mar. 2000. [32] M. Allman, D. Glover, and L. Sanchez, "Enhancing TCP over satellite channels using standard mechanisms," RFC 2488, Jan. 1999. [33] Z. Jiang, L. F. Chang, B. J. J. Kim and K. K. Leung, "Incorporating proxy services into wide area cellular IP networks," IEEE WCNC 2000, vol. 1, pp. 246-252, Chicago, Sept. 2000. [34] J. Q. Li, Z. X. Wang, D. Zeng and F. Y Wang, "Combined coherence and prefetching mechanisms for effective web caching," IEEE Int'I Conf. on Systems, Man, and Cybernetics, vol. 5, pp. 3034-3038, Tucson, Oct. 2001. 72 Bibliography [35] A. Chrungoo, V. Gupta, H. Sarari and R. Shorey, "Smart proxy: reducing latency for HTTP based web transfers across satellite links," IEEE Int'I Conf. on Personal Wireless Communications, pp. 572-576, Hyderabad, Dec. 2000. [36] H. Balakrishnan, S. Seshan, E. Amir and R. Katz, "Improving TCP/IP performance over wireless networks," Proc. Is' ACM MobiCom conf, vol. 1, pp. 711-718, Berkeley, Nov. 1995. [37] C. Chi, J. Deng and Y.H. Lim, "Compression proxy server: design and implementation," Proc. of 2nd USENIX Symposium on Internet Technologies and Systems, pp. 105-116, Berkeley, Oct. 1999. [38] J. Ishac and M. Allman, "On the performance of TCP spoofing in satellite networks," IEEE MILCOM, Communications for Network-Centric Operations: Creating the Information Force, vol. 1, pp. 700-704, McLean, Oct. 2001. [39] M. West and S. McCann, "Improving TCP performance over long-delay and error-prone links," IEE Seminar on Satellite Services and the Internet, pp. 1-9, 2000. [40] V.G. Bharadwaj, J.S. Baras, and N. P. Butts, "An architecture for Internet service via broadband satellite networks," International Journal of Satellite Communications, vol. 19, pp. 29-50, Jan.-Feb. 2001. [41] T. Hasegawa, T. Hasegawa, Y. Miyake and K. Nakao, "TCP Gateway for satellite-based Internet service accommodating multiple subscribers," Proc. IEEE WCNC'02, vol. 2, pp. 849-854, Orlando, Mar. 2002. [42] S. Floyd and V. Jacobson, "Random early detection gateways for congestion avoidance," IEEE/ACM Transactions on Networking, vol. 1, no. 4, pp. 397-413, Aug. 1993. [43] S. Floyd, "Recommendation on using 'gentle_' variant of RED," http://www.ciri.org/floyd/ red/gentle.html, Mar. 2000. [44] S. Floyd, "RED: discuss of setting parameters," http://www.ciri.org/floyd/ REDparameters.txt, Nov. 1997. 73 Bibliography [45] K. Ramakrishnan and S. Floyd, "A proposal to add explicit congestion notification (ECN) to IP," RFC 2481, Jan. 1999. [46] R. Ramani and A. Karandikar, "Explicit congestion notification (ECN) in TCP over wireless network," 2000 IEEE Int'I Conf. on Personal Wireless Communications, pp. 495-499, Hyderabad, Dec. 2000. [47] N. Guo, "WWW service in 3G wireless CDMA systems," 1999 IEEE Radio and Wireless Conf, pp. 137-140, Denver, Aug. 1999. [48] N. Abramson, "Internet Access Using VSATs," IEEE Communications Magazine, pp. 60-68, Jul. 2000. [49] T. Le-Ngoc and J.I. Mohammed, "Combined free/demand assignment multiple access (CFDAMA) protocols for packet satellite communication," Proc. of 2nd IEEE Int 7 Conf. on Universal Personal Communications, vol. 2, pp. 824-828, Ottawa, Oct. 1993. [50] RD Mitchell, T.C. Tozer and D. Grace, "Improved medium access control for data traffic via satellite using the CFDAMA protocol," IEE Seminar on Broadband Satellite: The Critical Success Factors Technology, Service and Markets, pp. 18/1-18/7, London, Oct. 2000. [51] E. Anderlind and J. Zander, "A traffic model for non-real-time traffic in wireless radio networks," IEEE Communications Letters, vol. 2, pp. 37-39, Mar. 1997. [52] K. Fall (Editor) and K. Varadhan (Editor), The ns Manual, The VINT Project, Jan. 2002. 74 Appendix A. List of Abbreviations and Acronyms ACK: ACKnowledgment ARQ: Automatic Repeat reQuest BER: Bit Error Rate CFDAMA: Combined Free/Demand Assignment Multiple Access DAMA: Demand Assignment Multiple Access DSACK: Dynamic Selective ACKnowledgment DVegas: Dynamic Vegas ECN: Explicit Congestion Notification FACK: Forward ACKnowledgment FEC: Forward Error Correction FTP: File Transport Protocol GEO: Geostationary Earth Orbit HTTP: HyperText Transfer Protocol IETF: Internet Engineering Task Force IP: Internet Protocol 75 Appendix A. List of Abbreviations and Acronyms LEO: Low Earth Orbit MAC: Medium Access Control MTU: Message Transfer Unit NACK: Negative ACKnowledgement OBP: On-Board Processing PEP: Performance Enhancement Proxy RED: Random Early Detection RTO: Retransmission Time Out RTT: Round Trip Time SACK: Selective ACKnowledgment SNR: Signal to Noise Ratio SPA: Smart Proxy Approach STP: Satellite Transport Protocol TCP: Transmission Control Protocol T/TCP: TCP for Transactions UDP: User Datagram Protocol 76 Appendix A. List of Abbreviations and Acronyms VSAT: Very Small Aperture Terminal W W W : World Wide Web 77 Appendix B. NS2 Simulation Models This appendix shows the satellite network interface stack and structure of satellite node [52]. from routing agent to Node -> entry I M Sat/Recv to SatChannel from SatChannel Figure B.l Network interface stack. 78 Appendix B. NS2 Simulation Models class SatNode: public Node SatPosition LinkHandoffM SatTrace List of pointers: nodehead nodehead_ linklisthead linklisthead channel* uplink_ channel* downlink Other link objects Other link objects Figure B.2 Structure of class SatNode. 79 

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-0065348/manifest

Comment

Related Items