Performance Evaluation of TCP variants under

different node speeds using OPNET Simulator

Chitranjan Sharma Bhudev Tyagi

DWCE DWCE
SGVU SGVU
Jaipur, India Jaipur, India
[email protected] [email protected]

Abstract— A mobile ad-hoc network (MANET) is a self Some attempts were previously made at describing TCP
starting dynamic network comprising of mobile nodes, where behavior in conventional wireless networks. However, research
each and every participant node voluntarily transmit the packets work showing the performance of most popular TCP variants
destined to some remote node using wireless (radio signal) in MANET have been lacking. A few studies have been carried
transmission. Past research efforts have denoted the problematic out on aspects relating to the performance evaluation of TCP
behaviour of traditional TCP agents in MANET environments variants under various node sizes and mobility conditions. In
and have proposed various remedies across the networking stack. this paper we experiment through analyzing the performance of
However, there has not been performance evaluation of different four TCP variants (Tahoe, Reno, New Reno and SACK) in
TCP agents under varying mobility conditions which takes into
terms of throughput, delay, upload response time; download
account past experiences in MANET evaluation. In this paper we
do performance evaluation of various TCP variants viz Tahoe,
response time and retransmission attempts within MANET.
Reno, New reno and SACK under varying node speed using Optimization of TCP in MANET investigated in several studies
simulation tool OPNET and evaluate its effect on Throughput, (e.g. [2], [6], and [7]). Likewise, some researches (e.g. [8], and
End to end delay, FTP download response time and FTP upload [9]) have addressed TCP performance problems caused by the
response time. route failures in a MANET. However, from their study, it is a
bit unclear as to at what extent the performance degradation of
Keywords— TCP, MANET, SACK, Reno, New-Reno, Tahoe TCP occurs in MANET. The experimental results are obtained
running simulation for a typical wireless network, not for a
MANET. One can observe the difference in that our study
I. INTRODUCTION explores the robustness of the TCP variant(s) by employing
Transmission Control Protocol (TCP)[1][11] is the heavy congestions with high load traffics for both FTP and
predominant Internet protocol and it carries approximately HTTP. The rest of the paper is structured as follows. Section 2
90% of Internet traffic in today’s heterogeneous wireless and deals with TCP variants under study. Section 3 describes
wired networks.TCP is reliable end to end protocol because MANET Simulation and Evaluation. Finally, the conclusions
TCP is trying to provide reliable data transmission between along with exploring avenues for future research are drawn in
two entities. TCP is extensively used connection oriented section 4.
transport layer protocol that provides reliable data packet
delivery over unreliable links.TCP primary purpose is to II. TCP VARIANTS
provide a connection oriented reliable data transfer service
between different applications to be able to provide these TCP is transport layer is the reliable connection orientated
services on top of an unreliable communication system. In TCP protocol that provides reliable transfer of data between the
we deals with multiplexing, data transfer, reliability flow nodes. It assure the reception of data at destination correctly
control, TCP segment, and congestion control and connection without any loss or damage [7]. The data has to be transmitted
management. TCP is independent of underlying network layers in the form of continuous stream of octets. The trustworthy
and therefore design of various TCP variants is based on the transfer of octets is achieved by using a sequence number to
properties of wired networks. However, In case of each octet. Another aspect of TCP is the three way handshakes
heterogeneous networks, TCP congestion control algorithms mechanism to establish a connection between the nodes.
may not perform well. The TCP protocol has been extensively Furthermore, TCP uses the port assignment as an addressing
tuned to give good performance at the transport layer in the mechanism to differentiate each connection for the cases of
traditional wired network environment. However, Traditional more TCP connection between nodes are required. After the
TCP is not well suited for mobile ad hoc networks (MANETs) introduction of first version of TCP, other variants are also
where packet loss due to broken routes can result in the introduced. The famous implementation of TCP called Tahoe,
counterproductive invocation of TCP’s congestion control Reno, New-Reno and SACK [3].
mechanisms [5].

