See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/256874285

Experimented Goodput Measurement of

Standard TCP Versions over Large-Bandwidth
Low-Latency Bottleneck

Article January 2012

CITATION READS

1 645

3 authors, including:

Dr.Ghassan A. Abed Mahamod Ismail

Ministry of Science and Technology, Iraq National University of Malaysia
32 PUBLICATIONS 86 CITATIONS 562 PUBLICATIONS 1,450 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Energy Efficient Wireless Sensor Network for Monitoring of Physiological and Biomechanical Parameters
in High Performance Cycling View project

Pilot Contamination and its Effect Towards Massive-MIMO Capacity in Fifth Generation (5G) Wireless
Transmission View project

All content following this page was uploaded by Dr.Ghassan A. Abed on 16 February 2017.

The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG 212

Experimented Goodput Measurement of

Standard TCP Versions over
Large-Bandwidth Low-Latency Bottleneck
Ghassan A. Abed, Mahamod Ismail, and Kasmiran Jumari

AbstractGoodput of Transmission Control Protocol (TCP) is the number of useful data bits, transferred by the network
elements to a certain destinations, per unit of time. In communications networks, network layer, transport layer, and occasionally
data link layer protocol overhead is involved in the throughput, but is excluded from the goodput. Goodput is constantly lesser
than the throughput where the throughput means the gross bits rate which is physically transmitted, that mostly is lesser than
network access connections rapidity (the link bandwidth or the link capacity). In other side, TCP flow control, congestion
avoidance, and slow-start may possibly cause a poorer goodput than the maximum throughput. This article provide an
experimented results to the goodput measurement for six TCP source variants, Tahoe, Reno, Newreno, Sack, Fack, and Vegas.
The goodput analysis based on using a specific network topology with large-bandwidth and low-latency bottleneck using
Network Simulator 2 (NS-2). The obtained results showed the huge differences among the measured goodput for these TCPs.

Index Terms Goodput, TCP, NS-2, MSS.

1 INTRODUCTION

G OODPUT is defined as the sum of single packets

