Performance of TCP Vegas, Bic and Reno Congestion Control Algorithms on Iridium Satellite Constellations

Published Online November 2012 in MECS (http://www. DOI: 10.5815/ijcnis.2012.12.04

Satellite Communications delves with a number of technical problems for mobile networks and applications. The difference of properties between satellite link and wired or wireless networks includes larger latency, bursty error characteristics, asymmetric capability, and unconventional network architecture. The above metrics creates a greater impact on satellite communication issues. [1].

Internetworking and computing aspect of satellite networks are major issues in the recent research. A variety of issues involving applications includes, network architecture, medium access controls, multicast routing, asymmetric routing, transport protocols, TCP performance enhancement techniques, data broadcast, and information disseminations. Communication over geosynchronous satellites have long round trip times of approximately 560 ms. The journey through the atmosphere can also introduce bit errors in the data stream. This means that considerable time is needed in Slow Start mechanism in order to open a new connection for TCP, to increase its throughput to what the link capacity will bear. The Loss of an errored packet due to congestion, results in reduction of the congestion window due to large RTT which results in the slowdown of high rate of throughput. In both cases, expensive satellite link capacity is not fully utilized [2].

The goal is to apply the TCP Congestion control, algorithms on Iridium satellite constellations and to perform a comparative analysis based on suitable metrics. The Usage of various tools applied for the experimental purpose has been listed

• II.    Problem Specification

The transmission Control Protocol (TCP) was originally designed for reliable data transport within the terrestrial wired networks. Even though it was not designed for satellite network communication, due to the increasing interest of fixed and mobile interactive service delivery via satellite directly to the final user, the TCP/IP is being studied to overcome its limitations within the satellite medium. TCP congestion control algorithms which were designed originally for wired network communication required only a little modification and performance tuning to be adapted for a Mobile Ad hoc Network. Even though the satellite network is like a wireless mobile ad hoc network, the algorithms working good on MANET certainly will not behave the same manner under satellite constellation. The reasons are the way in which routing and hand-off were handled in Satellite networking. The main aim of this study is to investigate the behavior of some of the existing TCP congestion control algorithms (Vegas, Reno and BIC) under Iridium satellite constellations. The results of this evaluation will make us understand the behavior of TCP congestion control algorithms on satellite network and show some possibilities for improving the existing congestion control algorithm to suit them with satellite networking.

• A.    The Satellite Constellations [3][15][16]

A group of artificial satellites working together in concert is known as a satellite constellation. They are classified into 3 types based on its height from the Earth’s surface. They are mentioned below as

• •    Low Earth Orbit (LEO) satellite constellations

• •    Medium Earth Orbit (MEO) satellite constellations

• •    High Earth Orbit (HEO) Satellite constellations.

Low Earth Orbiting satellites (LEOs)

The Low Earth Orbit, LEO is relatively low in altitude, and it ranges from 200 to 1200 km above the Earth surface and time taken for the satellite to orbit is merely 15 minutes. It is very close to the Earth and the low orbit altitude leads to number of characteristics features as, lower propagation delay, small path loss, minimal power requirement on satellite and user terminal, and more efficient spectrum allocation and considerably less Round Trip Time compared to other orbit satellites. Low Earth orbiting satellites are often deployed in satellite constellations, because the coverage area provided by a single LEO satellite only covers a small area that moves as the satellite travels at the high angular velocity needed to maintain its orbit. Many LEO satellites are needed to maintain continuous coverage over an area.

Geostationary Earth Orbiting satellites (GEOs)

The Geostationary Orbit has the advantage that the satellite remains in the same position and antennas can be directed towards the satellite and remains on track moving at the same angular velocity as the rotation of the Earth’s surface, provides permanent coverage over a large area which is contrast with LEO. As the height of a satellite increases, so the time for the satellite to orbit increases. At a height of 35,790 km, it takes 24 hours for the satellite to orbit and hence the name geosynchronous orbit as it is synchronized with the earth.

Broadband applications benefit from low-latency communications, so LEO satellite constellations provide an advantage over a geostationary satellite, where minimum theoretical latency is about 125 milliseconds, compared to 1 -4 milliseconds for a LEO satellite. A LEO satellite constellation can also provide more system capacity by frequency reuse across its coverage, with spot beam frequency use being analogous to the frequency reuse of cellular radio towers.

The Fig 1 drawn using the SaVi, the Satellite Visualization tool shows the Iridium Satellite constellation. The red circles are the orbits and the green dots represent the satellites. The satellites cross one another at the polar region of the Earth. The big white circles outline represents the coverage area of the corresponding satellites at that instant.

Fig 1 The Iridium Satellite Constellation on Earth

Satellite constellation coverage and geometrydetermining the minimum number of satellites needed to provide a service, and their orbits is a field in itself. A group of formation-flying satellites very close together and moving in almost identical orbits is known as a satellite cluster or Satellite formation flying.

• B.    Iridium Satellite Constellations

The name Iridium comes from a chemical element by the same name. The original plan for the constellation was to have 77 satellites which are equal to the atomic number for the chemical Iridium. Iridium constellation of 66 LEO satellites is the largest commercial satellite constellation in the world. The satellite constellation is cross- linked networked to be fully meshed leaving no gaps in service. The best known of the telecommunication satellite constellations is the Iridium constellation. It consists of 66 satellites (plus on-orbit spares) arranged in six orbital.

The satellites are equally spaced in each orbital plane, and the spacing in alternate planes is staggered so that the satellites form a grid. This grid covers the earth, so that a ground-based receiving unit can always reach a satellite, and allows satellite-to-satellite communication, so that a receiving unit at one point can communicate with a ground-based unit any-where else on earth

• C.    Software used for Satellite Communications Simulation:

Network Simulator (NS-2)

NS-2 is a discrete event network simulator. Monarch Group at CMU has extended NS-2 to support wireless networking. NS-2 offers simulation of different kinds of networks, modelling of different types of nodes, protocols, links, traffic and mobilities.NS2 can be used for exact satellite network simulation with a detailed modeling of radio frequency characteristics such as interference, fading, protocol interactions such as interactions of residual burst errors on the link with error checking codes, and second-order orbital effects like precession, gravitational anomalies, etc.

Satellite Handoff Modelling in NS-2

The non-geostationary characteristics and high speed movement of LEO Satellites, has raised to Satellite handoff modeling, which is a key component of LEO satellite network simulations. Transfer of connection to a new spotbeam or satellite is called handover . Various types of Handover in satellite systems are mentioned below.

Intra- Satellite hand-over

• •    Hand-over from one spot beam to another.

• •    Mobile station still in the footprint of the satellite, but in another cell

Inter-Satellite hand-over

• •    Hand-over from one satellite to another.

• •    Mobile station leaves the footprint of the satellite.

Gateway hand-over

• •    Hand-over from one gateway to another.

• •    Mobile station still in the footprint of a satellite, but gateway leaves footprint.

Inter-system hand-over

• •    Hand-over from one satellite network to a terrestrial cellular network.

The default Network visualization tool of NS-2 – the Network Animator (NAM) will not support satellite network visualization. But there are other open source softwares mentioned below which can be used to visualize satellite constellations.

• •    Sat-plot-scripts (perl scripts)

• •    SaVi (Satellite Constellations Visualization)

• •    Geomview

Sat-plot-scripts [4]

These Perl scripts can be used to visualize ns satellite constellation configurations, both an overall snapshot of the satellite positions at a given time and the path that a packet takes through the network. Original scripts were written by Tom Henderson, Daedalus Group, University of California at Berkeley. The Enhanced features, functionality, switches, map options, polar plots were written by Lloyd Wood, Centre for Communication Systems Research, University of Surrey.

SaVi [5] [6]

SaVi, the Satellite Visualization tool [5], is a computer program for visualizing and animating the movement of satellites and their coverage. This tool has been used for research in academic papers and also proven useful for demonstrating aspects of satellite constellations and their geometry, coverage and movement.

It has a graphical user interface which includes the following features:

• 1)    Three-dimensional     visualization of