978-1-4673-4529-3/12/$31.00 2012
c IEEE 302
A. TCP Tahoe sender uses additional incoming dup ACKs to clock subsequent
Tahoe refers to the TCP congestion control algorithm. TCP outgoing packets.
Tahoe is based on a principle of ‘conservation of packets’, In Reno, the sender' s usable window becomes where is the
means if the connection is running at the available bandwidth receiver' s advertised window, is the sender' s congestion
then a packet is not injected into the network unless a packet is window, and is maintained at until the number of dup ACKs
taken out. This principle implemented by TCP using the reaches tcprexmtthresh, and thereafter follows the number of
acknowledgements to clock outgoing packets because an duplicate ACKs. Thus, during Fast Recovery the sender
acknowledgement means that a packet was taken off the wire “inflates” its window by the number of dup ACKs it has
by the receiver and a congestion window CWND is also received, according to the observation that each dup ACK
maintained to reflect the network capacity [3]. indicates some packet has been removed from the network and
Congestion control plays an important role in flow control is now cached at the receiver. After entering Fast Recovery and
objective in transport layer protocol TCP. Congestion control retransmitting a single packet, the sender waits until half a
algorithm in TCP Tahoe is introduced by modifying original window of dup ACKs have been received, and then sends a
TCP using slow start, congestion avoidance and fast new packet for each additional dup ACK that is received. Upon
retransmits procedures [7]. Initially, slow-start procedure is receipt of an ACK for new data (called a “recovery ACK”) the
initiated after a packet loss had been detected with the sender exits Fast Recovery by setting number of dup ACK to 0.
congestion window set to 1. This worked as a TCP connection Reno's Fast Recovery algorithm is optimized for the case when
starts or re-starts to avoid the initial burst and the connection a single packet is dropped from a window of data. The Reno
might never get started. After the receipt of each sender retransmits at most one dropped packet per round-trip
acknowledgment, the congestion window CWD will be time. Reno significantly improves upon the behavior of Tahoe
increased by 1 and the congestion condition is increased as the TCP when a single packet is dropped from a window of data
number of packets sent is increased exponentially. When but can suffer from performance problems when multiple
congestion is encountered, the sending rate is decreased and the packets are dropped from a window of data.
CWD is reduced to 1 to start over again. In this way Tahoe can The increase in transmission rate is slower than that
detect packet losses by time-outs. Using occasional checks for observed in slow start adopted in Tahoe to relieve congestion
timeouts, costly repeated interrupt can be avoided. This can be [8]. Finally, the enhancement stops the communication path
used to retransmit packet before a packet loss is observed [7]. from going empty after fast retransmit procedure. This will
In congestion avoidance procedure Additive Increase avoid the need for the slow start procedure. Due to buffer
Multiplicative Decrease will be employed. The procedure is overflow, packet may be lost in congested link. In this case
started when congestion is noticed after packet loss is which, the sender will receive three duplicate
observed. In this case half of the current window will be saved acknowledgments or the sender retransmission timeout (RTO)
as a threshold value. Next, slow start phase will be operated timer will be expired. In the previous case, fast retransmit and
with CWD set to 1 until it reaches the threshold value. The recovery algorithm will be used by the sender to reduce the
CWD will be incremented linearly until it encounters a packet congestion window to half size.
loss. On the receipt of 3 duplicate ACK’s a sign of segment Next, the congestion window will be increased linearly and
lost will be indicated. The segment can be retransmitted can assist in congestion prevention. On the other hand for the
without waiting for timeout. In this case the Tahoe enters the case of single packet loss in a window, TCP Reno could
fast retransmit procedure [7]. Whenever segment loss is improve the performance by the use of fast recovery, whereas
indicated, fast retransmit procedure starts. This occurred for multiple packet loss, TCP Reno performance will be
whenever 3 duplicate ACK’s are received. degraded [8].

