Performance Comparison of TCP Variants in Mobile Ad- Hoc Networks

Shared by: ijcsis

Stats

views:: 179
posted:: 4/9/2011
language:: English
pages:: 6

Public Domain

Document Sample

(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 3, March 2011

Performance Comparison of TCP Variants
In Mobile Ad- Hoc Networks

Mandakini Tayade Sanjev Sharma
Student, School of Information Technology Head, School of Information Technology
Rajiv Gandhi Prodyogiki Vishwavidyalaya Rajiv Gandhi Prodyogiki Vishwavidyalaya
Bhopal (M.P.) India Bhopal (M.P.) India
tayademandakini@gmail.com sanjeev@rgtu.net

Abstract— Mobile Ad-Hoc networks (MANETs) are regardless of operating system and hardware, to communicate
characterized by self organized, adaptive and multihop wireless with each other. One of the major properties of TCP is that it
link; frequently changing network topology due to mobility is able to provide a connection-oriented data transfer service
support. Transmission Control Protocol (TCP) is connection that is reliable to applications that require that no data is lost
oriented, reliable, congestion control and end to end mechanism.
and/or damaged in the communication process. TCP is used in
In TCP due to network congestion and link failure packets are
losses and TCP tries to control this loss. In this article we present conjunction with the Internet Protocol [3] (IP) which only
the performance comparison of existing TCP variants: TCP provides an unreliable connectionless data transfer service
Tahoe, Reno, Lite, and New Reno for mobile ad-hoc networks. between different hosts. To be able to provide connection-
The behavior of TCP was different depending on the type of TCP oriented reliable communication, TCP needs to implement
variants because of improper activation or missing of congestion mechanisms on top of IP.
control. This analysis and comparisons are necessary to be aware TCP in its traditional form was designed and
of which TCP implementation is better for a specific scenario. optimized only for wired networks. Extensions of TCP that
provide improved performance across wired and single-hop
Keywords- Mobile ad-ho; Adaptive; TCP; Congestion control;
Packet loss;
wireless networks. Since TCP is widely used today and the
efficient integration of an ad hoc wireless network with the
Internet is paramount wherever possible, it is essential to have
I. INTRODUCTION mechanisms that can improve TCP’s performance in ad hoc
The transport layer protocol performs an end-to-end wireless networks. This would enable the seamless operation
connection, end-to-end delivery of data packets, error of application-level protocols such as FTP, SMTP, and HTTP
detection, flow control, and congestion control for networks. across the integrated ad hoc wireless networks and the Internet
The transmission control protocol (TCP) is the most usable Although a number of studies have been conducted
transport layer protocol in the Internet today. It transports and protocol modifications suggested. The reason behind the
large number of the traffic on the Internet. Its reliability, end- variations of TCP is that each type possesses some special
to-end congestion control mechanism, byte stream transport criteria, such as the traditional TCP has become known as
mechanism, and its tactful and simple design have not only TCP Tahoe. TCP Reno adds one new mechanism called Fast
contributed to the success of the Internet, but also have made Recovery to TCP Tahoe [11]. TCP New Reno uses the newest
TCP an influencing protocol in the design of many of the other retransmission mechanism of TCP Reno [8].
protocols and applications. Its adaptability to the congestion in
the network has been an important feature leading to graceful
degradation of the services offered by the network at times of II. RELATED WORK
extreme congestion. The TCP protocol has been extensively This section describes the basic functions of TCP variants,
tuned to give good performance at the transport layer in the which can clearly substitute the TCP implementations such as
traditional wired network environment. However, TCP in its TCP Tahoe, TCP Reno and TCP Lite.
present form is not well-suited for mobile ad hoc networks
(MANETs) where packet loss due to broken routes can result A. TCP Tahoe
in the reverse invocation of TCP’s congestion control Tahoe refers to the TCP congestion control algorithm. TCP
mechanisms. Tahoe [14] is based on a principle of ‘conservation of
The Transmission Control Protocol [1, 2] (TCP) is packets’, i.e. if the connection is running at the available
the most used transport protocol in the Internet today. It is a bandwidth capacity then a packet is not injected into the
part of the TCP/IP protocol suite which allows computers, network unless a packet is taken out as well. TCP implements

165 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 3, March 2011
this principle by using the acknowledgements to clock Reno performs very well over TCP when the packet
outgoing packets because an acknowledgement means that a losses are small. But when we have multiple packet losses in
packet was taken off the wire by the receiver. It also maintains one window then RENO doesn’t perform too well .The reason
a congestion window CWND to reflect the network capacity is that it can only detect single packet losses. If there is
[3]. When congestion encounters it decrease over sending rate multiple packet drops then the first info about the packet loss
and reduced congestion window to one. However there are comes when we receive the duplicate ACK’s. But the
certain issues, which need to be resolved to ensure this information about the second packet which was lost will come
equilibrium. only after the ACK for the retransmitted first segment reaches
1. Determination of the available bandwidth. the sender after one RTT. Another problem is that if the
2) Ensuring that equilibrium is maintained. widow is very small when the loss occurs then we would
3) How to react to congestion never receive enough duplicate acknowledgements for a fast
The Tahoe TCP implementation added a number of new retransmit and we would have to wait for a coarse grained
algorithms and refinements to earlier implementations. The timeout. .Reno's Fast Recovery algorithm is optimized for the
new algorithms include Slow-Start, Congestion Avoidance case when a single packet is dropped from a window of data.
and Fast Retransmit [6]. The refinements include a
modification to the round-trip time estimator used to set
C. TCP LITE
retransmission timeout values [4] [5]. It isn’t very suitable for
high band-width product links because of the waiting timeout. TCP Lite is a service that provides a transport method
The problem with Tahoe is that it takes a complete that interrupts TCP in order to reduce the overhead involved in
timeout interval to detect a packet loss and in fact, in most session management in which no data is transmitted or
implementations it takes even longer because of the coarse received. TCP Lite reduces or eliminates pure TCP protocol
grain timeout. Also since it doesn’t send immediate ACK’s, it data units used in the set up and ACK while maintaining order,
sends cumulative acknowledgements, therefore it follows a integrity, reliability and security of traditional TCP. TCP lite
‘go back n ‘approach. Thus every time a packet is lost it waits uses big window and protection against wrapped sequence
for a timeout and the pipeline is emptied. This offers a major numbers. Lite performs over TCP same as Reno. But when
cost in high band-width delay product links. window increases it have some problems to maintain them.