delivered to a finale host in a given time period, as
opposed to the overall number of packets trans-
In the last years, computer networks and mobile cellu-
lar systems have qualified incredible evolution and a lot
of computers and other user equipments become linked
ferred in a given time period that includes the retransmit-
together with most mutual protocol stack used being TCP.
ted packets. The rationale behind measuring the goodput
Currently, it is hard to recognize the congestion control
is that the end operators of TCP flow are concerned with
mechanisms that are applied by different engines in In-
transferring single packets and do not care about the
ternet. The header of TCP does not deliver any facts for
number of retransmissions cycles executed by the TCP
them. One more imperative problem is the manner that
source [1]. Let's say, if a file is transmitted, the goodput
these mechanisms are employed in diverse operating sys-
that the operator experiences correspond to the size of file
tems [4]. The greatest universal transport protocol in-
in bits divided by the file transferring period of time.
volved is the TCP and in the original accomplishment of
Through the previous two decades, several of mecha-
TCP, a very small number of variants were done to mini-
nisms were proposed to enhance the standard TCP ver-
malize the congestion in network path. Employment used
sions, Tahoe and Reno. Afterward Jacobson [2] introduced
accumulative confident acknowledgements and the expi-
the his algorithm of congestion control, then TCP devel-
ration of a retransmission timer to afford reliability based
opment grow into actual dynamic and many algorithms
on a modest go-back-n model. Some successive variants
have been assumed for congestion control to enhancing
of TCP grounded on the mechanisms of congestion con-
the stability, and bandwidth sharing among flows over
trol and avoidance have been proposed and established
wired and wireless networks. Actually, currently TCP is
[5]. The object beyond the differences of TCP is that every
not fit appropriate for wireless networks due to losses
variant takes certain singular principles. The prime TCP
resulted from using radio channels and the problems are
has been called by TCP Tahoe. While TCP Reno comple-
misread as indication of congestion by recent TCP struc-
ments new technique to improve congestion control of
tures and leading to an unnecessary decreasing of the
Tahoe, this mechanism called fast recovery. The newest
transmission rate. Therefore, TCP needs additional con-
retransmission algorithm was added to Reno to get new
nection layer protocols like using split connections or reli-
TCP termed as Newreno. Fack TCP is a Reno but uses
able link layer approach to professionally work in wire-
forward acknowledgment technique. The usage of Sacks
less links [3].
allows to the receiver to indicate some extra segment that
received with non-order during single duplicate ACK,
Ghassan A. Abed is PhD candidate in Department of Electrical, Elec- while TCP Vegas assumes its individual exclusive ap-
tronic, and Systems Engineering Faculty of Engineering and Built Envi- proaches for congestion control [6].
ronment, National University of Malaysia, UKM.
Prof. Dr. Mahamod Ismail is with Faculty of Engineering and Built Envi-
ronment, National University of Malaysia, UKM.
Prof. Dr. Kasmiran Jumari is with Faculty of Engineering and Built Envi-
ronment, National University of Malaysia, UKM.
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG
TCP congestion control algorithms are the leading ob-
ject to using the networks applications successfully in
spite of source bottlenecks and mostly impulsive the ac-
cess patterns of users. TCP Reno, Sack, Tahoe, Newreno,
Fack and Vegas, are represent the source TCP variants
and each variants support different congestion control
algorithm. The base of TCP congestion control is
grounded on Additive Increase Multiple Decrease
(AIMD) algorithm, by halving the window size when
congestion window having a loss in packet, and growing
the window in one segment for every Round Trip Time
(RTT).
The second module of congestion control is the re-
transmission timer, containing the exponential bake-offs
of the retransmit timer if the packet that retransmitted is
dropped. The third essential module is the slow-start
mechanism for the primary exploratory for existing
bandwidth.
The other congestion control mechanism is the clock-
ing of ACK. Everywhere the acknowledgments arrived to
the sender is used to clock-out the transmission for the
new next packet. The TCP source variants discussed here,
where all share the many features like slow-start, except
TCP Vegas, and all follow to the fundamental basis of
slow-start, AIMD, retransmit timers, and clocking of
ACK.
2 TCP VARIANTS BACKGROUND
There are many TCP variants that modified and devel-
oped with respectively with the communications needs.
Most of TCP current versions are include set of algo-
rithms which built to control the congestion in critical
links of network with maintaining the network through-
put [7]. In present years, TCP has been faced the fast
growth in internet in parallel with the demand increasing
to transfer the media on high speed links supported TCP.
In order to improve its performance TCP cuts down the
size of its congestion window resulted in further per-
formance degradation. This is a more serious problem in
bursty and highly mobile networks which have rapid
topological changes [8]. TCP provides division for se-
quenced data stream into packets, confirms the packets
delivery with the possibility of losing the IP layer loses,
retransmit, reorders, or packets duplication, and monitor-
ing the network band capacity to avoiding congestions.
TCP protocol can provide over two end points connec-
tion, flow rate controlling with bidirectional link and data
reliability [9].In addition, each TCP sender can regulates
the size of the congestion window using the congestion
control mechanism and the TCP can update and dynami-
cally regulate the window size depending on the packets
ACK or by indicates the packets losses when occur.
213
If the congestion window has constant value, the ACK
timing of the sent packets will depend on the ACK of the
first set of packets (early packets). TCP sliding window
depend on ACK clock which calculate the sender flow
rate and when RTT changed with different values, the
sliding window will determine the mean sending rate of
complete window per average RTT. The transmission
window size controlled by dependence on the ACKs re-
ceived each RTT and these parameters indicate the gen-
eral differences between TCP versions. The main function
of TCP window control is to obtain high packets rate with
minimum losses by avoiding network overloading in the
same time to provide optimum sharing to the network
bandwidth among connections. The optimum bandwidth
sharing can changed because the varying amounts of
overcrowding between traffics over the network, also it
because the varying in network itself like the updates in
routing or the time-varying capacity over radio links [9].
TCP Tahoe and TCP Reno are mostly applied over
many wireless applications because of the effective con-
gestion control mechanisms. These mechanisms provide
varying in size of congestion window depending on ACK
status, thus when packets acknowledged the window size
is increased and decreased when detect lost in packets. In
TCP Tahoe, Reno, and Vegas, the congestion avoidance
phase algorithm permit to the window size to increase by
one segment every RTT. This increment stop when the
window size reaches the congestion point and that will
stimulates the window size to decrease and slow-down to
the next phase.
Basically, TCP seeks to provide reliability to data
transmitted between two hosts. TCP is trying to provide
reliable data transmission between two entities. TCP ap-
plies set of rules to handle lost in packets resulted from
physical errors in transmission or because of the conges-
tion in cross traffics [4]. In recent days, the need to pro-
vide reliable data transmission over Internet traffics or
cellular mobile systems becomes very important. TCP
represents the prevailing protocol that provide reliability
to data transferring in all end-to-end data stream services
on the Internet and many of new networks. Usually, its
not easy to determine the available bandwidth for TCP
packets flow. In fact, its very complex problem due to the
effects of the congestion control of TCP and the network
dynamics. These two factors make the proceedings of
exact allocation for the packets flow complicated. The
approved mechanism to detect the optimum bandwidth
to send packets from TCP sender is congestion control
[10]. The understood of TCP behavior and the approaches
to enhance the performance of TCP in wireless channels
have been many difficulties and challenges. In parallel
with this, considerable researches dealt with in detail
many proposed development and mechanisms to raise
the efficiency of the performance of TCP, some of these
problems already solved, but others are still open [11].
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG 214