satellites in orbit around the Earth

• 2)    Display of Satellites footprints on earth’s surface and computation of fraction of the Earth's surface covered by the constellation

• 3)    Simulation of a view of the satellites overhead from an arbitrary point on the Earth's surface.

Geomview [7]

Geomview is an open source interactive geometry viewing program built upon the Object Oriented Graphics Library. SaVi leverages Geomview for simple three-dimensional (3D) rendering and OpenGL texture mapping.

• III.    Tcp Congestion Algorithms

In satellite networks, TCP throughput decreases because the long propagation delays cause longer duration of the Slow Start phase during which the sender may not use the available bandwidth [3]; Further, it was initially designed to work in networks with low link error rates, i.e., all segment losses were mostly due to network congestion. As a result, the sender decreases its transmission rate each time a segment loss is detected. This causes unnecessary throughput degradation if segment losses occur due to link errors, as it is common in satellite networks.

• A.    Evaluated TCP Congestion Algorithms [11][13][14]

The TCP algorithms with respect to implementation point of view is categorized into 2 modes

• •    Split Mode

An intermediate router reveals the information in the TCP packet and process the packet to the destination. Both sender and receiver communicate with the intermediate router independently without the knowledge of the other end.

• •    End-to End Approach Mode

In this mode only the end hosts participate in flow control. The receiver provides feedback reflecting the network condition, and the sender makes decisions for congestion control.

