This action might not be possible to undo. Are you sure you want to continue?
This document is mainly about the influence of protocols on the performance of Satellite Communication. It is widely recognized that satellite communications are affected by some peculiar problems, which penalize heavily the performance and efficiency of the Transmission Control Protocol (TCP). In fact, wireless satellite channels are usually characterized by link-asymmetry and higher Round Trip Time and Bit Error Rate in comparison to wired links. It means that TCP, which was developed for wired channels, exhibits often poor performance in a satellite scenario (unfair bandwidth repartition, low throughput and long file-transfer delay). We will study and compare many TCP variants recently proposed. In particular we will compare TCP-Reno standard implementation with TCP-SACK, TCP-Westwood, TCP-Vegas and TCP-Tibet. We will test the different protocols on a simulated satellite scenario, with the support of NS2, a well-know network simulator platform, annotating the advantages and drawbacks of various protocols in order to improve the transmission of IP data packets over satellite channels.
Keywords: Satellite link, Performance analysis, TCP behaviors.
The use of satellites for Internet traffic is a very attractive proposition since the wired network is highly congested. On the average, any IP flow needs to travel through 17 to 20 nodes, and hence may go across multiple bottlenecks. On the other hand, with satellites, just one hop is sufficient to connect two very distant sites. Unfortunately, the use of satellite is limited by the poor performance obtained by usual TCP/IP suite protocols. In fact the long propagation delay of satellite channel has the same effect of traveling through various bottlenecks affecting the congestion control scheme of many connection oriented protocols, which erroneously underestimate the bandwidth available on the link and assume to be in a congestion state. Moreover, in the future communication system, the satellite component is supposed to be integrated with the terrestrial component  and the interaction of satellite and terrestrial connections brings new performance problems which are actually partially unexplored and not completely solved. Satellite communication needs to be completely integrated in the actual communication system without technical handicaps, if it wants to assume a particularly important role, and not only complementary, in the future communication world, especially if aiming at real global coverage and ensuring access to maritime, aeronautical and remote users.
The main goal of this project is to evaluate the performance of typical mobile Internet applications, using different TCP schemes. While high efficiency on fast satellite links may eventually require the introduction of a new protocol, many studies  indicate that full link utilization may be achieved by using the TCP performance enhancements that have already been approved or that are currently in the standards process. Of particular interest in the satellite environment are performance enhancements for scaled windows and timestamps, fast retransmit and recovery, and selective acknowledgement. This paper describes the protocols which adopt these performance enhancements and show the effects of their implementation on increasing TCP‟s performance over satellite links.
.We analyze some representative satellite scenarios with a classical GEO configuration satellite repeater.
very reliable links can be provided even with small terminals. for enhancing coverage of existing or developing land mobile systems and to ensure long-range mobility and large bandwidth.Literature survey THE ROLE OF SATELLITES: In the future. . The broadcast nature of the satellite channel also makes satellites suitable for broadcasting/multicasting. plane or ship). are based on a geosynchronous orbital configuration. In this way. The satellite may also be integrated with short-range wireless networks (Bluetooth) in order to provide Internet services to mobile vehicles. in order to guarantee a complete control of mission evolution. In this scenario. Besides the satellite is the only way for extending the range of communication out of our planet connecting space stations and space shuttles in a future interplanetary communication network. satellites will play an important role in providing wireless access to mobile users. providing large bandwidth directly to users. The presence of satellite links provides extra capacity and an alternate and less congested route to existing wired and wireless systems. The growing interest in exploring new worlds needs an affordable and performing system of communication for granting the success of space missions. Such GEO systems provide (or are designed to provide) high availability high data rate links (up to 2 Mbit/s and more) and huge total capacity (of the order of 10 Gbit/s). bus. The main satellite communication systems. A single GEO satellite is able to cover a very wide area with multiple narrow spot beams using multibeam antennas. Many of them are expected to provide regional limited coverage in a few years and global coverage (excluding poles) finally. thus offering unique opportunities for improving efficiency and reliability. the satellite will connect one vehicular terminal to the Internet while the Bluetooth system will be able to interconnect equipment inside the vehicle (car. train.
The key satellite network features that need to be considered in order to evaluate the impact of satellite on internet application performance are: propagation delay. Delay. where a large TCP window is required for efficient use of the satellite link. we also address other TCP schemes (Westwood  and Tibet) and evaluate TCP performance when terrestrial and satellite TCP connection share the same bottleneck in order to establish which protocol has the better behaviour when used for both long and short Round Trip Time (RTT) connection.Previous works [8-12] has addressed the performance of TCP/IP over geostationary satellites.g. signal-to-noise ratio (SNR). where the connection between two fixed stations goes across a GEO satellite. In this process each satellite is an element of a network. besides we exposed both type of connections to the aggressive behavior of a UDP flow to evaluate the ability to conserve their throughput. This has mainly focused on evaluating performance of different TCP schemes (Tahoe. Reno. routing strategy. when considering the performance of real time (e. and new design problems are involved both at the network and the transport layers. The problem is particularly relevant to TCP due to its delay-sensitive nature. While considering the performance of standard Internet protocols over paths including satellite links. the delay may be critical. Satellite systems are changing their role from the “bentpipe” (transparent) channel paradigm to the “onboard routing” (regenerative) paradigm associated with packet transmission and switching. Some of the main aspects that need to be . For voice and other real time applications too. Such an environment creates a very realistic scenario for the evaluation of performance in a satellite environment. SATELLITE FEATURES AFFECTING PERFORMANCE OF IP APPLICATIONS First. In this paper. with significant impact on throughput. The problem is particularly acute in TCP applications over links with large bandwidth-delay products. the large propagation delays have to be taken into account. New Reno. voice and video) applications the large propagation delays represent a critical issue.Bandwidth Product (DBP). A lossy satellite link can cause frequent “slow start” events. SACK). satellite diversity.
The delay variability is particularly relevant to TCP. 11].considered in order to evaluate the impact of system architecture on the performance of network protocols are: Propagation delay: Due to the large distance that packets need to travel in satellite networks. This delay can be considered constant in the caseof fixed users while it is variable in the case of mobile users. This phenomenon is even more critical if ISLs are implemented. splitting and cascading may be used . or on the connection strategy if ISLs are used. The transmission delay in a GEO architecture depends on the user-gateway distance (or user-user if direct connection is allowed) when a single satellite configuration with no ISLs (inter-satellite links) is considered. Also. In a connectionless . Whenever a change in RTT occurs. TCP may not be able to update its estimate of RTT quickly enough. If the RTT keeps changing. Delay-Bandwidth Product (DBP): The performance of TCP over satellite links is also influenced by the Delay-BandwidthProduct (DBP). This performance can be enhanced by adopting techniques such as selective acknowledge and window dimensioning [9. since the routing strategy may also play a very important role. techniques such as TCP spoofing. and 11]. since it causes the delivery packet time to be variable and may affect the estimate of Round Trip Time (RTT) by TCP. However due to queue phenomenon in terrestrial router even fixed users can experience a large variability in propagation delay. This may cause premature timeouts/retransmissions. 10. they can experience a significant transmission delay (depending on the type of constellation and the routing strategy adopted). it takes some time for TCP to adapt to the change. This has been evaluated through simulations and experiments [9. Satellite diversity: Satellite diversity is a very efficient technique for improving link availability or SNR by utilizing more than one user-satellite link to establish communication. reducing the overall bandwidth efficiency.
the original TCP protocol was extended with some additive function. This causes TCP to employ its congestion control algorithms. Poor SNR is an extensively studied issue for GEO satellites. TCP attributes it to network congestion. In the following we describe these functions: . Signal-to-noise ratio (SNR): In GEO constellations. the satellite diversity feature has the advantage of increasing the probability of packet delivery to/from the satellite network from/to Earth. However. and causes an unnecessary reduction in throughput. Since TCP has been designed mainly for wired links. TCP PROTOCOLS DETAILS The Transmission Control Protocol (TCP) was originally designed for wired link so it is based on some assumption related to specific characteristic of wired link. over 10 GHz) for fixed communications and also due to shadowing in case of mobile communications. Moreover TCP is based on the assumption that the network does not provide any explicit feedback to the sources. the SNR (or equivalently Bit Error Rate. This is detrimental in satellite links. 4. or less) so that when a packet is lost. BER) is characterized by a great variability due to free space losses and troposphere propagation (including rain. the mains of which were implemented in TCP Reno. which reduces the overall throughput. such as round-trip time (RTT) or usable bandwidth in order to perform efficient end-to-end congestion control.system. In order to improve the performance of TCP connections for preventing congestion events and achieve a fair share of bandwidth among different connections. Both shadowing and deep rain fading can cause packet loss. which causes a reduction in capacity. it assumes that the BER is very low (of the order of 10-10. this increases the number of busy channels. Therefore each source must form its own estimates of the network properties.
however. Slow start ends when the receiver‟s advertised window is reached or when loss is detected. Fast Retransmit and Fast Recovery TCP Reno also incorporates Fast Retransmit and Recovery. fast recovery is used instead. it injects two segments into the network. Slow start begins by sending one segment and waiting for an acknowledgement. satellite links are particularly sensitive to the limited throughput available during slow start. Fast recovery works in conjunction with fast retransmit. it drops back into slow start until the packet sending rate is one half the rate at which the loss was detected and then begins the congestion avoidance phase. Congestion avoidance is used to probe the network for available bandwidth by sending one additional segment for each round trip time (up to the receivers advertised window). If the sending TCP detects the segment loss using fast retransmit. Fast recovery halves the . Rather than waiting for the retransmit timeout (RTO). when a sender retransmits a segment. Although these mechanisms have been found in many Unix variants of TCP for several years. In the original slow start/congestion avoidance scheme. RFC 2001. Because the amount of time required for slow start to achieve full bandwidth is a function of round trip time. it normally recovers by moving first into a slow start phase followed by a congestion avoidance phase. they were not documented as a Standards Track RFC until 1997. when the sending TCP detects segment loss (by default assuming network congestion). thus leading to an exponential increase in the amount of data being sent. For each acknowledgement the sender receives. the TCP sender can retransmit a segment if it receives three duplicate ACKs for the segment sent immediately before the lost segment. As mentioned above. Slow start is used to gradually increase the rate at which the sender injects data into the network.Slow Start and Congestion Avoidance The slow start and congestion avoidance mechanisms were introduced in 1988 in  and added as a requirement for TCP implementations in RFC 1122. Fast retransmit reduces the time it takes a TCP sender to detect a single dropped segment.
in order to improve the response to partial acknowledgments. triggering the Fast Retransmit algorithm. without falling back to slow start. In the original implementation of the TCP Fast Recovery algorithm the TCP data sender only retransmits a packet after a retransmit timeout has occurred. or after three duplicate acknowledgements have arrived. Using a selective acknowledgement (SACK) mechanism. a more timely retransmission of dropped segments is used. giving the sender more information about which segments might need to be retransmitted and avoiding to retransmit segments which travel trough long delay link. TCP Vegas In order to increase throughput and decrease losses TCP Vegas introduces three techniques . TCP SACK This protocol introduces the ability for TCP to use Selective Acknowledgments. but each invocation of the Reno Fast Retransmit algorithm leads to the retransmission of only a single data packet. TCP NewReno defines a "Fast Recovery procedure" that begins when three duplicate ACKs are received and ends when either a retransmission timeout occurs or an ACK arrives that acknowledges all of the data up to and including the data that was outstanding when the Fast Recovery procedure began. the SACKs generated at the receiver explicitly inform the sender about which segments have arrived and which may have been lost. In this way it can recover a situation when multiple packets have been dropped from a single window of data in a faster way than TCP-Reno. such as satellite connections. A single retransmit timeout might result in the retransmission of several data packets. This is obtained by .segment sending rate and begins congestion avoidance immediately. which were first proposed by Janey Hoe . as defined in RFC 2018. This aspect is considered very important in satellite scenario. TCP Newreno This protocol implements some modifications in Fast Recovery algorithm. Firstly. because the cumulative positive acknowledgments employed by TCP are not particularly well suited to the long-delay satellite environment due to the time it takes to obtain information about segment loss.
TCP Tibet This protocol implements some modifications in TCP Westwood mechanism for estimating the available bandwidth. When a non-duplicate ACK is received after a retransmission. and obtains bandwidth estimates which oscillate around the fair-share value when all TCP sources experience almost the same path conditions. leading to unnecessary window reduction. . sporadic losses or with paths with high bandwidth/delay product typical of satellite links. In addition it is also possible. then Vegas anticipates the retransmission of the segment. TCP Westwood This protocol  has the advantage that can be implemented only at the sources of TCP connections so at difference of SACK not need a worldwide diffusion for working correctly. in order to estimate the used bandwidth. i. If it is. Resetting the window to match available bandwidth makes TCP Westwood more robust to sporadic losses due to wireless channel problems. The estimate is realized by measuring and low-pass filtering the length of acked packets and the intervals between ACKs‟ arrivals. Vegas again checks to see if the time interval since the segment was sent is larger than the timeout value. to apply a low-pass filter directly to the packets‟ length and the intervals between sending times. In fact.using a more accurate RTT estimate. Vegas only decreases the congestion window if the retransmitted segment was previously sent after the last decrease. Furthermore. These often cause conventional TCP to overreact. it introduces a double filtering technique to obtain correct estimates of the bandwidth used by TCP sources without error introduced by sporadic losses. especially in presence of random. by reading the system clock each time a segment is sent and again when an ACK arrives. It performs an estimate of the available bandwidth by measuring the returning rate of acknowledgements. which usually occurs when packets travel trough long-delay links. a loss that happened before the last window decrease does not imply that the network is congested for the current congestion window size. This explicit bandwidth estimation scheme has a deep impact over the performance of TCP.e. In particular. Thanks to the Double filtering technique TCP Tibet has a bandwidth estimation mechanism which is not biased by the phenomenon of ACK compression. and uses this estimate for setting the parameter of the Fast recovery mechanism in order to avoid the blind halving of the sending rate as in TCP Reno after packet losses.
whenever any node wants to initiate communication with another node to which it has no route. Reactive Routing Protocol These protocols only find a route to the destination node when there is a need to send data. Reactive routing protocols are: protocol (DSR) -Based Adaptive Routing (SSA) -Aided Routing Protocol (LAR) . The sender will than wait for the destination node or an intermediate node to respond with a list of intermediate nodes between the source and destination. This kind of protocols is usually based on flooding the network with Route Request (RREQ) and Route reply (RERP) messages.BACKGROUND 1. The routing protocol will try to establish such a route. The source node will start by transmitting route request throughput the network. Reactive protocols start to set up routes on-demand.
Hybrid Routing Protocol Since proactive and reactive protocols each work best in oppositely different scenarios. at every single node an absolute picture of the network is maintained. It is used to find a balance between both protocols. Through a regular exchange of network topology packets between the nodes of the network. When the routing information becomes worthless quickly. There is hence minimal delay in determining the route to be taken. This is especially important for time-critical traffic. whereas. Proactive WSN Protocols include: -eye State Routing (FSR) -Sequenced Distance Vector (DSDV) -head Gateway Switch Routing Protocol (CGSR) 3. Hybrid protocols are: ting Protocol (ZRP) 13 . Proactive Routing Protocol Proactive WSNs protocols are also called as table-driven protocols and will actively determine the layout of the network. reactive protocols are used for locating nodes outside those domains. there are many short-lived routes that are being determined and not used before they turn invalid.2. Proactive operations are restricted to small domain. hybrid method uses both.
namely Dynamic Source Routing (DSR) and Ad Hoc On-demand Distance Vector (AODV) routing protocols.-head Gateway Switch Routing Protocol (CGSR) The routing protocols AODV. When a node wants to establish a route to a destination. Problem formulation and implementation issues TCP/IP protocol was designed for wired networks which provides end to end reliable communication between nodes and assures ordered delivery of packets. On-demand Routing Protocols such as AODV and DSR are used for this performance analysis of TCP. We will analyze the performance of two ondemand routing protocols for ad hoc networks. But in case of ad hoc networks packet losses are due to congestion in the network and due to frequent link failures so when we adapt TCP to ad hoc networks it misinterprets the packet losses due to link failure as packet losses due to congestion and in the instance of a timeout. As it is still a successful protocol in wired networks. route changes due to host mobility can have a detrimental impact on performance. They can be used in mobile ad hoc networks to rout packets between mobile nodes.This results in unnecessary reduction of transmission rate because of which throughput of the whole network degrades. based on TCP traffic flows. . These types of routing protocols create routes only when requested by a source node. We also use DSDV which is a table driven routing protocol. losses are mainly due to congestion. DSR and DSDV are three of the promising routing protocols. It also provides flow control and error control mechanisms. One the route has been established. it is maintained until either destination becomes inaccessible or the route is no longer desired. backing-off its retransmission timeout (RTO). Therefore. it initiates a route discovery process within the network.
Fast Retransmit and Fast Recovery the mechanisms described so far were part of the original proposal to add congestion control to TCP. and the TCP congestion control mechanisms will start dealing with the segment loss. TCP does not have any resilience mechanisms that are specially designed to deal with link failures. that the coarse-grained implementation of TCP timeouts led to long periods of time during which the connection went dead while waiting for a timer to expire. It was soon discovered. but also works with fair queuing. NewReno TCP and SACK TCP are widely implemented. The main versions of TCP are Tahoe TCP. Because of this. there is no difference between link failure and network congestion. We focus on another two new TCP variants TCP FACK and TCP Vegas because they are the newer versions and are being deployed.Proposed research methodology TCP optimization in WSNs has been investigated in several studies. From the viewpoint of TCP. DSR and DSDV Congestion Control Mechanisms The predominant example of end-to-end congestion control in use today. NewReno TCP and SACK TCP. however. As a result. when part of the network fails and some segments are dropped. TCP will assume that there is congestion somewhere in the network. Reno TCP. TCP congestion control mechanisms have improved over time.transmit was added to TCP. And also the analysis was not on just one routing protocol but three widely used routing protocols. . The essential strategy of TCP is to send packets into the network without a reservation and then to react to observable events that occur. a new mechanism called fast re. AODV. that implemented by TCP. Fast retransmit is a heuristic that sometimes triggers the retransmission of a dropped packet sooner than the regular timeout mechanism. Tahoe TCP is the oldest version and only a few old systems use it. TCP assumes only FIFO queuing in the network routers.
It also provides powerful trace functionalities. It not only supports most commonly used IP protocols but also allows the users to extend or implement their own protocols. including DSR.Required resource for proposed work Network Simulator (NS-2) Ns2 is a discrete event simulator targeted at networking research. The full source code of ns2 can be downloaded and compiled for multiple platforms such as UNIX. Ns2 is highly extensible. It consists of two simulation tools. routing and multicast protocols over wired and wireless networks. Windows. The network simulator (ns) contains all commonly used IP protocols. which are very important in our project since various information need to be logged for analysis. C++ . There is a one-to-one correspondence between a class in the interpreted hierarchy and one in the compile hierarchy.Ns2 is an object-oriented simulator written in C++ and TCL. It provides substantial support for simulation of TCP. The reason to use two different programming languages is that OTCL is suitable for the programs and configurations that demand frequent and fast change while C++ is suitable for the programs that have high demand in speed. The network animator (nam) is use to visualize the simulations. Ns2 fully simulates a layered network from the physical radio transmission channel to high-level applications. The simulator supports a class hierarchy in C++ and a similar class hierarchy within the TCL interpreter. The latest ns2 version supports the four routing protocols. Languages Used:1.
Throughput is calculated in bites/sec. TCL TCL is an interpretive language. 7. which means that a programmer is free to use C code for the speed critical parts of a program. a programmer can add new commands to the language by implementing them as C functions. Expected outcomes In this article By using different WSN routing protocols like proactive (DSDV) and reactive (AODV and DSR) we want to measure. 1. C++ uses a compiler. Total number of received packets at destination Throughput (bites/sec) = ------------------------------------------------------------Total simulation time 2. Throughput: Throughput is the average number of successfully delivered data packets on a communication network or network node. In TCL. each time something in the source code is changed. data packet/second and data packet/time slot. the program has to be partially recompiled and delinked. End To End Delay and Packet Delivery Ratio. The C functions can then be called from the (8) command line interface of the TCL interpreter.C++ is a programming language that implements object-oriented programming. 1. . C++ is a superset of C. calculate and compare the parameters like Throughput. End to end Delay: It can be defined as the time a packet takes to travel from source to destination.
Packet Delivery Ratio: The ratio of number of delivered data packet to the (9) destination. By using this fundamentals we are comparing all the rounting protocol which are taken by us. 3. . We are expecting that after the comparison reactive (AODV) routing protocol is much better than other two.dend-end= N[ dtrans+dprop+dproc] Where dend-end dtras dprop dproc N = end-to-end delay = transmission delay = propagation delay = processing delay = number of links (Number of routers + 1) The lower value of end to end delay means better performance of the protocol. Total number of packet receive PDR = ------------------------------------------Total number of packet sent The greater value of the packet delivery ratio means better performance of the Protocol.
Martignon. and T. A. The NewReno Modifications to TCP‟s Fast Recovery Algorithm.Romanov. October 1996. Hayes. and M. Loreti. vol.C: Hoe. O‟Mahony.-Feb.R. Improving the Start-up Behaviour of a congestion Control Scheme for TCP. and A. 7.Henderson. M. Floyd. H. Satellite Systems Performance with TCP-IP Applications. IWDC 2001. J. April 1996 5. Ostermann. Kapoor. UMTS: the fusion of fixed and mobile networking. Mathis. P. D. IWDC 2001. September 2001. M. TCP Performance over Satellite Links. Kruse. Taormina. 21. A. Taormina.Luglio. IETF RFC 2582. M. Ohio University 3. M. 4. J. Capone. and F. TCP Selective Acknoledgement Option. 2. S. Allman. S. Floyd. J. R. Jan. .Mahadavi. VazquezCastro. S. RFC 2018. F. Stepahnek. Gerla. ACM SIGCOMM Computer communications Review. Vatalaro. IEEE Internet Computing.References 1. April 1999 6. Bandwidth Estimates in the TCP Congestion Control Scheme. September 2001. 1998. C.
RFC 2001 16. June 2000. D. Charalambous. Casetti. TCP Vegas: New Techniques for Congestion Detection and Avoidance. pages 24--35. Congestion Avoidance and Control. 7. H. 40-47. July 1999. pp.8.isi. On the Performance of TCP-based Data transfers on a faded Ka-Band Satellite Link. ACM. July 1999. B. S. RFC 793 17. Borman. Proceedings of the 6th Ka-Band Utilization Conference. V. A History of the Improvement of Internet Protocols Over Satellites Using ACTS. Kruse. L. 7. Evans. IEEE Communications Magazine. P. In Proceedings ACM SIG-COMM „88. L. NASA‟s Broadband satellite networking research. Requirements for Internet Hosts.edu/nsnam/ns/. n. D. M. “TCP Slow Start. pp. D. 57-63. Invited paper for ACTS Conference 2000. Sanadidi. D. S. Brakmo. www. Ostermann. W. O‟Malley. January 1997. W. C. J. and D. 2000 13. Ostermann. Braden. J. R. Lee. May 2000. Mascolo. V. V. Postel. W. Ivancic. R. RFC 1122 15. October 1989. “Network Simulator (NS-2)”. S. S. Peterson. RFC 1323 18. UCLA CSTechnical Report #200017. Brooks. August 1988 14. Frantz. B. Allman. Shell. Jacobson. Beering. May 1992. 10. Hoder. Frost. . H. Jacobson. S. TCP with Faster Recovery. Congestion Avoidance. Fast Retransmit. Stevens. May 1994. C. Allman. M. Performance evaluation of TCP extensions on ATM over high bandwidth delay product networks. 1994 ACM SIGCOMM Conference. D. M. 12. Kruse. 11. M. n. S. S. 9. Gerla. 19.Communication Layers. S. IEEE Communications Magazine. September 1981. TCP Extensions for High Performance. Transmission Control Protocol. Braden. L. and Fast Recovery Algorithms.
This action might not be possible to undo. Are you sure you want to continue?