Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
Performance Comparison of TCP Variants in Mobile Ad- Hoc Networks

Performance Comparison of TCP Variants in Mobile Ad- Hoc Networks

Ratings: (0)|Views: 169 |Likes:
Published by ijcsis
Mobile Ad-Hoc networks (MANETs) are characterized by self organized, adaptive and multihop wireless link; frequently changing network topology due to mobility support. Transmission Control Protocol (TCP) is connection oriented, reliable, congestion control and end to end mechanism. In TCP due to network congestion and link failure packets are losses and TCP tries to control this loss. In this article we present the performance comparison of existing TCP variants: TCP Tahoe, Reno, Lite, and New Reno for mobile ad-hoc networks. The behavior of TCP was different depending on the type of TCP variants because of improper activation or missing of congestion control. This analysis and comparisons are necessary to be aware of which TCP implementation is better for a specific scenario.
Mobile Ad-Hoc networks (MANETs) are characterized by self organized, adaptive and multihop wireless link; frequently changing network topology due to mobility support. Transmission Control Protocol (TCP) is connection oriented, reliable, congestion control and end to end mechanism. In TCP due to network congestion and link failure packets are losses and TCP tries to control this loss. In this article we present the performance comparison of existing TCP variants: TCP Tahoe, Reno, Lite, and New Reno for mobile ad-hoc networks. The behavior of TCP was different depending on the type of TCP variants because of improper activation or missing of congestion control. This analysis and comparisons are necessary to be aware of which TCP implementation is better for a specific scenario.

More info:

Published by: ijcsis on Apr 10, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

04/10/2011

pdf

text

original

 
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 9, No. 3, March 2011
Performance Comparison of TCP VariantsIn Mobile Ad- Hoc Networks
Mandakini TayadeStudent, School of Information TechnologyRajiv Gandhi Prodyogiki VishwavidyalayaBhopal (M.P.) India
tayademandakini@gmail.com
Sanjev SharmaHead, School of Information TechnologyRajiv Gandhi Prodyogiki VishwavidyalayaBhopal (M.P.) India
sanjeev@rgtu.net 
Abstract
— Mobile Ad-Hoc networks (MANETs) arecharacterized by self organized, adaptive and multihop wirelesslink; frequently changing network topology due to mobilitysupport. Transmission Control Protocol (TCP) is connectionoriented, reliable, congestion control and end to end mechanism.In TCP due to network congestion and link failure packets arelosses and TCP tries to control this loss. In this article we presentthe performance comparison of existing TCP variants: TCPTahoe, Reno, Lite, and New Reno for mobile ad-hoc networks.The behavior of TCP was different depending on the type of TCPvariants because of improper activation or missing of congestioncontrol. This analysis and comparisons are necessary to be awareof which TCP implementation is better for a specific scenario.
Keywords- Mobile ad-ho; Adaptive; TCP; Congestion control;Packet loss;
I.
 
I
NTRODUCTION
The transport layer protocol performs an end-to-endconnection, end-to-end delivery of data packets, errordetection, flow control, and congestion control for networks.The transmission control protocol (TCP) is the most usabletransport layer protocol in the Internet today. It transportslarge number of the traffic on the Internet. Its reliability, end-to-end congestion control mechanism, byte stream transportmechanism, and its tactful and simple design have not onlycontributed to the success of the Internet, but also have madeTCP an influencing protocol in the design of many of the otherprotocols and applications. Its adaptability to the congestion inthe network has been an important feature leading to gracefuldegradation of the services offered by the network at times of extreme congestion. The TCP protocol has been extensivelytuned to give good performance at the transport layer in thetraditional wired network environment. However, TCP in itspresent form is not well-suited for mobile ad hoc networks(MANETs) where packet loss due to broken routes can resultin the reverse invocation of TCP’s congestion controlmechanisms.The Transmission Control Protocol [1, 2] (TCP) isthe most used transport protocol in the Internet today. It is apart of the TCP/IP protocol suite which allows computers,regardless of operating system and hardware, to communicatewith each other. One of the major properties of TCP is that itis able to provide a connection-oriented data transfer servicethat is reliable to applications that require that no data is lostand/or damaged in the communication process. TCP is used inconjunction with the Internet Protocol [3] (IP) which onlyprovides an unreliable connectionless data transfer servicebetween different hosts. To be able to provide connection-oriented reliable communication, TCP needs to implementmechanisms on top of IP.TCP in its traditional form was designed andoptimized only for wired networks. Extensions of TCP thatprovide improved performance across wired and single-hopwireless networks. Since TCP is widely used today and theefficient integration of an ad hoc wireless network with theInternet is paramount wherever possible, it is essential to havemechanisms that can improve TCP’s performance in ad hocwireless networks. This would enable the seamless operationof application-level protocols such as FTP, SMTP, and HTTPacross the integrated ad hoc wireless networks and the InternetAlthough a number of studies have been conductedand protocol modifications suggested. The reason behind thevariations of TCP is that each type possesses some specialcriteria, such as the traditional TCP has become known asTCP Tahoe. TCP Reno adds one new mechanism called FastRecovery to TCP Tahoe [11]. TCP New Reno uses the newestretransmission mechanism of TCP Reno [8].II.
 