In the End-to-End approach the ability to accurately determine the bandwidth is the key to better performance. The below mentioned algorithms is based on this approach.

End-to-End Approach

The congestion control mechanism is realized in 2 ways

•

•

Reactive Congestion Control – In this, the sender rectifies the congestion window when the network situation becomes marginal or has crossed the threshold.

Proactive Congestion Control – In this type, the feedbacks from the network, guide the sender to reallocate network resources in order to prevent congestion.

• B.    TCP Reno Congestion Control (Reno) [8][12]

TCP Reno is a Reactive approach, it implements the TCP’s AIMD (Additive Increase Multiplicative Decrease) mechanism of increasing the congestion window W by one segment per RTT (Round-Trip Time for each received ACK and halving the congestion window W for each loss event per RTT.

TCP Reno controls the congested window as follows

Increase

W = W + —

Decrease w = w - - w

• C.    Binary Increase Congestion control for TCP (BIC) [9]

(win in + win ax) wtarget =-------------               (3)

After the window grows to the mid-point, and if no packet loss occurs in the network, then it means that the network can still handle more traffic and thus BIC-TCP sets the mid-point to be the new minimum (wmin = w) and a new target is computed. This has an effect of growing the window really fast when the current window size is far from the available capacity of the path, and furthermore, if it is close to the available capacity (where we had the previous loss), it slowly reduces its window increment.

• D.    TCP Vegas congestion control( vegas)[8]

TCP Vegas is a Proactive approach which is Delay based TCP Congestion control algorithm. It emphasizes packet delay, rather than packet loss as a signal to determine the rate at which to send packets. It adopts a more sophisticated bandwidth estimation scheme. It uses the difference between Expected Throughput and Actual Throughput to estimate the available bandwidth in the network. The algorithm heavily depends on accurate calculation of the Base RTT. Base RTT is calculated as the minimum of all measured RTTs, it is commonly the RTT of the first segment sent by the connection.

If the network is not overflown by the traffic, the two parameters and its difference are calculated as follows:

, ,      , H'indou⁷ Size

Expected Throughput =

№ndou^- Size

Actual Throughput =--- z^z---

' Actual \ „

..Throughput,I'Ba5e RTT

/ Expected \ /

Difference = _,      ,    . - I ■

'.Throughput^ \

The idea is that when the network is not congested, the Actual Throughput will be close to the Expected throughput. Otherwise, the actual throughput will be smaller than the expected throughput. TCP Vegas, using this difference in throughputs, estimates the congestion level in the network and updates the window size accordingly. Note that this difference in the throughput can be easily translated into the difference between the window size and the number of acknowledged packets during the round trip time.

• IV.    Simulation and Analysis of IRIDIUM Satellite Constellation

• A.    Parameters of Iridium Satellite Constellation[10]

Table 1 Iridium Constellation Parameters

Parameter	Iridium
Altitude	780 km
Planes	6
Satellites per plane	11
Inclination (deg)	86.4
Interplane separation (deg)	31.6
Seam separation (deg)	22
Elevation mask (deg)	8.2
Intraplane phasing	Yes
Interplane phasing	Yes
ISLs per satellite	4
ISL bandwidth	25 Mb/s
Up/downlink bandwidth	1.5 Mb/s
Cross-seam ISLs	No
ISL latitude threshold (deg)	60
Queue length	50

The TCP connection Setup

In order to evaluate the effects of applying different congestion control algorithms in satellite network, the dumbbell network configuration in the following figure is used for the simulation with NS-2. A satellite network which is composed of lot of moving satellites of belonging to a satellite constellation is used to connect two distant ground terminals.

The diagram Fig 2 shows an instant of, part of the rapidly changing satellite constellation network. In our simulation, we established communication between two ground terminals. One terminal was setup at Berkeley, California (37.9 lat , -122.3 long) and the another terminal at Chennai, India (13.04 lat, 80.17 long).

The diagram Fig 2 The TCP/IP connection Between T1 and T2 explains the simulated satellite network connection. The ground terminal represented as T1 which simulates n TCP sources and T2 which simulates n TCP sinks. The TCP sources and sinks were connected (terminals T1 and T2) over the highly moving satellite nodes.

Fig 2 The TCP/IP connection Between T1 and T2

• B.    Simulation Parameters

Important Common Satellite Network Parameters

Table 2 : Common Satellite Network Parameters

Physical Layer Type	:   Phy/Sat
Link Layer	:   LL/Sat
Mac Type	:  Mac/Sat
Queue Type	:   DropTail
Queue Limit	:   50
TTL	:   32
Term Handoff Interval	:   10 ms
Satellite Handoff Interval	:   10 ms

Important Traffic Parameters :

Table 3 : Traffic Parameters

Type	:  Vegas, Reno and BIC
PacketSize	:   1448
Initial Window Size	:   30000
TCP Sources	:     3
TCP Sink	:     3
Ground Terminals	:    2
Application	:  FTP4

Under NS2, there is no visualization support (nam-network) animation for visualizing a satellite constellation. A tool called as “SatPlot Scripts” is used for visualizing satellite constellations. The Fig 3 is the output of SatPlot scripts which shows one snap shot of the communication instance. During simulation, one particular instance of our interest can be dumbed into a log file. The dump file will contain information about the satellite location and data path at that instance.

Sat Plot scripts will use those information and Project satellite locations and data paths on a standard world map

T1 Berkeley

T2 Chennai

Intermediate Hops (pink nodes)

Fig 3 The Path between T1 and T2 (on Iridium Constellation)

• C.    Performance Metrics

Contention Window(cwin)

To avoid collisions within a traffic category, the station counts down an additional random number of time slots, known as a contention window, before attempting to transmit data. If another station transmits before the countdown has ended, the station waits for the next idle period, after which it continues the countdown where it left off.

The contention window dynamics are more important in a TCP congestion control algorithm. The better contention window management provides better throughput and minimum end to end delay. So, ‘Time Vs cwin size’ is used as an evaluation metric.

Round Trip Time (RTT)

In telecommunications, the round-trip delay time (RTD) or round-trip time (RTT) is the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgment of that signal to be received. This time delay therefore consists of the transmission times between the two points of a signal.

The dynamics of round trip time reflects the behavior of TCP congestion control algorithm. The minimum round trip time provides better TCP performance. So, ‘Time Vs RTT’ is used as an evaluation metric.

End to End Delay(EED)

End-to-end delay refers to the time taken for a packet to be transmitted across a network from source to destination.

^dend-end -^W[^dtraiu + ^dprop + ^dprocJ         (⁷)

dend-end       =   end-to-end delay dtrans          = transmission delay dprop         =   propagation delay dproc          =   processing delay

N            =   Number of Links

It is the cumulative delay which includes transmission delay, propagation delay and processing delay across a network

Jitter or Packet delay variation (PDV)

Packet delay variation (PDV) is the difference in end-to-end one-way delay between selected packets in a flow with any lost packets being ignored The delay is specified from the start of the packet being transmitted at the source to the end of the packet being received at the destination. A component of the delay which does not vary from packet to packet can be ignored, hence if the packet sizes are the same and packets always take the same time to be processed at the destination then the packet arrival time at the destination could be used instead of the time the end of the packet is received.

Packet Delivery Fraction (PDF)

PDF is the ratio of received packets by the destination nodes to the total amount of data packets sent by the CBR sources. This metric tells us how reliable the protocol is. It gives the rate of loss which will be undergone by the transport protocol, which will then affect the maximum throughput the ad hoc network will be capable of supporting.

Where

P is the fraction of successfully delivered packets.

c      is the total number of flow or connection f is the unique flow id serving as index.

Rf is the count of packets received from flow f.

Nf is the count of packets transmitted to f.

Packet Delivery fraction is also referred as Packet Delivery Ratio (PDR).

Throughput

The throughput metric measures, how well the network can constantly provide data to the sink. The amount of packets successfully received at the destination. This is a fundamental measure of the performance of a network and therefore, an important factor to consider.

Dropped Packets.

The number of data packets that are not successfully sent to the destination during the transmission. Here we calculate time vs Number of Packets Dropped.

• V.    RESULTS AND DISCUSSIONS

The performance of the congestion control algorithms have been evaluated on Iridium satellite constellation.. The following line graphs and bar charts shows the comparative performance of the three algorithms vegas, reno and bic under Iridium satellite constellation.

The line graph (Fig 4) shows the contention window dynamics of the three congestion control algorithms under Iridium constellations. As shown in this chart, there is no change in contention window size in the case of Vegas.

Fig 4 The Contention Window Dynamics

As shown in the graph (Fig 5) , the round trip time in the case of Vegas was very minimum than reno and bic.

Fig 5 The RTT Dynamics

Fig 6 The Time Vs E2E Graph

The graph (Fig 7) shows the packet Delay. Vegas provided minimum packet delay compared to reno and bic.

Fig 7 The Packet Delay

The following (Table 4) tabulates the values of Iridium constellations with respect to TCP algorithms and its suitable metrics

Table 4 Performance Metrics

			Average
Transport ( ЛПСГР 11 9 ПАП         1 Conste at on	Throughput	Dropped	End –	Average
Protocol	(kbps)	Packets	to End	Delay
			Delay
Vegas	1756.26	0	159.86	20.32
Iridium        Reno	1610.30	104	370.47	23.39
Bic	1673.22	96	429.57	22.38

The bar chart (Fig 8) , shows the average performance in terms of end to end delay. In terms of end to end delay Vegas outperformed the other two algorithms.

The Analysis of End to End Delay and Jitter

As shown in the graph (Fig 6) , the performance in terms of end to end delay was very minimum in the case of Vegas.

The line graph (Fig 9) shows the performance in terms of jitter (jitter1 - Packet delay variation – ie, the difference in end-to-end delay). As shown in the following graph, the performance in terms of jitter was very minimum in the case of bic . In the case of Vegas, the jitter was very uniform but with respect to Reno it is the poor performer.

Fig 9 The Time vs Jitter1 (PDV) Graph

The bar chart (Fig 10) shows the average jitter. As shown in the chart, the performance in terms of jitter was good in the case of bic.

The Average Jitterl

Jitterl

Fig 10 The Average Jitter (PDV)

The Analysis of PDF, Throughput and Dropped Packets

The below mentioned bar chart (Fig 11) shows the performance in terms of Packet Delivery Function. With respect to PDF, the performance of vegas was better than the other two .

As shown in the (Fig 12) the PDF in the case of vegas is good because it is not at all dropping any packets.

Fig 12 The Average Throughput

The bar chart (Fig 13) shows the time vs packet dropped graph. According to the results, the dropped packet count in the case of vegas was zero. (the following graph was drawn from –; that is why we see a tiny bar for vegas which were actually representing 0)

According the above results, vegas is the overall good performer. Vegas is providing equal performance under different metrics in Iridium satellite constellation.

• VI.    CONCLUSION

According to the arrived results, the overall performance of vegas was good in Iridium constellations, Irrespective of the high end to end delay, the behavior of TCP/IP under Satellite network is somewhat resembling a high latency wired network. If we see the cwin and RTT dynamics, we can realize the similarity with wired network. Even though, the communication is happening wirelessly under rapid satellite movements, the behavior of TCP under satellite network is not like a mobile adhoc network. The reason for this behavior may be the hand-off and routing strategies used in the present satellite network systems – they were not like as in the case of normal adhoc network or wired network. So future works may address the ways to improve the behavior of a TCP congestion control algorithm by considering the hand-off and routing strategies of the satellite networking. TCP protocols have lower throughput, PDF and high end to end delay under satellite networks mainly due to the effects of long propagation delays and high link error rates Future works will address the ways to improve any of the selected TCP congestion algorithm for satellite networking.

Annexure: Visualization of Satellite Constellation

The simulated Iridium Constellation and Terminals- Plotted using “Sat-plot-scripts”

Satellite network at time 1.00

Packet seen from 1.0000 to 1.0699 duration 69.901

Fig 14 The Iridium Satellites, Links and the Communication hops(pink) between Terminals

The Coverage of Map Iridium Constellation – An instant Created using the tool “Savi” In the following figure, the green dots represents the locations of the satellites at that instant.

Fig 15 The Iridium Coverage Map