B. TCP RENO Next, slow start phase will be operated with CWD set to 1
until it reaches the threshold value. The CWD will be
The Reno retained the enhancements incorporated into incremented linearly until it encounters a packet loss. On the
Tahoe, but enhances the Fast Retransmit operation to include receipt of 3 duplicate ACK’s, a signal of segment loss is
Fast Recovery [12]. The new algorithm stops the indicated. The segment can be retransmitted without waiting
communication path (“pipe”) from going empty after Fast for timeout. In this case the Tahoe enters the fast retransmit
Retransmit and it avoids the need to Slow-Start to re-fill it after procedure [7]. Finally, whenever segment loss is indicated, fast
a single packet loss. Fast Recovery operation can be illustrated retransmit procedure started and it is occurred whenever 3
by assuming each duplicate ACK received represents a single duplicate ACK’s received.
packet having left the pipe. Therefore, during Fast Recovery
the TCP sender is able to make accurate estimates of the
C. TCP New-Reno
amount of outstanding data.
The New-Reno TCP in this paper includes a small change
Fast Recovery is entered by a TCP sender after receiving an to the Reno algorithm at the sender that eliminates Reno's wait
initial threshold of dup ACKs. This threshold, usually known for a retransmit timer when multiple packets are lost from a
as tcprexmtthresh, is generally set to three. Once the threshold window [10], [11]. The change concerns the sender' s behavior
of dup ACKs is received, sender retransmits single packet and during Fast Recovery when a partial ACK is received that
reduces its congestion window by one half. Instead of slow- acknowledges some but not all of the packets that were
starting, as is performed by a Tahoe TCP sender, the Reno outstanding at the start of that Fast Recovery time period.

2013 3rd IEEE International Advance Computing Conference (IACC) 303

