7/30/2019 shikh

1/20

Abstract

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.

7/30/2019 shikh

2/20

Introduction

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 [1] 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 [2] 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 TCPs performance oversatellite links.

7/30/2019 shikh

3/20

We analyze some representative satellite scenarios with a

classical GEO configuration satellite repeater.

7/30/2019 shikh

4/20

Literature survey

THE ROLE OF SATELLITES:

In the future, satellites will play an important role in providing wireless access to mobile

users, for enhancing coverage of existing or developing land mobile systems and to ensure

long-range mobility and large bandwidth. The presence of satellite links provides extra

capacity and an alternate and less congested route to existing wired and wireless systems,

thus offering unique opportunities for improving efficiency and reliability. The broadcast

nature of the satellite channel also makes satellites suitable for broadcasting/multicasting.

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. The growing interest in exploring new worlds needs an affordable and performing

system of communication for granting the success of space missions, in order to guarantee a

complete control of mission evolution.

The satellite may also be integrated with short-range wirelessnetworks (Bluetooth) in order to provide Internet services to mobile vehicles. In this

scenario, the satellite will connect one vehicular terminal to the Internet while the Bluetooth

system will be able to interconnect equipment inside the vehicle (car, bus, train, plane or

ship).

The main satellite communication systems, providing large bandwidth

directly to users, are based on a geosynchronous orbital configuration. A single GEOsatellite is able to cover a very wide area with multiple narrow spot beams using multibeam

antennas. In this way, very reliable links can be provided even with small terminals. 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). Many of them are

expected to provide regional limited coverage in a few years and global coverage

(excluding poles) finally.

7/30/2019 shikh

5/20

Previous works [8-12] has addressed the performance of TCP/IP over

geostationary satellites. This has mainly focused on evaluating performance of different

TCP schemes (Tahoe, Reno, New Reno, SACK), where the connection between two fixed

stations goes across a GEO satellite. In this paper, we also address other TCP schemes

(Westwood [12] and Tibet[7]) 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;

besides we exposed both type of connections to the aggressive behavior of a UDP flow to

evaluate the ability to conserve their throughput. 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, when considering the performance of real time (e.g.

voice and video) applications the large propagation delays represent a critical issue. The

problem is particularly acute in TCP applications over links with large bandwidth-delay

products, where a large TCP window is required for efficient use of the satellite link. A

lossy satellite link can cause frequent slow start events, with significant impact on

throughput. 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- Bandwidth Product (DBP), signal-to-noise ratio (SNR), satellite diversity, routing

strategy.

Satellite systems are changing their role from the bent-

pipe (transparent) channel paradigm to the onboard routing (regenerative) paradigm

associated with packet transmission and switching. In this process each satellite is anelement of a network, and new design problems are involved both at the network and the

transport layers.

While considering the performance of standard Internet protocols over paths including

satellite links, the large propagation delays have to be taken into account. The problem is

particularly relevant to TCP due to its delay-sensitive nature. For voice and other real time

applications too, the delay may be critical. Some of the main aspects that need to be

7/30/2019 shikh

6/20

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, they can

experience a significant transmission delay (depending on the type of constellation and the

routing strategy adopted). 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, or on the connection strategyif ISLs are used. This delay can be considered constant in the caseof fixed users while it is

variable in the case of mobile users. However due to queue phenomenon in terrestrial router

even fixed users can experience a large variability in propagation delay. This phenomenon

is even more critical if ISLs are implemented, since the routing strategy may also play a

very important role. The delay variability is particularly relevant to TCP, since it causes the

delivery packet time to be variable and may affect the estimate of Round Trip Time (RTT)

by TCP. Whenever a change in RTT occurs, it takes some time for TCP to adapt to the

change. If the RTT keeps changing, TCP may not be able to update its estimate of RTTquickly enough. This may cause premature timeouts/retransmissions, reducing the overall

bandwidth efficiency.

Delay-Bandwidth Product (DBP):

The performance of TCP over satellite links is also influenced by the Delay-Bandwidth-

Product (DBP). This has been evaluated through simulations and experiments [9, 10, and11]. This performance can be enhanced by adopting techniques such as selective

acknowledge and window dimensioning [9, 11]. Also, techniques such as TCP spoofing,

splitting and cascading may be used [11].

Satellite diversity:

Satellite diversity is a very efficient technique for improving link availability or SNR byutilizing more than one user-satellite link to establish communication. In a connectionless

7/30/2019 shikh

7/20

system, the satellite diversity feature has the advantage of increasing the probability of

packet delivery to/from the satellite network from/to Earth. However, this increases the

number of busy channels, which causes a reduction in capacity.

Signal-to-noise ratio (SNR):