B. TCP Reno III. SIMULATION ENVIRONMENT
TCP Reno [1] retains the basic principle of Tahoe, such as The evaluation of the TCP variants, qualnet 5.0 under the
slow starts and the coarse grain re-transmit timer. However it windows platform is used as the simulation tool. Initially the
adds some intelligence over it so that lost packets are detected number of nodes is 50, Simulation time was taken 200 seconds
earlier and the pipeline is not emptied every time a packet is and seed as 1.
lost. Reno requires that we receive immediate Table 1 Network simulation Parameter
acknowledgement whenever a segment is received. The logic
behind this is that whenever we receive a duplicate S. Parameter Values
acknowledgment, then his duplicate acknowledgment could No.
have been received if the next segment in sequence expected, 1 Area 1500x1500
has been delayed in the network and the segments reached 2 Number of nodes 10, 20 ,30 ,40 50
there out of order or else that the packet is lost 3 Application FTP
4 Mobility Model RWP
. If we receive a number of duplicate acknowledgements
then that means that sufficient time have passed and even if 5 Pause Time 5,10, 15,20,25, 30
Seconds
the segment had taken a longer path, it should have gotten to
6 Speed 5,10,15,20,25,30
the receiver by now. There is a very high probability that it Seconds
was lost. So Reno suggests an algorithm called ‘Fast Re- 7 Routing Protocol DSR
Transmit’. Whenever we receive3 duplicate ACK’s we take it
8 Node Placement Random
as a sign that the segment was lost, so we re-transmit the
segment without waiting for timeout. The basic algorithm is 9 Seed 1
presented as under: 10 TCP Variants TCP Reno, TCP Lite
, TCP Tahoe
1) Each time we receive 3 duplicate ACK’s we take that to 11 Data Packet Constant, 512 bytes
mean that the segment was lost and we re-transmit the packet size
segment immediately and enter ‘Fast- Recovery’
2) Sets ssthresh to half the current window size and also set 12 Simulation Time 200 Seconds
CWND to the same value.
3) For each duplicate ACK receive increase CWND by one. If
the increase CWND is greater than the amount of data in the All the scenarios have been designed in 1500m x 1500m area.
path then transmit a new segment else wait. Mobility model used is Random Way Point (RWP). In this

