Performance Comparison of TCP Variants in Mobile Ad- Hoc Networks

Document Sample
Performance Comparison of TCP Variants in Mobile Ad- Hoc Networks Powered By Docstoc
					                                                                 (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