In GEO constellations, the SNR (or equivalently Bit Error Rate, BER) is characterized by a

great variability due to free space losses and troposphere propagation (including rain, over

10 GHz) for fixed communications and also due to shadowing in case of mobile

communications. Both shadowing and deep rain fading can cause packet loss. Poor SNR is

an extensively studied issue for GEO satellites. Since TCP has been designed mainly for

wired links, it assumes that the BER is very low (of the order of 10-10, or less) so that when

a packet is lost, TCP attributes it to network congestion. This causes TCP to employ its

congestion control algorithms, which reduces the overall throughput. This is detrimental in

satellite links, and causes an unnecessary reduction in throughput.

4. 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. Moreover TCP is

based on the assumption that the network does not provide any explicit feedback to the

sources. Therefore each source must form its own estimates of the network properties, such

as round-trip time (RTT) or usable bandwidth in order to perform efficient end-to-end

congestion control.

In order to improve the performance of TCP connections for

preventing congestion events and achieve a fair share of bandwidth among different

connections, the original TCP protocol was extended with some additive function, the mains

of which were implemented in TCP Reno. In the following we describe these functions:

7/30/2019 shikh

8/20

Slow Start and Congestion Avoidance

The slow start and congestion avoidance mechanisms were introduced in 1988 in [13] and

added as a requirement for TCP implementations in RFC 1122[14].

Slow start is used to gradually increase the rate at which the

sender injects data into the network. Slow start begins by sending one segment and waiting

for an acknowledgement. For each acknowledgement the sender receives, it injects two

segments into the network, thus leading to an exponential increase in the amount of data

being sent. Slow start ends when the receivers advertised window is reached or when loss

is detected. Because the amount of time required for slow start to achieve full bandwidth is

a function of round trip time, satellite links are particularly sensitive to the limited

throughput available during slow start.

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). In the original slow start/congestion avoidance scheme,

when the sending TCP detects segment loss (by default assuming network congestion), itdrops 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.

Fast Retransmit and Fast Recovery

TCP Reno also incorporates Fast Retransmit and Recovery, RFC 2001[15]. Although these

mechanisms have been found in many Unix variants of TCP for several years, they were not

documented as a Standards Track RFC until 1997. Fast retransmit reduces the time it takes a

TCP sender to detect a single dropped segment. Rather than waiting for the retransmit

timeout (RTO), the TCP sender can retransmit a segment if it receives three duplicate ACKs

for the segment sent immediately before the lost segment.

Fast recovery works in conjunction with fast retransmit. As mentioned above, when a

sender retransmits a segment, it normally recovers by moving first into a slow start phase

followed by a congestion avoidance phase. If the sending TCP detects the segment lossusing fast retransmit, however, fast recovery is used instead. Fast recovery halves the

7/30/2019 shikh

9/20

segment sending rate and begins congestion avoidance immediately, without falling back to

slow start.

TCP SACK

This protocol introduces the ability for TCP to use Selective Acknowledgments. This aspect

is considered very important in satellite scenario, 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.Using a selective acknowledgement (SACK) mechanism, as defined in RFC 2018[4], the

SACKs generated at the receiver explicitly inform the sender about which segments have

arrived and which may have been lost, giving the sender more information about which

segments might need to be retransmitted and avoiding to retransmit segments which travel

trough long delay link, such as satellite connections.

TCP Newreno

This protocol implements some modifications in Fast Recovery algorithm, in order to

improve the response to partial acknowledgments, which were first proposed by Janey Hoe

[6]. 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, triggering the Fast Retransmit algorithm. A single

retransmit timeout might result in the retransmission of several data packets, 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. 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.

TCP Vegas

In order to increase throughput and decrease losses TCP Vegas introduces three techniques[18]. Firstly, a more timely retransmission of dropped segments is used. This is obtained by

7/30/2019 shikh

10/20

7/30/2019 shikh

11/20

BACKGROUND

1. Reactive Routing Protocol

These protocols only find a route to the destination node when there is a need to send data.

The source node will start by transmitting route request throughput the network. 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.

Reactive protocols start to set up routes on-demand. The routing protocol will try to

establish such a route, whenever any node wants to initiate communication with another

node to which it has no route. This kind of protocols is usually based on flooding the

network with Route Request (RREQ) and Route reply (RERP) messages.

Reactive routing protocols are:

protocol (DSR)

-Based Adaptive Routing (SSA)

-Aided Routing Protocol (LAR)

7/30/2019 shikh

12/20

2. Proactive Routing Protocol

Proactive WSNs protocols are also called as table-driven protocols and will actively

determine the layout of the network. Through a regular exchange of network topology

packets between the nodes of the network, at every single node an absolute picture of the