The object behind the differences of TCP is that each TABLE 1

type has some distinct criteria such as the base TCP has SIMULATION PARAMETERS
become known as TCP Tahoe. TCP Reno adds one new
mechanism called fast recovery to TCP Tahoe. Newreno Parameter Value
uses the newest retransmission mechanism of TCP Reno. Number of Source nodes 4
The use of Sacks permits the receiver to specify several Number of Source nodes 4
additional data packets that have been received out of Number of Routers 2
order within one dupack. TCP Vegas proposes its own Bandwidth of Bottleneck (R1- 100 Mbps
unique retransmission and congestion control strategies. R2)
TCP Fack is Reno TCP with forward acknowledgment Propagation delay of all links 3 msec
[12]. Bandwidth of Source Nodes 10 Mbps
(S - R1)
Bandwidth of Destination 10 Mbps
3 NETWORK TOPOLOGY AND SIMULATION Nodes (D - R1)
PARAMETERS Packet size 536,1460 Bytes
As mentioned before, the experiments performed using Max. window size 128 packets
NS-2 simulator [13] and grounded on using Tcl script. The Queue scheme Drop-Tail
proposed topology included four source nodes linked to tcpTick 0.5sec
corresponding four nodes as destination nodes through Queue size 64 packets
two routers with single bottleneck. The propagation delay Simulation time 11sec
of all topology links set to 3 msec while the bandwidth of TCP protocol Tahoe, Reno, Ne-
the source and destination nodes set to 10 Mbps except wreno, Vegas, Sack,
the bottleneck which is set to 100 Mbps as shown in Fig.1 and Fack
where that achieved the large-bandwidth concept.

In fact, the large-bandwidth low-latency bottleneck repre-
sents the main link in next generation network such as
Long Term Evolution (LTE) networks, where the goodput
of standard TCPs can give a premium evaluation to the
performance of these variants over next generation net-
works. The simulation and links parameters are briefed in
Table 1.
The nodes groups S and D are represented the TCP send-
er and receiver respectively, and the queue size between
them is set to 64 packets while the queuing type is chose
to be DropTail. In other hand, the maximum bound of
TCP window size is set to 128 packets and tcpTick to 0.5
second where tcpTick is the timer clock granularity for
measuring RTT intervals (the default value 0.1 sec).

Fig. 1. Proposed Network Topology for Goodput Measurements

JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG 215

The general concept of TCP Goodput, that its measure

the total of TCP payload bytes per second that the system
under test can transmit and receive between its ports and
the Maximum Segment Size (MSS). Therefore, the maxi-
mum segment size effect on the goodput behaviour, that's
why, the experiment separately, used two segment sizes,
536 Bytes and 1460 Bytes to achieve high accuracy to the
estimated goodput. At last, the simulation duration is
fixed to 11sec for each experiment (when MSS= 536 Bytes
and when MSS=1460 Bytes).

4 RESULTS AND DISCUSSION