Whereas in Reno, partial ACKs take TCP out of Fast Recovery represents the estimated number of packets outstanding in the
by “deflating” the usable window back to the size of the path. (This differs from the mechanisms in the Reno
congestion window. In case of New-Reno, partial ACKs do not implementation.) The sender only sends new or retransmitted
take TCP out of Fast Recovery. Alternatively, partial ACKs data when the estimated number of packets in the path is less
received during Fast Recovery are treated as an indication that than the congestion window. The variable pipe has to be
the packet immediately following the acknowledged packet in incremented by one when the sender either sends a new packet
the sequence space has been lost, and have to be retransmitted. or retransmits an old packet. It is to be decremented by one
Therefore, when multiple packets are lost from a single when the sender receives a dup ACK packet with a SACK
window of data, New-Reno can recover without any option reporting that new data has been received at the
retransmission timeouts and will retransmit one lost packet per receiver.
round-trip time till all of the lost packets from that window
have been retransmitted. New-Reno operates in Fast Recovery When a retransmitted packet is itself dropped out, the
until all of the data outstanding when Fast Recovery was SACK implementation detects the drop with a retransmit
initiated has been acknowledged. timeout. It retransmits the dropped packet and then slow-
starting. The sender is out of Fast Recovery when a recovery
The implementations of New-Reno and SACK TCP in our acknowledgment is received acknowledging all data that was
simulator also use a “maxburst” parameter. In our SACK TCP outstanding when Fast Recovery was entered. The SACK
implementation, the “maxburst” parameter value limits to four sender has special handling for partial ACKs (ACKs received
the number of packets that can be sent in response to a single during Fast Recovery that advance the Acknowledgment
incoming ACK, even if the sender’s congestion window would Number field of the TCP header, but do not take the sender out
allow more packets to be sent. In New-Reno, the “maxburst” of Fast Recovery).
parameter is set to four packets and two packets outside of Fast
Recovery and during Fast Recovery respectively, to accurately For partial ACKs, the sender decrements pipe by two
reproduce the behavior of Reno TCP during Fast Recovery. packets rather than one, as follows. When Fast Retransmit is
initiated, pipe is effectively decremented by one for the packet
TCP New-Reno is a modification of the TCP Reno through that was assumed to have been dropped, and then incremented
the use of retransmission process. This is occurred in the fast by one for the packet that was retransmitted. Thus,
recovery phase of the TCP Reno. In the improvement, TCP decrementing the pipe by two packets when the first partial
New Reno can detect multiple packet losses. Furthermore, ACK is received is in some sense “cheating”, as that partial
within the period of fast recovery, every unacknowledged ACK only represents one packet having left the pipe. However,
segment received and the fast recovery phase is terminated [9]. for any succeeding partial ACKs, pipe was incremented when
Having achieved this improvisation, several reductions in the the retransmitted packet entered the pipe, but was never
congestion window size will be avoided in the cases of decremented for the packet assumed to have been dropped.
multiple packet losses occurrence. Furthermore, the congestion Thus, when the succeeding partial ACK arrives, it does in fact
window size is set up to slow start threshold the congestion represent two packets that have left the pipe: the original
avoidance phase will be resumed and next segment will be packet (assumed to have been dropped), and the retransmitted
retransmitted when partial acknowledgment is received [8], packet. Because the sender decrements pipe by two packets
[10]. Here it is worth to mention that in partial rather than one for partial ACKs, the SACK sender never
acknowledgments, all remaining packets at the onset of the fast recovers more slowly than a Slow-Start.
recovery are not necessarily acknowledged properly [8], [11].
III. MANET SIMULATION AND EVALUATION
D. TCP SACK
In simulation there are eight different scenarios. First of all
The congestion control algorithms implemented in our we create a scenario with 60 mobile nodes with a static server
SACK TCP are a conservative extension of Reno's congestion employing TCP Reno. The mobile nodes are moving with
control, in which same algorithms is used for increasing and speed of 10 m/s with pause time 50 sec. This scenario is
decreasing the congestion window, and make minimal changes flooded with heavy http and ftp traffic. This scenario is
to the other congestion control algorithms. Adding SACK to duplicated three times and TCP variant is changed to New-
TCP does not change the basic underlying congestion control reno, SACK and Tahoe respectively. Then these four scenarios
algorithms. The SACK TCP implementation retains the are again duplicated and node speed is now set to 20 m/s. All
properties of Tahoe and Reno TCP of being robust in the the scenarios use DSR protocol for routing purpose. It is worth
presence of out-of-order packets and uses retransmit timeouts to mention that the campus area under investigation is 1000
as the recovery method of last resort. The main difference meters x 1000 meters dimension. Simulation time is set to 10
between the SACK TCP implementation and the Reno TCP minutes. The investigation involves the measurement of
implementation is in the behavior when multiple packets are Throughput, Delay, FTP upload response time and FTP
dropped from one window of data. download response time of the network in each of the above
As in Reno, the SACK TCP implementation enters Fast scenarios. Finally, the results drawn for each TCP variant with
Recovery when the data sender receives tcprexmtthresh varying node speed in the networks will be assessed. The
duplicate acknowledgments. The sender retransmits a packet as results of these simulation scenarios are as shown in Table 1 to
well as cuts the congestion window in half. During Fast Table 4.
Recovery, SACK maintains a variable called pipe that

304 2013 3rd IEEE International Advance Computing Conference (IACC)

A. Impact on Throughput As the results shows Reno achieves highest average
throughput of 175,848.88 and Tahoe lowest of 168,373.82
TABLE I. THROUGHPUT COMPARISON FOR TCP VARIANTS AT 10M/S whereas for New-Reno and SACK throughput is 170485.36
AND 20 M/S and 174318.02 respectively when node speed is 10 m/s.
Node speed When the node speed is increased to 20m/s Reno achieves
10 m/s 20 m/s lowest and Tahoe achieves highest average throughput of
TCP Variant
171,774.07 and 182,962.48 respectively. Whereas throughput
Tahoe 168,373.82 182,962.48 for New-Reno and SACK is 173769.05 and 178031.57
Reno 175,848.88 171,774.07
respectively.

New Reno 170,485.36 173,769.05 B. Impact on End to End Delay

SACK 174,318.02 178,031.57 In this sub-section, the routing performance is analyzed in
terms of end-to-end delay with the variations of node speeds.
The results are shown by the graphs in fig. 2(a) and 2(b).
As the results shows in low mobility scenario Tahoe
achieve lowest delay of about 14.9 millisecond but in high
mobility scenario New-Reno outperforms by achieving lowest
delay of 14.09 millisecond.