network is maintained. There is hence minimal delay in determining the route to be taken.

This is especially important for time-critical traffic. When the routing information becomes

worthless quickly, there are many short-lived routes that are being determined and not usedbefore they turn invalid.

Proactive WSN Protocols include:

-eye State Routing (FSR)

-Sequenced Distance Vector (DSDV)

-head Gateway Switch Routing Protocol (CGSR)

3. Hybrid Routing Protocol

Since proactive and reactive protocols each work best in oppositely different scenarios,

hybrid method uses both. It is used to find a balance between both protocols. Proactive

operations are restricted to small domain, whereas, reactive protocols are used for locating

nodes outside those domains.

Hybrid protocols are:

ting Protocol (ZRP) 13

7/30/2019 shikh

13/20

-head Gateway Switch Routing Protocol (CGSR)

The routing protocols AODV, DSR and DSDV are three of the promising routing protocols.

They can be used in mobile ad hoc networks to rout packets between mobile nodes.

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. It also provides

flow control and error control mechanisms. As it is still a successful protocol in wired

networks, losses are mainly due to congestion. 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, backing-off its retransmission timeout

(RTO).This results in unnecessary reduction of transmission rate because of which

throughput of the whole network degrades. Therefore, route changes due to host mobility

can have a detrimental impact on performance. On-demand Routing Protocols such as

AODV and DSR are used for this performance analysis of TCP. These types of routing

protocols create routes only when requested by a source node. When a node wants to

establish a route to a destination, it initiates a route discovery process within the network.

One the route has been established, it is maintained until either destination becomes

inaccessible or the route is no longer desired. We will analyze the performance of two on-

demand routing protocols for ad hoc networks, namely Dynamic Source Routing (DSR) and

Ad Hoc On-demand Distance Vector (AODV) routing protocols, based on TCP traffic

flows. We also use DSDV which is a table driven routing protocol.

7/30/2019 shikh

14/20

Proposed research methodology

TCP optimization in WSNs has been investigated in several studies. TCP does not have any

resilience mechanisms that are specially designed to deal with link failures. From the

viewpoint of TCP, there is no difference between link failure and network congestion. 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, and the TCP congestion control mechanisms

will start dealing with the segment loss. TCP congestion control mechanisms have

improved over time. The main versions of TCP are Tahoe TCP, Reno TCP, NewReno TCP

and SACK TCP. Tahoe TCP is the oldest version and only a few old systems use it.

NewReno TCP and SACK TCP are widely implemented. We focus on another two new

TCP variants TCP FACK and TCP Vegas because they are the newer versions and are

being deployed. And also the analysis was not on just one routing protocol but three widely

used routing protocols, AODV, DSR and DSDV Congestion Control Mechanisms The

predominant example of end-to-end congestion control in use today, that implemented by

TCP. The essential strategy of TCP is to send packets into the network without a reservation

and then to react to observable events that occur. TCP assumes only FIFO queuing in the

network routers, but also works with fair queuing. Fast Retransmit and Fast Recovery themechanisms described so far were part of the original proposal to add

congestion control to TCP. It was soon discovered, however, 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. Because of this, a new mechanism called fast

re- transmit was added to TCP. Fast retransmit is a heuristic that sometimes triggers the

retransmission of a dropped packet sooner than the regular timeout mechanism.

7/30/2019 shikh

15/20

Required resource for proposed work

Network Simulator (NS-2)

Ns2 is a discrete event simulator targeted at networking research. It provides substantial

support for simulation of TCP, routing and multicast protocols over wired and wireless

networks. It consists of two simulation tools. The network simulator (ns) contains all

commonly used IP protocols. 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.Ns2 is an object-oriented simulator written in C++ and

TCL. The simulator supports a class hierarchy in C++ and a similar class hierarchy within

the TCL interpreter. There is a one-to-one correspondence between a class in the interpreted

hierarchy and one in the compile hierarchy. 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. Ns2 is highly extensible. It not only supports most commonly used IP protocols but

also allows the users to extend or implement their own protocols. The latest ns2 versionsupports the four routing protocols, including DSR. It also provides powerful trace

functionalities, which are very important in our project since various information need to be

logged for analysis. The full source code of ns2 can be downloaded and compiled for

multiple platforms such as UNIX, Windows.

Languages Used:-

1. C++

7/30/2019 shikh

16/20

C++ is a programming language that implements object-oriented programming. C++ uses a

compiler, each time something in the source code is changed, the program has to be

partially recompiled and delinked. C++ is a superset of C, which means that a programmer

is free to use C code for the speed critical parts of a program.

1. TCLTCL is an interpretive language. In TCL, a programmer can add new commands to the