As explained previously, the goodput measurement based
on two trials, the first when MSS equal to 536 Bytes and the Fig. 2. Demonstration of Different TCPs Goodput Measurements
second when it 1460 Bytes and each experiment test the (MSS=536 Bytes).
goodput for Tahoe, Reno, Newreno, Sack, Fack, and Vegas.
That because the tests script measures the goodput for each
MSS value separately and the MSS changed for each ex-
periment.

The full results of the goodput measuring over the pro-

posed topology for TCP source variants are shown in Table 2
and Table 3 while the results are demonstrated in the column
chart in Fig. 2 and Fig. 3.

TABLE 2
RESULTS OF DIFFERENT TCPS GOODPUT
MMS=536 BYTES

TCP Goodput (Mbps)

Tahoe 18.220
Reno 21.936 Fig. 3. Demonstration of Different TCPs Goodput Measurements
Newreno 25.044 (MSS=1460 Bytes).
Vegas 8.640
Sack 22.110
Fack 1.369 From these results, Fack TCP provides poorer goodput in
both trials, in spite of the goodput for Fack TCP improved
when MSS=1460 Bytes, this due to the slow congestion con-
trol mechanism used with Fack where it cannot covering the
packet losing and after each loss, the congestion window
TABLE 3 initiated from the initial value and increase the window
RESULTS OF DIFFERENT TCPS GOODPUT again. In other side, Newreno perform better than other TCP
MMS=1460 BYTES variants where that because the intelligent congestion con-
trol mechanism used in Newreno, where the combination of
four phases, slow-start, congestion avoidance, fast recovery,
TCP Goodput (Mbps) and fast retransmit assist Newreno to covering the packet
Tahoe 18.220 dropping. In addition, after packet loss, the congestion con-
Reno 21.936 trol start form the half window size and no need to start
Newreno 25.044 from the initial window level where all this features assisted
Vegas 8.640 Newreno to give high goodput. Reno showed a reasonable
Sack 22.110 goodput compared with other variants but the degradation
Fack 1.369 in Reno goodput is because Reno cannot perform well with
high packet loss rate, where this situation expected in our
simulation.
JOURNAL OF COMPUTING, VOLUME 4, ISSUE 5, MAY 2012, ISSN 2151-9617
https://sites.google.com/site/journalofcomputing
WWW.JOURNALOFCOMPUTING.ORG
Tahoe and Sack (Sack is improved Reno version) per-
formed a critical goodput, where Sack used the features of
Reno to cover the expected packet loss while Tahoe limitedly
covered the packet loss due to Tahoe used fast recovery but
the fast retransmit not included in the congestion control
mechanism. In Vegas, and because it used a special conges-
tion control approach, Vegas can give high throughput but
cannot give a reasonable goodput. This due to the conges-
tion control of Vegas estimate the congestion point according
to the current and expected window size, so the packet loss
become lesser than other TCP variants but the goodput ro-
mans poor as shown in graphical demonstration of the ex-
perimented results with two trials, one when MSS=536 Bytes
and the other when MSS=1460 Bytes.
5 CONCLUSION
This paper provided and experimented results to the
goodput for six TCP source variants over large-
bandwidth and low-latency bottleneck of 100 Mbps and 3
msec as a bandwidth and propagation delay. The TCP
variants showed a large goodput difference in number of
Mbps transferred over the bottleneck in spite that all of
them used the same parameters and conditions. Two tri-
als used in the test, one when MSS=536 Bytes and the
other when MSS=1460 Bytes, where the two segment size
achieve more reality and credibility to the goodput per-
formance. Newreno gave the best goodput compared
with other versions while Fack gave the lesser goodput.
In fact, the all TCP versions used in the experiments can-
not achieve the high level requirements of the next gen-
eration networks, especially when an wireless channels
and nodes includes in the networks such as the cellular
system. For this reasons, and from the obtained results,
the congestion control of all standard TCP variants are
require to improve to be able to provide an end-to-end
reliable connection with lesser packet loss and high
goodput level.
ACKNOWLEDGMENT
This study is sponsored by Universiti Kebangsaan Malay-
sia (UKM) through the university research grant OUP-
2012-182.
REFERENCES
[1] S. Sharma, D. Gillies, and W. Feng, "On the Goodput of TCP NewReno
in Mobile Networks," 2010, pp. 1-8.
[2] V. Jacobson, "Congestion avoidance and control," 1988, pp. 314-329.
[3] L. A. Grieco and S. Mascolo, "Performance evaluation and comparison
of Westwood+, New Reno, and Vegas TCP congestion control," ACM
SIGCOMM Computer Communication Review, vol. 34, pp. 25-38, 2004.
[4] B. Moraru, F. Copaciu, G. Lazar, and V. Dobrota, "Practical analysis of
tcp implementations: Tahoe, reno, newreno," 2003, pp. 125138.
[5] B. Qureshi, M. Othman, and N. Hamid, "Progress in various TCP vari-
ants (February 2009)," 2009, pp. 1-6.
[6] M. S. Islam, M. Kashem, W. H. Sadid, M. A. Rahman, M. N. Islam, and
S. Anam, "TCP variants and network parameters: a comprehensive per-
formance analysis," Proceedings of the International MultiConference of
Engineers and Computer Scientists, vol. 1, 2009.
View publication stats
216
[7] G. A. Abed, M. Ismail, and K. Jumari., "ARCHITECTURE AND
FUNCTIONAL STRUCTURE OF TRANSMISSION CONTROL PRO-
TOCOL OVER VARIOUS NETWORKS APPLICATIONS," Journal of
Theoretical and Applied Information Technology, vol. 34, 2011.
[8] S. Henna, "A Throughput Analysis of TCP Variants in Mobile Wireless
Networks," 2009, pp. 279-284.
[9] N. Mller, Automatic control in TCP over wireless: School of Electrical
Engineering, Royal Institute of Technology, 2005.
[10] H. Abrahamsson, O. Hagsand and I. Marsh, "TCP over high speed
variable capacity links: A simulation study for bandwidth allocation,"
2002, pp. 117-129.
[11] X. Chen, H. Zhai, J. Wang and Y. Fang, "A survey on improving TCP
performance over wireless networks," Resource management in wire-
less networking, pp. 657-695, 2005.
[12] G. A. Abed, M. Ismail, and K. Jumari, "Behavior of cwnd for TCP source
variants over parameters of LTE networks," Information Technology
Journal, vol. 10.
[13] N. Simulator, "ns-2," 1989.
Ghassan A. Abed received his B.Sc. and
M.Sc. degree in Computer Engineering from
University of Technology, Baghdad, Iraq, in
1996 and 2003 respectively. He was Head of
Transmitters and Receivers Dept. in
Microwave Research Centre in Ministry of
Sciences and Technology, Iraq. Currently, he
is PhD candidate in National University of
Malaysia (UKM), Selangor, Malaysia. He is
working in Mobile and Computer Wireless
Networks and his research interests include developing new TCP
mechanisms to improve performance of TCP over 4G systems and
beyond.
Prof. Dr.Mahamod Ismail joined the Depart-
ment of Electrical, Electronics and System En-
gineering, Faculty of Engineering and Built
Environment, Universiti Kebangsaan Malaysia
(UKM) in 1985 and currently he is a Professor
in Communication Engineering. He received the
B.Sc. degree in Electrical and Electronics from
University of Strathclyde, U.K. in 1985, the
M.Sc. degree in Communication Engineering
and Digital Electronics from University of Manchester Institute of
Science and Technology (UMIST), Manchester U.K. in 1987, and the
Ph.D. from University of Bradford, U.K. in 1996. He was with the first
Malaysia Microsatellite TiungSat Team Engineers in Surrey Satellite
Technology Ltd. U.K. for 9 months started in June 1997. His re-
search interests include mobile and satellite communication, and
wireless networking particularly on the radio resource management
for the next generation wireless communication network. He is cur-
rently the Chair of IEEE Malaysia Section.
Prof. Dr.Kasmiran Jumari received his B.Sc.
from National University Malaysia, 1976 and
M.Sc. degree from University of Aberdeen, UK,
1977. His Ph.D. received from University of
Kent, UK, 1985. Currently he is a Professor at
the Department of Electrical, Electronic and
Systems Engineering, in National University of
Malaysia (UKM) from 2001. His research inter-
ests are in computer network security, software
engineering, computer engineering, and image processing.