166 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 3, March 2011
model a mobile node is initially placed in a random location in
the simulation area, and then moved in a randomly chosen
direction between at a random speed between [SpeedMin, Node Speed vs Byte Received
SpeedMax]. The movement proceeds for a specific amount of
time or distance, and the process is repeated a predetermined 3000000

Byte Recevied
number of times. We choose Min speed = 5 m/s, Max speed = 2000000
30m/s, and pause time = 5s to 30s. TCP RENO
1000000
0 TCP LITE
IV. PERFORMANCE ANALYSIS AND RESULTS 5 10 15 20 25 30 TCP TAHOE
The performance problems of standard TCP over high
Congestion and delay paths are largely related with bulk data Node Speed (m/Sec)
transfers. It is understood that TCP flows, and indeed non-
TCP flows, constitute a large proportion of traffic in real Fig 2: Node Speed vs. Byte Received
networks. Performance analysis is done based on the
simulation results. The data’s are taken from the trace file and
the graphs are drawn.
Node Speed vs Packet Loss
A. Performance metrics used for this works are as follows:
60

Packet Loss
1) Throughput is the measure of the number of packet 40
successfully transmitted to their final destination per unit TCP RENO
time. It is the ratio between the numbers of sent packets vs. 20
received packets. 0 TCP LITE

5 10 15 20 25 30 TCP TAHOE
2) Byte Received is the measure of the no. of total bytes
received by targeted destination node. We can calculate it by Node Speed (m/Sec)
subtracting total received bytes by server in total sent bytes
by client.
Fig 3: Node Speed vs Packet Loss
3) Packet loss is the measure of total discarded packet due to
Figure 1, 2 and 3 are show the relationship between
corruption or due to packet drop. We can calculate it by
node speeds versus throughput, byte received and packet loss.
subtracting total received packets by server in total sent
The node speed for the analysis is taken from 5 to 30 seconds
packet by client.
the throughput measured for different node speeds and graph
is drawn.

Node Speed vs Throughput Pause time vs Throughput
200000 150000
Throughput

Throughput

100000 TCP RENO 100000
0 TCP RENO
TCP LITE 50000
5 10 15 20 25 30 TCP LITE
TCP TAHOE 0
5 10 15 20 25 30 TCP TAHOE
Node Speed in ( M/Sec)
Pause time (Sec)
Fig 1: Node Speed vs. Throughput

Fig 4: Pause time vs. Throughput

167 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 3, March 2011

Pause time vs Byte Received No. of Node vs Byte Received

3000000 3000000
Byte Received

Byte Received
2000000 2000000
TCP RENO TCP RENO
1000000 1000000
TCP LITE TCP LITE
0 0
5 10 15 20 25 30 TCP TAHOE 10 20 30 40 50 TCP TAHOE

Pause time (Sec) No. of Node

Fig 5: Pause time vs. Byte Received Fig 8: No. of Node vs Byte Received

No. of Node vs Packet Loss
50

Packet Loss
40
30
20 TCP RENO
10 TCP LITE
0
TCP TAHOE
10 20 30 40 50

No. of Node

Fig 6: Pause Time vs Packet Loss Fig 9: No. of Node vs Packet Loss

Figure 4, 5 and 6 shows the relationship between Figure 7, 8 and 9 shows the relationship between no.
Pause time versus throughput, byte received and packer loss. of node versus throughput, byte received and packer loss. The
The pause time for the analysis is taken from 5 to 30 seconds no. of node for the analysis is taken from 10 to 50 the
the throughput and packet loss measured for different pause throughput measured for different node and graph is drawn.
time and graph is drawn.
Here, for each protocol variant, for node speed, different
number of nodes, the throughput utilization and packet loss are
measured and the graphs are drawn.
No. of Node vs Throughput
Table 2 Best TCP based on Parameter
100000
S. No. Parameters The best TCP
Throughput