language by implementing them as C functions. The C functions can then be called from the

(8)

command line interface of the TCL interpreter.

7. Expected outcomes

In this article By using different WSN routing protocols like proactive (DSDV) and reactive

(AODV and DSR) we want to measure, calculate and compare the parameters like

Throughput, End To End Delay and Packet Delivery Ratio.

1. Throughput: Throughput is the average number of successfully delivered datapackets on a communication network or network node.

Throughput is calculated in bites/sec, data packet/second and data packet/time slot.

Total number of received packets at destination

Throughput (bites/sec) = -------------------------------------------------------------

Total simulation time

2. End to end Delay: It can be defined as the time a packet takes to travel fromsource

to destination.

7/30/2019 shikh

17/20

dend-end= N[ dtrans+dprop+dproc]

Where

dend-end = end-to-end delaydtras = transmission delay

dprop = propagation delay

dproc = processing delay

N = number of links (Number of routers + 1)

The lower value of end to end delay means better performance of the protocol.

3.

Packet Delivery Ratio: The ratio of number of delivered data packet to the(9)

destination.

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.

By using this fundamentals we are comparing all the rounting protocol which are taken

by us. We are expecting that after the comparison reactive (AODV) routing protocol is

much better than other two.

http://en.wikipedia.org/wiki/Propagation_delayhttp://en.wikipedia.org/wiki/Processing_delayhttp://en.wikipedia.org/wiki/Processing_delayhttp://en.wikipedia.org/wiki/Propagation_delay

7/30/2019 shikh

18/20

References

1. D. OMahony, UMTS: the fusion of fixed and mobile networking, IEEE Internet

Computing, vol. 21, Jan.-Feb. 1998.

2. M. Allman, C. Hayes, H. Kruse, S. Ostermann, TCP Performance over Satellite Links,Ohio University

3. P. Loreti, M.Luglio, R. Kapoor, J. Stepahnek, M. Gerla, F. Vatalaro, and M. A. Vazquez-

Castro, Satellite Systems Performance with TCP-IP Applications, IWDC 2001, Taormina,

September 2001.

4. S. Floyd, M. Mathis, J.Mahadavi, and A.Romanov, TCP Selective Acknoledgement

Option, RFC 2018, April 1996

5. S. Floyd, and T.R.Henderson, The NewReno Modifications to TCPs Fast Recovery

Algorithm, IETF RFC 2582, April 1999

6. J.C: Hoe, Improving the Start-up Behaviour of a congestion Control Scheme for TCP,

ACM SIGCOMM Computer communications Review, October 1996.

7. A. Capone, and F. Martignon, Bandwidth Estimates in the TCP Congestion Control

Scheme, IWDC 2001, Taormina, September 2001.

7/30/2019 shikh

19/20

8. W. D. Ivancic, D. Brooks, B. Frantz, D. Hoder, D. Shell, D. Beering, NASAs Broadband

satellite networking research, IEEE Communications Magazine, n. 7, July 1999, pp. 40-47.

9. C. P. Charalambous, V. S. Frost, J. B. Evans, Performance evaluation of TCP extensionson ATM over high bandwidth delay product networks, IEEE Communications Magazine, n.

7, July 1999, pp. 57-63.

10. H. Kruse, S. Ostermann, M. Allman, On the Performance of TCP-based Data transfers

on a faded Ka-Band Satellite Link, Proceedings of the 6th Ka-Band Utilization Conference,

June 2000.

11. M. Allman, H. Kruse, S. Ostermann, A History of the Improvement of Internet

Protocols Over Satellites Using ACTS, Invited paper for ACTS Conference 2000, May

2000.

12. C. Casetti, M. Gerla, S. S. Lee, S. Mascolo, M. Sanadidi, TCP with Faster Recovery,

UCLA CSTechnical Report #200017, 2000

13. V. Jacobson, Congestion Avoidance and Control, In Proceedings ACM SIG-COMM 88,

ACM, August 1988

14. R. Braden, Requirements for Internet Hosts- Communication Layers, October 1989,

RFC 1122

15. W. Stevens, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast

Recovery Algorithms, January 1997, RFC 2001

16. J. Postel, Transmission Control Protocol, September 1981, RFC 793

17. V. Jacobson, R. Braden, and D. Borman, TCP Extensions for High Performance, May

1992, RFC 1323

18. L. S. Brakmo, S. W. OMalley, L. L. Peterson, TCP Vegas: New Techniques forCongestion Detection and Avoidance, 1994 ACM SIGCOMM Conference, pages 24--35,

May 1994.

19. Network Simulator (NS-2), www.isi.edu/nsnam/ns/.

7/30/2019 shikh

20/20