TABLE II. END TO END DELAY (AVERAGE) COMPARISON FOR TCP

VARIANTS AT 10M/S AND 20 M/S

Node speed
10 m/s 20 m/s
TCP Variant

Tahoe 14.9 18.1

Reno 16.6 16.6
New Reno 15.8 14.1
SACK 16.1 19.1

(a)

(b)
(a)
Figure 1. Throughput for node speed (a)10 m/s and for (b) 20 m/s

In this sub-section, the performance of the routing protocols

in terms of throughput is examined with respect to mobility of
the nodes. DSR routing protocol is used here for evaluation of
TCP variants performance evaluation. The graphical results are
shown in fig. 1(a) and 1(b).

2013 3rd IEEE International Advance Computing Conference (IACC) 305

 (b) (a)

Figure 2. End to End Delay for: (a) 10 m/s and (b) 20 m/s

C. Impact on Download Response Time

In this sub-section, the performance of Tahoe, Reno, New
Reno and SACK variants are evaluated in terms of download
response time. Fig. 3 demonstrates the download response time
of four TCP variants whilst the mobility rate is varied in the
network. In this case, X- axis and Y-axis in each figure stand
for simulation time and download response time, respectively.
The download performance is evaluated in terms of FTP traffic
with a file size of 50 Kbytes.
Fig. 3 demonstrates the download response time of three
TCP variants whilst the mobility rate is varied in the network.
In this case, X- axis and Y-axis in each figure stand for
simulation time and download response time, respectively. The
download performance is evaluated in terms of FTP traffic (b)
with a file size of 50 Kbytes.
Figure 3. Download response time at node speed: (a) 10 m/s and (b) 20 m/s
Fig. 3(a) depicts a scenario against a node speed of 10 m/s
where the lowest average download response time is observed At the beginning, the required response time is found to be
in Tahoe version, amounting to approximately 1.172 sec, quite high for all the three variants, about 5 sec in SACK, 3.8
followed by 1.755, 2.143 sec and 1.240 sec in SACK, Reno sec in Reno and 3.7 sec in New Reno. However, the response
and New Reno versions respectively. Similarly, in a 20 m/s time gradually falls with even a little fluctuation, which tends
network (Fig. 3(b)) New Reno accounting for the lowest to be stabilized towards the end of simulation.
download response time of about 1.71 sec, on average, while
Reno, Tahoe and SACK versions require nearly 5.56, 3.31 sec D. Impact on Upload Response Time
and 2.21 sec respectively, to download the above mentioned
FTP file. TABLE IV. UPLOAD RESPONSE TIME COMPARISON FOR TCP VARIANTS
AT 10M/S AND 20 M/S

TABLE III. DOWNLOAD RESPONSE TIME (AVERAGE) COMPARISON FOR Node speed
TCP VARIANTS AT 10M/S AND 20 M/S 10 m/s 20 m/s
TCP Variant
Node speed
10 m/s 20 m/s Tahoe 0.763 2.183
TCP Variant
Reno 1.125 1.123
Tahoe 1.172 3.317
Reno 2.143 5.517 New Reno 0.852 0.639
New Reno 2.140 1.708 SACK 0.805 1.460
SACK 1.755 2.214

306 2013 3rd IEEE International Advance Computing Conference (IACC)

 IV. CONCLUSIONS
In this paper the performance analysis of TCP variants
Tahoe, Reno, New-reno and SACK in MANET have been
investigated. The investigation considers the impact of
mobility, network http traffic load on TCP variants on the
network performance. In the performance assessment
throughput, delay, download response time and upload
response time are adopted for the whole scenarios considered.
The simulation using OPNET consider different scenarios that
attempt to cover all of the aspects on network evaluation
required. The results shows that for low mobility network (10
m/s) tahoe performs best for delay, download response time,
upload response time whereas reno gives maximum
throughput. As the mobility increases (20 m/s) new reno
performs best in terms of delay, download response time,
upload response time and tahoe shows maximum throughput.
(a) The investigation suggests the importance of intelligent system
usage in the network operating system. The intelligent system
will select the routing protocol according to the network
conditions that include TCP variant used, HTTP traffic load
type, network size and mobile speed.