50000 1 Node Speed TCP RENO
TCP RENO
2 Pause Time TCP TAHOE
TCP LITE
0 3 No. of Node TCP TAHOE
10 20 30 40 50 TCP TAHOE

No. of Node
Table 2 shows that the selection of best TCP variant from
the selected list based on the analysis result for the three
Fig 7: No. of Node vs Throughput parameters like node speeds versus throughput and packet loss
, Pause time versus throughput and packer loss and no. of
node versus throughput and packer loss .

168 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 3, March 2011
It can be seen that TCP Reno is the best TCP about the protocol which one is better and suitable for packet
Variants, it can be taken into consideration based on node and link utilization in the network congestion and link failure
speeds versus throughput and packet loss.TCP Lite suitable for condition in Ad-hoc network environment because the
the variation in no. of node for both throughput and packet traditional TCP treat all packet losses due to the congestion, it
loss. does not treat from the link failure.
TCP Tahoe can be the best suited the selection of TCP In this paper we will make a comparison
variants based on Pause time versus throughput and packer between TCP Tahoe, TCP Reno and TCP Lite in varying
loss, under the condition that the pause time from 5 to 30 environment. The performance graphs are obtained and
seconds. analyzed by the TCP variants: TCP Tahoe, TCP Reno and
TCP Lite. The most of protocol shows better uses and many of
them shows poor responsiveness to changing network
V. COMPARISON OF TCP VARIANTS conditions and network utilization. Although there are various
protocols have been used, that can overcome the congested
A. TCP Tahoe and unreliable nature of network. Though there are various
It is much more robust in the face of lost packets. It can schemas and mechanisms proposed, there is no single
detect and retransmit lost packet much sooner than timeouts in mechanism that can overcome the unreliable nature of network
Tahoe. It also has fewer re-transmissions since it doesn’t in a reliable way .Here each and every variant has its own
empty the whole pipe whenever it loses packets. It is better at advantages and disadvantages to solve the networks problems
congestion avoidance and its modified congestion avoidance of TCP protocol.
and slow start algorithms measure incipient congestion and In short, any protocol will be effective based on the
very accurately measures the available bandwidth available parameters that are to be taken into consideration. To conclude
and therefore uses network resources efficiently and don’t this area is not completely explored to it maximum and still lot
contribute to congestion. It isn’t very suitable for high band- more research can be done towards establishing a basis for the
width product links because of the waiting timeout. development of new protocol.

VII. FUTURE WORK
B. TCP Reno
More than half of the coarse grained timeouts of Reno are
prevented by Vegas as it detects and re-transmits more than Our review suggests that in forthcoming efforts, analysis of
one lost packet before timeout occurs. It doesn’t have to TCP algorithm and comparisons of them. In future we explore
always wait for 3 duplicate packets so it can retransmit sooner. the effect of congestion avoidance algorithm on all TCP
It doesn’t reduce the congestion window too much variants and ad hoc routing protocol. In order to accurately
prematurely. The advantages that it has in congestion simulate the realistic congested network environment, there is
avoidance and bandwidth utilization over Tahoe exist here as a need to experiment with multiple TCP flows. Our future
well. It can suffer from performance problems when multiple work is to propose a new algorithm for congestion avoidance
packets are dropped from a window of data. in congested network to improve the TCP environment.