RELATED WORK
 This section describes the basic functions of TCP variants,which can clearly substitute the TCP implementations such asTCP Tahoe, TCP Reno and TCP Lite.
A.
 
TCP Tahoe
Tahoe refers to the TCP congestion control algorithm. TCPTahoe [14] is based on a principle of ‘conservation of packets’, i.e. if the connection is running at the availablebandwidth capacity then a packet is not injected into thenetwork 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 outgoing packets because an acknowledgement means that apacket was taken off the wire by the receiver. It also maintainsa congestion window CWND to reflect the network capacity[3]. When congestion encounters it decrease over sending rateand reduced congestion window to one. However there arecertain issues, which need to be resolved to ensure thisequilibrium.
 
1. Determination of the available bandwidth.2) Ensuring that equilibrium is maintained.3) How to react to congestionThe Tahoe TCP implementation added a number of newalgorithms and refinements to earlier implementations. Thenew algorithms include Slow-Start, Congestion Avoidanceand Fast Retransmit [6]. The refinements include amodification to the round-trip time estimator used to setretransmission timeout values [4] [5]. It isn’t very suitable forhigh band-width product links because of the waiting timeout.The problem with Tahoe is that it takes a completetimeout interval to detect a packet loss and in fact, in mostimplementations it takes even longer because of the coarsegrain timeout. Also since it doesn’t send immediate ACK’s, itsends cumulative acknowledgements, therefore it follows a‘go back n ‘approach. Thus every time a packet is lost it waitsfor a timeout and the pipeline is emptied. This offers a majorcost in high band-width delay product links.
B.
 
TCP Reno
 
TCP Reno [1] retains the basic principle of Tahoe, such asslow starts and the coarse grain re-transmit timer. However itadds some intelligence over it so that lost packets are detectedearlier and the pipeline is not emptied every time a packet islost. Reno requires that we receive immediateacknowledgement whenever a segment is received. The logicbehind this is that whenever we receive a duplicateacknowledgment, then his duplicate acknowledgment couldhave been received if the next segment in sequence expected,has been delayed in the network and the segments reachedthere out of order or else that the packet is lost. If we receive a number of duplicate acknowledgementsthen that means that sufficient time have passed and even if the segment had taken a longer path, it should have gotten tothe receiver by now. There is a very high probability that itwas lost. So Reno suggests an algorithm called
Fast Re-Transmit’.
 
Whenever we receive3 duplicate ACK’s we take itas a sign that the segment was lost, so we re-transmit thesegment without waiting for timeout. The basic algorithm ispresented as under:
 
1) Each time we receive 3 duplicate ACK’s we take that tomean that the segment was lost and we re-transmit thesegment immediately and enter ‘Fast- Recovery’2) Sets ssthresh to half the current window size and also setCWND 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 thepath then transmit a new segment else wait.Reno performs very well over TCP when the packetlosses are small. But when we have multiple packet losses inone window then RENO doesn’t perform too well .The reasonis that it can only detect single packet losses. If there ismultiple packet drops then the first info about the packet losscomes when we receive the duplicate ACK’s. But theinformation about the second packet which was lost will comeonly after the ACK for the retransmitted first segment reachesthe sender after one RTT. Another problem is that if thewidow is very small when the loss occurs then we wouldnever receive enough duplicate acknowledgements for a fastretransmit and we would have to wait for a coarse grainedtimeout. .Reno's Fast Recovery algorithm is optimized for thecase when a single packet is dropped from a window of data.
C.
 