REFERENCES
[1] J. Postel, “Transmission Control Protocol”, RFC 793, Sep 1981.
[2] Kevin Fall and Sally Floyd, “Simulation-based Comparisons of Tahoe,
Reno, and SACK TCP”.
[3] Md Nazmul Islam Khan, Rashed Ahmed and Md. Tariq Aziz, “A Survey
of TCP Reno, New Reno and SACK over Mobile ad-hoc Network”,
(IJDPS) Vol.3, No.1, January 2012
[4] Prof. Siddeeq, Y. Ameen and Ibrahim. A. Ibrahimi, “MANET Routing
Protocols Performance Evaluation with TCP Taho, Reno and New-
Reno”, International Journal of u- ande- Service, Science and
Technology, Vol. 4, No. 1, March 2011.
[5] Saher S. Manaseer, "On backoff mechanisms for wireless mobile ad hoc
networks," in Ph. D thesis, The Faculty of Information and
(b) Mathematical Sciences at University of Glasgow, Scotland, 2009, PP. 1-
156.
Figure 4. Upload response time for node speed: (a) 10 m/s and (b) 20 m/s [6] S. B. Lee, G. S. Ahn, and A.T. Campbell, "Improving UDP and TCP
performance in mobile ad hoc networks with INSIGNIA," IEEE
Communications Magazine, vol. 39, no. 6, pp. 156-165, August 2002.
The performance of different TCP versions is analyzed in
this sub-section in terms of their response time to uploading a [7] K.Kathiravan, S. Thamarai Selvi, and A.Selvam, "TCP performance
analysis for mobile adhoc network using on-demand routing protocols,"
FTP file of 50,000 bytes. The X-axis shows the simulation time Ubiquitous Computing and Communication Journal, pp. 370-376, April
while the Y-axis shows the upload response time (Fig. 4). 2007.
Looking at the figures, it becomes apparent that the upload [8] S. Papanastasiou, M. Ould-Khaoua, and L. Mackenzie, "On the
response time does not vary significantly with the increase in evaluation of TCP in MANETs," in Proceedings of the International
node speeds. In order to carry out uploading of a FTP file of Workshop on Wireless Ad Hoc, August 2005.
50,000 bytes, the maximum required time is estimated as 1.126 [9] A. Al Hanbali, E. Altman and P. Nain, "A survey of TCP over mobile ad
sec for Reno in a low mobility network, followed by 2.183 sec hoc networks," Research Report no. 5182, INRIA Sophia Antipolis
research unit, May 2004.
for Tahoe in a high mobile network, respectively.
[10] J. Hoe. “Start-up Dynamics of TCP's Congestion Control and Avoidance
For 20 m/s network, (Fig. 4(b)), TCP Reno, SACK and Schemes,”. Jun. 1995. Master's thesis, MIT.
New Reno require shorter response time, approximately [11] D.D. Clark and J. Hoe. “Start-up Dynamics of TCP's Congestion Control
1.123,1.460 and 0.639 sec respectively. and Avoidance Schemes,”. Technical report, Jun. 1995. Presentation to
the Internet End-to- End Research Group, cited for acknowledgement
When the upload response time against different mobility purposes only.
rates is analyzed (Figure 6.14b), again, the Reno variants are [12] V. Jacobson. “Modified TCP Congestion Avoidance Algorithm,”.
found to be of particular importance as they achieve the lowest Technical report, 30 Apr. 1990. Email to the end2end-interest Mailing
List, URL ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt.
response time in all the scenarios. On the other hand, the New
[13] OPNET Simulator, Available: http://www.opnet.com.
Reno is found to have taken relatively more time to upload a
file.

2013 3rd IEEE International Advance Computing Conference (IACC) 307