C. TCP Lite
Acknowledgment
TCP lite doesn’t have clear cut advantages over Reno. It is
as much as same like a TCP Reno. It detects and re-transmits I am deeply thankful to my HOD Dr. Sanjeev
more than one lost packet before timeout occurs. It can suffer Sharma, School of Information Technology, my supervisor
from performance problems packets are dropped in big Prof. Varsha Sharma and Prof. Santosh Sahu and my all
amount. It has better congestion avoidance and bandwidth friends whose help, stimulating suggestions and
utilization over Tahoe and Reno because TCP Lite provides encouragement helped me in all the time for my review.
big window and protection against wrapped sequence numbers
option, but it doesn’t reduce the congestion window too much
like Reno for congestion avoidance. It suggests better way for REFERENCES
fast retransmission when packet losses in network.
[1] A.Gurtov and S. Floyd, “Modelling wireless links or transport
Protocols,”ACM SIGCOMM, April 2004.
[2] K. Fall, S. Floyd “Simulation Based Comparison of Tahoe, Reno and
VI. CONCLUSION SACK TCP”, 1998.
[3] M. Mathis, J. Mahdavi,”Forward Acknowledgement: Refining
The comparison on existing TCP variants based on TCP Congestion Control” in Proceedings of ACM SIGCOMM,
1996.
throughput and packet loss analyzed from various
[4] W. Stevens, “TCP Slow Start, Congestion Avoidance Fast
experimental results obtained from qualnet 5.0. and described Retransmit Algorithm”, IETF RFC 2001, January 1997.

169 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 3, March 2011
[5] Van Jacobson,” Congestion Avoidance and Control”
SIGCOMM Symposium on communications Architectures AUTHORS PROFILE
and Protocols, rd Stevens: TCP/IP Illustrated, Volume 1: “The
Protocols”, Addison Wesley, 1994. Dr. Sanjeev Sharma is an Associate Professor
[6] Renaud Bruyeron, Bruno Hemon, Lixia Zhang: “Experimentations with and Head of School of Information Technology
TCP Selective Acknowledgment”, ACM SIGCOMM Computer in RGPV University of IT, Bhopal, Madhya
Communication Review, April 1988.
Pradesh, India. He is also Deputy Registrar
[7] S.Floyd, T.Henderson “The New-Reno Modification to TCP’s Fast (Academic) of RGPV University. He obtained his
Recovery Algorithm” RFC 2582, Apr 1999.
PhD degree from RGPV University. His research
[8] Ad Hoc Mobile Wireless Networks: Protocols and Systems, C.K. Toh,
interest is in the field of MANETs. He has
Springer Prentice Hall Publishers, ISBN 013 007 8174, 2001.
published over 150 National and International Journals &
[9] Ahmad Al Hanbali, Eitan Altman, Philippe Nain “A Survey of TCP
conferences various papers across India and other countries.
over Ad Hoc Networks “June, 2005.
[10] Yi-Cheng Chan, Chia-Liang Lin, and Fang-Chun Liu “A Competitive
Delay-Based TCP”, 2008 IEEE.
[11] Qualnet simulator version 3.10 user‘s manual by Scalable Network
Technologies, Inc, 2000, 2001.
Mandakini Tayade is a Student of Information
Technology in the Department of School of
[12] Qualnet simulator Scalable Network Technology, “QualNet4.0
simulator” Tutorial -Qualnet forum- www.scalable-networks.com.
Information Technology RGPV University of IT,
Bhopal, Madhya Pradesh, India. She received the
[13] Pawan Kumar Gupta “Throughput Enhancement of TCP over Wireless
Links”January2002.”http://etd.ncsi.iisc.ernet.in/bitstream/2 Bachelor and Master degrees in information
005/48/1/Throughput_Enhancement_Of_TCP_Over_Wireless_Links_Te Technology from Rajiv Gandhi Prodyogiki
xt.pdf”. Vishwavidyalaya in 2008 - 2010 respectively.
[14] Jinwen Zhu, Tianrui Bai , Performance of Tahoe, Reno, and SACK TCP During 2008 to 2010, she stayed in Research in MANETs. She has
at Different Scenarios, 27-30 Nov. 2006, On page(s): 1-4. published two papers in international journal of engineering science
[15] Chen. L.-J., Sun. T., Yang, G., Sanadidi, M. Gerla, M., AdHoc Probe: and technology and one paper in international conference in Calcutta.
Path Capacity Probing in Ad Hoc Networks, Proceedings of
the First International Conference on Wireless Internet WICON 05.

170 http://sites.google.com/site/ijcsis/
ISSN 1947-5500