Performance Evaluation of TCP variants under
different node speeds using OPNET Simulator
Chitranjan Sharma
DWCE
SGVU
Jaipur, India
sharma.chitranjan@gmail.com
Abstract— A mobile ad-hoc network (MANET) is a self
starting dynamic network comprising of mobile nodes, where
each and every participant node voluntarily transmit the packets
destined to some remote node using wireless (radio signal)
transmission. Past research efforts have denoted the problematic
behaviour of traditional TCP agents in MANET environments
and have proposed various remedies across the networking stack.
However, there has not been performance evaluation of different
TCP agents under varying mobility conditions which takes into
account past experiences in MANET evaluation. In this paper we
do performance evaluation of various TCP variants viz Tahoe,
Reno, New reno and SACK under varying node speed using
simulation tool OPNET and evaluate its effect on Throughput,
End to end delay, FTP download response time and FTP upload
response time.
Keywords— TCP, MANET, SACK, Reno, New-Reno, Tahoe
I. INTRODUCTION
Transmission Control Protocol (TCP)[1][11] is the
predominant Internet protocol and it carries approximately
90% of Internet traffic in today’s heterogeneous wireless and
wired networks.TCP is reliable end to end protocol because
TCP is trying to provide reliable data transmission between
two entities. TCP is extensively used connection oriented
transport layer protocol that provides reliable data packet
delivery over unreliable links.TCP primary purpose is to
provide a connection oriented reliable data transfer service
between different applications to be able to provide these
services on top of an unreliable communication system. In TCP
we deals with multiplexing, data transfer, reliability flow
control, TCP segment, and congestion control and connection
management. TCP is independent of underlying network layers
and therefore design of various TCP variants is based on the
properties of wired networks. However, In case of
heterogeneous networks, TCP congestion control algorithms
may not perform well. The TCP protocol has been extensively
tuned to give good performance at the transport layer in the
traditional wired network environment. However, Traditional
TCP is not well suited for mobile ad hoc networks (MANETs)
where packet loss due to broken routes can result in the
counterproductive invocation of TCP’s congestion control
mechanisms [5].
978-1-4673-4529-3/12/$31.00 2012
c IEEE
Bhudev Tyagi
DWCE
SGVU
Jaipur, India
bhudevtyagi@gmail.com
Some attempts were previously made at describing TCP
behavior in conventional wireless networks. However, research
work showing the performance of most popular TCP variants
in MANET have been lacking. A few studies have been carried
out on aspects relating to the performance evaluation of TCP
variants under various node sizes and mobility conditions. In
this paper we experiment through analyzing the performance of
four TCP variants (Tahoe, Reno, New Reno and SACK) in
terms of throughput, delay, upload response time; download
response time and retransmission attempts within MANET.
Optimization of TCP in MANET investigated in several studies
(e.g. [2], [6], and [7]). Likewise, some researches (e.g. [8], and
[9]) have addressed TCP performance problems caused by the
route failures in a MANET. However, from their study, it is a
bit unclear as to at what extent the performance degradation of
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
explores the robustness of the TCP variant(s) by employing
heavy congestions with high load traffics for both FTP and
HTTP. The rest of the paper is structured as follows. Section 2
deals with TCP variants under study. Section 3 describes
MANET Simulation and Evaluation. Finally, the conclusions
along with exploring avenues for future research are drawn in
section 4.
II. TCP VARIANTS
TCP is transport layer is the reliable connection orientated
protocol that provides reliable transfer of data between the
nodes. It assure the reception of data at destination correctly
without any loss or damage [7]. The data has to be transmitted
in the form of continuous stream of octets. The trustworthy
transfer of octets is achieved by using a sequence number to
each octet. Another aspect of TCP is the three way handshakes
mechanism to establish a connection between the nodes.
Furthermore, TCP uses the port assignment as an addressing
mechanism to differentiate each connection for the cases of
more TCP connection between nodes are required. After the
introduction of first version of TCP, other variants are also
introduced. The famous implementation of TCP called Tahoe,
Reno, New-Reno and SACK [3].
302
A. TCP Tahoe
Tahoe refers to the TCP congestion control algorithm. TCP
Tahoe is based on a principle of ‘conservation of packets’,
means if the connection is running at the available bandwidth
then a packet is not injected into the network unless a packet is
taken out. This principle implemented by TCP using the
acknowledgements to clock outgoing packets because an
acknowledgement means that a packet was taken off the wire
by the receiver and a congestion window CWND is also
maintained to reflect the network capacity [3].
Congestion control plays an important role in flow control
objective in transport layer protocol TCP. Congestion control
algorithm in TCP Tahoe is introduced by modifying original
TCP using slow start, congestion avoidance and fast
retransmits procedures [7]. Initially, slow-start procedure is
initiated after a packet loss had been detected with the
congestion window set to 1. This worked as a TCP connection
starts or re-starts to avoid the initial burst and the connection
might never get started. After the receipt of each
acknowledgment, the congestion window CWD will be
increased by 1 and the congestion condition is increased as the
number of packets sent is increased exponentially. When
congestion is encountered, the sending rate is decreased and the
CWD is reduced to 1 to start over again. In this way Tahoe can
detect packet losses by time-outs. Using occasional checks for
timeouts, costly repeated interrupt can be avoided. This can be
used to retransmit packet before a packet loss is observed [7].
In congestion avoidance procedure Additive Increase
Multiplicative Decrease will be employed. The procedure is
started when congestion is noticed after packet loss is
observed. In this case half of the current window will be saved
as a threshold value. Next, slow start phase will be operated
with CWD set to 1 until it reaches the threshold value. The
CWD will be incremented linearly until it encounters a packet
loss. On the receipt of 3 duplicate ACK’s a sign of segment
lost will be indicated. The segment can be retransmitted
without waiting for timeout. In this case the Tahoe enters the
fast retransmit procedure [7]. Whenever segment loss is
indicated, fast retransmit procedure starts. This occurred
whenever 3 duplicate ACK’s are received.
B. TCP RENO
The Reno retained the enhancements incorporated into
Tahoe, but enhances the Fast Retransmit operation to include
Fast Recovery [12]. The new algorithm stops the
communication path (“pipe”) from going empty after Fast
Retransmit and it avoids the need to Slow-Start to re-fill it after
a single packet loss. Fast Recovery operation can be illustrated
by assuming each duplicate ACK received represents a single
packet having left the pipe. Therefore, during Fast Recovery
the TCP sender is able to make accurate estimates of the
amount of outstanding data.
Fast Recovery is entered by a TCP sender after receiving an
initial threshold of dup ACKs. This threshold, usually known
as tcprexmtthresh, is generally set to three. Once the threshold
of dup ACKs is received, sender retransmits single packet and
reduces its congestion window by one half. Instead of slow-
starting, as is performed by a Tahoe TCP sender, the Reno
2013 3rd IEEE International Advance Computing Conference (IACC)
sender uses additional incoming dup ACKs to clock subsequent
outgoing packets.
In Reno, the sender' s usable window becomes where is the
receiver' s advertised window, is the sender' s congestion
window, and is maintained at until the number of dup ACKs
reaches tcprexmtthresh, and thereafter follows the number of
duplicate ACKs. Thus, during Fast Recovery the sender
“inflates” its window by the number of dup ACKs it has
received, according to the observation that each dup ACK
indicates some packet has been removed from the network and
is now cached at the receiver. After entering Fast Recovery and
retransmitting a single packet, the sender waits until half a
window of dup ACKs have been received, and then sends a
new packet for each additional dup ACK that is received. Upon
receipt of an ACK for new data (called a “recovery ACK”) the
sender exits Fast Recovery by setting number of dup ACK to 0.
Reno's Fast Recovery algorithm is optimized for the case when
a single packet is dropped from a window of data. The Reno
sender retransmits at most one dropped packet per round-trip
time. Reno significantly improves upon the behavior of Tahoe
TCP when a single packet is dropped from a window of data
but can suffer from performance problems when multiple
packets are dropped from a window of data.
The increase in transmission rate is slower than that
observed in slow start adopted in Tahoe to relieve congestion
[8]. Finally, the enhancement stops the communication path
from going empty after fast retransmit procedure. This will
avoid the need for the slow start procedure. Due to buffer
overflow, packet may be lost in congested link. In this case
which, the sender will receive three duplicate
acknowledgments or the sender retransmission timeout (RTO)
timer will be expired. In the previous case, fast retransmit and
recovery algorithm will be used by the sender to reduce the
congestion window to half size.
Next, the congestion window will be increased linearly and
can assist in congestion prevention. On the other hand for the
case of single packet loss in a window, TCP Reno could
improve the performance by the use of fast recovery, whereas
for multiple packet loss, TCP Reno performance will be
degraded [8].
Next, slow start phase will be operated with CWD set to 1
until it reaches the threshold value. The CWD will be
incremented linearly until it encounters a packet loss. On the
receipt of 3 duplicate ACK’s, a signal of segment loss is
indicated. The segment can be retransmitted without waiting
for timeout. In this case the Tahoe enters the fast retransmit
procedure [7]. Finally, whenever segment loss is indicated, fast
retransmit procedure started and it is occurred whenever 3
duplicate ACK’s received.
C. TCP New-Reno
The New-Reno TCP in this paper includes a small change
to the Reno algorithm at the sender that eliminates Reno's wait
for a retransmit timer when multiple packets are lost from a
window [10], [11]. The change concerns the sender' s behavior
during Fast Recovery when a partial ACK is received that
acknowledges some but not all of the packets that were
outstanding at the start of that Fast Recovery time period.
303
Whereas in Reno, partial ACKs take TCP out of Fast Recovery
by “deflating” the usable window back to the size of the
congestion window. In case of New-Reno, partial ACKs do not
take TCP out of Fast Recovery. Alternatively, partial ACKs
received during Fast Recovery are treated as an indication that
the packet immediately following the acknowledged packet in
the sequence space has been lost, and have to be retransmitted.
Therefore, when multiple packets are lost from a single
window of data, New-Reno can recover without any
retransmission timeouts and will retransmit one lost packet per
round-trip time till all of the lost packets from that window
have been retransmitted. New-Reno operates in Fast Recovery
until all of the data outstanding when Fast Recovery was
initiated has been acknowledged.
The implementations of New-Reno and SACK TCP in our
simulator also use a “maxburst” parameter. In our SACK TCP
implementation, the “maxburst” parameter value limits to four
the number of packets that can be sent in response to a single
incoming ACK, even if the sender’s congestion window would
allow more packets to be sent. In New-Reno, the “maxburst”
parameter is set to four packets and two packets outside of Fast
Recovery and during Fast Recovery respectively, to accurately
reproduce the behavior of Reno TCP during Fast Recovery.
TCP New-Reno is a modification of the TCP Reno through
the use of retransmission process. This is occurred in the fast
recovery phase of the TCP Reno. In the improvement, TCP
New Reno can detect multiple packet losses. Furthermore,
within the period of fast recovery, every unacknowledged
segment received and the fast recovery phase is terminated [9].
Having achieved this improvisation, several reductions in the
congestion window size will be avoided in the cases of
multiple packet losses occurrence. Furthermore, the congestion
window size is set up to slow start threshold the congestion
avoidance phase will be resumed and next segment will be
retransmitted when partial acknowledgment is received [8],
[10]. Here it is worth to mention that in partial
acknowledgments, all remaining packets at the onset of the fast
recovery are not necessarily acknowledged properly [8], [11].
D. TCP SACK
The congestion control algorithms implemented in our
SACK TCP are a conservative extension of Reno's congestion
control, in which same algorithms is used for increasing and
decreasing the congestion window, and make minimal changes
to the other congestion control algorithms. Adding SACK to
TCP does not change the basic underlying congestion control
algorithms. The SACK TCP implementation retains the
properties of Tahoe and Reno TCP of being robust in the
presence of out-of-order packets and uses retransmit timeouts
as the recovery method of last resort. The main difference
between the SACK TCP implementation and the Reno TCP
implementation is in the behavior when multiple packets are
dropped from one window of data.
As in Reno, the SACK TCP implementation enters Fast
Recovery when the data sender receives tcprexmtthresh
duplicate acknowledgments. The sender retransmits a packet as
well as cuts the congestion window in half. During Fast
Recovery, SACK maintains a variable called pipe that
304 2013 3rd IEEE International Advance Computing Conference (IACC)
represents the estimated number of packets outstanding in the
path. (This differs from the mechanisms in the Reno
implementation.) The sender only sends new or retransmitted
data when the estimated number of packets in the path is less
than the congestion window. The variable pipe has to be
incremented by one when the sender either sends a new packet
or retransmits an old packet. It is to be decremented by one
when the sender receives a dup ACK packet with a SACK
option reporting that new data has been received at the
receiver.
When a retransmitted packet is itself dropped out, the
SACK implementation detects the drop with a retransmit
timeout. It retransmits the dropped packet and then slow-
starting. The sender is out of Fast Recovery when a recovery
acknowledgment is received acknowledging all data that was
outstanding when Fast Recovery was entered. The SACK
sender has special handling for partial ACKs (ACKs received
during Fast Recovery that advance the Acknowledgment
Number field of the TCP header, but do not take the sender out
of Fast Recovery).
For partial ACKs, the sender decrements pipe by two
packets rather than one, as follows. When Fast Retransmit is
initiated, pipe is effectively decremented by one for the packet
that was assumed to have been dropped, and then incremented
by one for the packet that was retransmitted. Thus,
decrementing the pipe by two packets when the first partial
ACK is received is in some sense “cheating”, as that partial
ACK only represents one packet having left the pipe. However,
for any succeeding partial ACKs, pipe was incremented when
the retransmitted packet entered the pipe, but was never
decremented for the packet assumed to have been dropped.
Thus, when the succeeding partial ACK arrives, it does in fact
represent two packets that have left the pipe: the original
packet (assumed to have been dropped), and the retransmitted
packet. Because the sender decrements pipe by two packets
rather than one for partial ACKs, the SACK sender never
recovers more slowly than a Slow-Start.
III. MANET SIMULATION AND EVALUATION
In simulation there are eight different scenarios. First of all
we create a scenario with 60 mobile nodes with a static server
employing TCP Reno. The mobile nodes are moving with
speed of 10 m/s with pause time 50 sec. This scenario is
flooded with heavy http and ftp traffic. This scenario is
duplicated three times and TCP variant is changed to New-
reno, SACK and Tahoe respectively. Then these four scenarios
are again duplicated and node speed is now set to 20 m/s. All
the scenarios use DSR protocol for routing purpose. It is worth
to mention that the campus area under investigation is 1000
meters x 1000 meters dimension. Simulation time is set to 10
minutes. The investigation involves the measurement of
Throughput, Delay, FTP upload response time and FTP
download response time of the network in each of the above
scenarios. Finally, the results drawn for each TCP variant with
varying node speed in the networks will be assessed. The
results of these simulation scenarios are as shown in Table 1 to
Table 4.
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)