TCP LITE 
TCP Lite is a service that provides a transport methodthat interrupts TCP in order to reduce the overhead involved insession management in which no data is transmitted orreceived. TCP Lite reduces or eliminates pure TCP protocoldata units used in the set up and ACK while maintaining order,integrity, reliability and security of traditional TCP. TCP liteuses big window and protection against wrapped sequencenumbers. Lite performs over TCP same as Reno. But whenwindow increases it have some problems to maintain them.III.
 
SIMULATION ENVIRONMENT
 
The evaluation of the TCP variants, qualnet 5.0 under thewindows platform is used as the simulation tool.
Initially thenumber of nodes is 50, Simulation time was taken 200 secondsand seed as 1.
Table 1 Network simulation Parameter
S.No.Parameter Values
1 Area 1500x15002 Number of nodes 10, 20 ,30 ,40 503 Application FTP
 
4 Mobility Model RWP5 Pause Time 5,10, 15,20,25, 30Seconds6 Speed 5,10,15,20,25,30Seconds7 Routing Protocol DSR8 Node Placement Random9 Seed 110 TCP Variants TCP Reno, TCP Lite, TCP Tahoe11 Data Packet Constant, 512 bytespacket size12 Simulation Time 200 Seconds
All the scenarios have been designed in 1500m x 1500m area.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 inthe simulation area, and then moved in a randomly chosendirection between at a random speed between [
Speed 
Min
,
 SpeedMax
]. The movement proceeds for a specific amount of time or distance, and the process is repeated a predeterminednumber of times. We choose Min speed = 5 m/s, Max speed =30m/s, and pause time = 5s to 30s.IV.
 
P
ERFORMANCE ANALYSIS AND RESULTS
 The performance problems of standard TCP over highCongestion and delay paths are largely related with bulk datatransfers. It is understood that TCP flows, and indeed non-TCP flows, constitute a large proportion of traffic in realnetworks. Performance analysis is done based on thesimulation results. The data’s are taken from the trace file andthe graphs are drawn.
A.
 
Performance metrics used for this works are as follows:
1)
 
Throughput 
is the measure of the number of packetsuccessfully transmitted to their final destination per unittime. It is the ratio between the numbers of sent packets vs.received packets.2)
 
Byte Received 
 
is the measure of the no. of total bytesreceived by targeted destination node. We can calculate it bysubtracting total received bytes by server in total sent bytesby client.3)
 
Packet loss
is the measure of total discarded packet due tocorruption or due to packet drop. We can calculate it bysubtracting total received packets by server in total sentpacket by client.
01000002000005 10 15 20 25 30
Throughput
Node Speed in ( M/Sec)
Node Speed vs Throughput
TCP RENOTCP LITETCP TAHOE
 
Fig 1: Node Speed vs. Throughput
01000000200000030000005 10 15 20 25 30
Byte Recevied
Node Speed (m/Sec)
Node Speed vs Byte Received
TCP RENOTCP LITETCP TAHOE
 
Fig 2: Node Speed vs. Byte Received
02040605 10 15 20 25 30
Packet Loss
Node Speed (m/Sec)
Node Speed vs Packet Loss
TCP RENOTCP LITETCP TAHOE
Fig 3: Node Speed vs Packet Loss
 Figure 1, 2 and 3 are show the relationship betweennode speeds versus throughput, byte received and packet loss.The node speed for the analysis is taken from 5 to 30 secondsthe throughput measured for different node speeds and graphis drawn.
0500001000001500005 10 15 20 25 30
Throughput
Pause time (Sec)
Pause time vs Throughput
TCP RENOTCP LITETCP TAHOE
 Fig 4: Pause time vs. Throughput
 
167 http://sites.google.com/site/ijcsis/ISSN 1947-5500

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->