(a)
(b)
Figure 4. Upload response time for node speed: (a) 10 m/s and (b) 20 m/s
The performance of different TCP versions is analyzed in
this sub-section in terms of their response time to uploading a
FTP file of 50,000 bytes. The X-axis shows the simulation time
while the Y-axis shows the upload response time (Fig. 4).
Looking at the figures, it becomes apparent that the upload
response time does not vary significantly with the increase in
node speeds. In order to carry out uploading of a FTP file of
50,000 bytes, the maximum required time is estimated as 1.126
sec for Reno in a low mobility network, followed by 2.183 sec
for Tahoe in a high mobile network, respectively.
For 20 m/s network, (Fig. 4(b)), TCP Reno, SACK and
New Reno require shorter response time, approximately
1.123,1.460 and 0.639 sec respectively.
When the upload response time against different mobility
rates is analyzed (Figure 6.14b), again, the Reno variants are
found to be of particular importance as they achieve the lowest
response time in all the scenarios. On the other hand, the New
Reno is found to have taken relatively more time to upload a
file.
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.
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
Mathematical Sciences at University of Glasgow, Scotland, 2009, PP. 1-
156.
[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.
[7] K.Kathiravan, S. Thamarai Selvi, and A.Selvam, "TCP performance
analysis for mobile adhoc network using on-demand routing protocols,"
Ubiquitous Computing and Communication Journal, pp. 370-376, April
2007.
[8] S. Papanastasiou, M. Ould-Khaoua, and L. Mackenzie, "On the
evaluation of TCP in MANETs," in Proceedings of the International
Workshop on Wireless Ad Hoc, August 2005.
[9] A. Al Hanbali, E. Altman and P. Nain, "A survey of TCP over mobile ad
hoc networks," Research Report no. 5182, INRIA Sophia Antipolis
research unit, May 2004.
[10] J. Hoe. “Start-up Dynamics of TCP's Congestion Control and Avoidance
Schemes,”. Jun. 1995. Master's thesis, MIT.
[11] D.D. Clark and J. Hoe. “Start-up Dynamics of TCP's Congestion Control
and Avoidance Schemes,”. Technical report, Jun. 1995. Presentation to
the Internet End-to- End Research Group, cited for acknowledgement
purposes only.
[12] V. Jacobson. “Modified TCP Congestion Avoidance Algorithm,”.
Technical report, 30 Apr. 1990. Email to the end2end-interest Mailing
List, URL ftp://ftp.ee.lbl.gov/email/vanj.90apr30.txt.
[13] OPNET Simulator, Available: http://www.opnet.com.
307