Studying_the_TCP_Flow_and_Congestion_Con.pdf

Studying the TCP Flow and Congestion Control
Mechanisms Impact on Internet Environment
Khalid Mohamed, Said Hussein and Asad Abdi Abubakr El Seddiq
Department of Electrical & Electronics Engineering Department of Computer Engineering
International University of Africa Al-Neelain University
Khartoum, Sudan Khartoum, Sudan
Kha.omer@hotmail.com
Asadcabdi011 & Jallaludin456@gmail.com
abubakr.elhussein@gmail.com
Abstract - The Transmission Control Protocol (TCP) is
connection oriented, reliable and end-to-end protocol that support
flow and congestion control, with the evolution and rapid growth
of the internet and emergence of internet of things IoT, flow and
congestion have clear impact in the network performance. In this
paper we study congestion control mechanisms Tahoe, Reno,
Newreno, SACK and Vegas, which are introduced to control
network utilization and increase throughput, in the performance
evaluation we evaluate the performance metrics such as
throughput, packets loss, delivery and reveals impact of the cwnd.
Showing that SACK had done better performance in terms of
numbers of packets sent, throughput and delivery ratio than
Newreno, Vegas shows the best performance of all of them.
Index Terms – TCP, Congestion mechanisms, Tahoe, Reno,
Newreno, SACK and Vegas.
I. INTRODUCTION
The Transmission Control Protocol (TCP) is intended to
provide a reliable process-to-process communication service,
able to transfer a continuous stream of octets in a multinetwork
environment. The TCP is intended to be a host-to-host
protocol in common use in multiple networks.
TCP is used to provide a connection-oriented, end-to-end
reliable, securable connection service between pairs of
processes, it is able to transfer a continuous stream of octets in
each direction between its users by packaging some number of
octets into segments for transmission through the internet
system.
Transmission is made reliable via the use of sequence
numbers and acknowledgments, sequence numbers are used to
correctly order segments that may be received out of order and
to eliminate duplicates, and acknowledgments must be
received within a timeout interval, otherwise the data is
retransmitted, to govern the flow of data between TCP hosts, a
flow control mechanism is employed [15].
TCP implements four congestion control algorithms: slow
start, congestion avoidance, fast retransmit, and fast recovery,
developed in [1] and [10]. TCP sender to control the amount
of outstanding data being injected into the network use the
slow start and congestion avoidance algorithms and add the
congestion window (cwnd) to the a sender-side to limit amount
of transmit data before receiving an ACK, in receiver-side add
receiver's advertised window (rwnd) to limit the amount of
outstanding data, the minimum of cwnd and rwnd governs data
transmission, and to determine which algorithm is used to
control data transmission the slow start threshold (ssthresh) is
used.
When an out-of-order segment arrives TCP receiver
should send an immediate duplicate ACK to inform the sender
that a segment was received out-of-order and which sequence
number is expected, duplicate ACKs can be cause due to
dropped segments or re-ordering of data segments by the
network, after fast retransmit algorithm sends the missing
segment the transmission of new data is governs by the "fast
recovery" algorithm until a non-duplicate ACK arrives [9].
Now days with the invention of Internet of Things (IoT)
several low power communication technologies have been
proposed, this devices may relay on the transport protocols
such as TCP or User Datagram Protocol (UDP), however there
are quite challenge must be considered, UDP may be easier to
implement in microcontrollers than TCP, but the security tools
used for TCP (SSL/TLS) are not available in UDP, HTTP
relies on the TCP. TCP’s flow control mechanism is not
appropriate for Low Power and Lossy Networks (LLNs) and
its overhead is considered too high for short-lived transactions
[13].
[14] Surveyed the most important aspects of the IoT, he
address that TCP cannot be used efficiently for the end-to-end
transmission control in the IoT due to (Connection setup,
Congestion control and Data buffering) therefore, information
should be the focus of communication and networking
solutions.
In section II of this paper, we describe the principles of
congestion control mechanisms and procedures that is
followed to handle congestion, timeout and retransmission.
Section III presents a detailed description of the network
model. In section IV we analyse simulations result and
discuss cwnd impact in the different simulations scenarios, and
Section V concludes the paper.
II. OVERVIEW OF TCP CONGESTION CONTROL
MECHANISMS
A. Congestion Control Algorithm
1) 1) TCP Tahoe: TCP Tahoe based on TCP congestion
control algorithm which was suggested by Van Jacobson in his
paper [1]. The flow on a TCP connection obey a ‘conservation
International Journal of Computer Science and Information Security (IJCSIS),
Vol. 16, No. 11, November 2018
174 https://sites.google.com/site/ijcsis/
ISSN 1947-5500

of packets’ principle, the protocol is ‘self-clocking’, new
packet isn’t put into the network until an old packet leaves. the
sender uses ACKs as a ‘clock’ to strobe new packets into the
network, self-clocking systems automatically adjust to
bandwidth and delay variations and have a wide dynamic
range, to start the ‘clock’, the a slow-start algorithm it
developed to gradually increase the amount of data in-transit.
2) TCP Reno: TCP Reno in [10] retains implementation
of the basic principle of Tahoe, such as slow starts, but add
modification to the congestion avoidance algorithm, The Reno
algorithm prevents the pipe from going empty after a loss, and
the packet loss is used as a signal that the pipe is congested
can be detected by: a retransmit timeout slow-start must be
start, or three duplicate ACKs re-transmit the segment
immediately and enter Fast Recovery and reduces its
congestion window by one half and set SSthresh to the same
value, for each dup ACK received represents a single packet
have left the pipe and cwnd incremented by one.
3) TCP NewReno: modified Fast Recovery algorithm in
RFC 2581, the TCP data sender responds to a partial
acknowledgment(the acknowledgement for the retransmitted
packet will acknowledge some but not all of the packets
transmitted before the Fast Retransmit) by inferring that the
next in-sequence packet has been lost, and retransmitting that
packet [7], NewReno 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.
4) TCP Sack: With selective acknowledgments, the data
receiver can inform the sender about all segments that have
arrived successfully, so the sender need retransmit only the
segments that have actually been lost, The SACK option
follows the format in [4], the SACK option field contains a
number of SACK blocks The first block in a SACK option is
required to report the data receiver's most recently received
segment, and the additional SACK blocks repeat the most
recently reported SACK blocks, The main difference between
SACK and Reno is the behavior in the event of multiple
segment losses, During Fast Recovery , SACK maintains a
variable called pipe that represents the estimated number of
packets outstanding in the path[5][6].
5) TCP Vegas: TCP Vegas [2] is a modification of Reno
implementation, which introduced to provide some new
insights into congestion control, and to propose modifications
to the implementation of TCP that exploit these insights. It
employs three techniques to increase throughput and decrease
losses. New Retransmission Mechanism: its uses more
accurate RTT estimate to decide to retransmit also reads and
records the system clock each time a segment is sent. Vegas
treats the receipt of certain ACKs as a trigger to check if a
timeout should happen. Congestion A voidance Mechanism: it
determines congestion by a decrease in sending rate as
compared to the expected rate does not use the loss of segment
to signal that there is congestion, it apply approaches in Wang
and Crowcroft’s Tri-S scheme [3]. Modified Slow-Start
Mechanism: it allows exponential growth only every other
RTT, when the actual rate falls below the expected rate by a
certain amount, it changes from slow-start mode to linear
increase/decrease mode.
B. TCP Congestion Control Procedures
Fig. 1 shows the TCP congestion control procedures that
must be followed when congestion occur, the retransmission is
needed to recover a missing packet, in slow start phase the
cwnd grow exponentially until it reach the threshold, after that
the congestion avoidance phase start and the value of threshold
is set to half of the current window size, and cwnd is set to the
value of threshold, then the cwnd size increase
linearly(additive increase) until three ACKs arrive to the
sender or time-out event occur, when three ACKs happen TCP
start fast transmission and fast recovery phase and
multiplicative decrease procedure take over, and the value of
threshold is set to the half of current window size and the
value of cwnd is set to the threshold value and congestion
avoidance phase start, in the second case if time-out occur at
this moment the multiplicative decrease start and reduce the
threshold value to half of the current window size and cwnd it
set to one segment, TCP enter slow start phase again[16][17].
Fig. 1 TCP congestion control procedures.
C. Timeout and Retransmission
TCP provides reliability when data segments and
acknowledgments can get lost, it handles this by setting a
timeout when it sends data, and if the data isn't acknowledged
when the timeout expires, it retransmits the data.
ISSN 1947-5500

Round-Trip Time (RTT) Measurement:
TCP must measure the RTT between sending a byte and
receiving an acknowledgment, we use the following equations
that are applied to each RTT measurement M.
R = αR + (1 - α)M (1)
Where α is a smoothing factor
The initial retransmission timeout is calculated using the
formula:
RTO = A + 2D. (2)
The factor 2Dis used only for this initial calculation. After this
4D is added to A to calculate RTO.
Err = M – A (3)
A = A + gErr (4)
D = D + h(|Err| - D) (5)
RTO = A + 4D (6)
Where A is the smoothed RTT (an estimator of the average)
D is the smoothed mean deviation.
Err is the difference between the measured value just obtained
and the current RTT estimator.
Both A and D are used to calculate the next retransmission
timeout (RTO).
The gain g is for the average and the larger gain for the
deviation makes the RTO go up faster when the RTT changes
[8].
Fig. 2 is provide a visual description of round trip time TCP
congestion control mechanism.
Fig. 2 Round trip time vs. time
D. Congestion Control evaluation metrics
The congestion control mechanisms evaluated in terms of
trade-offs between a range of metrics, using flow-based
metrics given by the transport protocol itself like throughput,
delay, and loss rates [11].
1) Throughput: is the link utilization or flow rate in bytes
per second, the clear goal of most congestion control
mechanisms to maximize throughput, throughput is important
in a wide range of environments, from highly-congested
networks to under-utilized ones, and from long-lived flows to
very short ones.
2) Delay: can be measured as a flow-based metric in
terms of per-packet transfer times, Per-packet delay can also
include delay at the sender waiting for the transport protocol to
send the packet.
3) Packet Loss Rates: can be measured as a network-
based or as a flow-based metric, a congestion event or loss
event consists of one or more lost or marked packets in one
round-trip time.
4) Deployability: Metrics related to deployability include
the ease of failure diagnosis and the overhead in terms of
packet header size or added complexity at end-nodes or
routers.
III. NETWORK MODEL AND SIMULATIONS
We used NS2-Simulator to simulate the different network
scenarios, NS-2 is a discrete event simulator targeted at
networking researches hence it provides a substantial support
for the simulation of these TCP variants [12]. Fig. 3 shows the
simulation topology, the sender TCP source and the receiver
TCP sink communicate throw bottleneck link 500 kbit/s and
100ms propagation delay.
Fig. 3 Network simulation topology
IV. RESULT AND ANALYSIS
Table I and table II shows the output of the simulation
scenarios for the TCP congestion control mechanism (Tahoe,
Reno, Newreno, Sack and Vegas), Vegas has the highest
numbers of packets sent (43074) and received (43074) in
contrast the Reno has the lowest numbers of packets sent
(33694) and received (33668), the maximum number of lost by
Newreno packet is equal to 34.
ISSN 1947-5500

TABLE I
NUMBERS OF PACKETS SENT, RECEIVED AND LOST
Congestion
Control
Mechanisms
Number of
packets sent
Number of
packets
received
Number of
packets lost
Tahoe 35550 35520 30
Reno 33694 33668 26
Newreno 38132 38098 34
Sack 39141 39111 30
Vegas 43074 43074 0
The Reno and Sack approximately has same delivery ratio
(99.77%) it’s seem to be better than Newreno and Tahoe,
however Newreno has higher throughput (451.36) than Reno
and has lower average delay than Sack.
The Vegas show the best performance according to the
numbers of sending and receiving packets, delivery ratio
throughput and average delay.
TABLE II
Throughput, Packet Delivery Ratio, and Average delay
Congestion
Control
Mechanisms
Average
delay
Throughput Packet delivery ratio
Tahoe 0.18456 420.71 99.75
Reno 0.17465 398.70 99.77
Newreno 0.18642 451.36 99.73
Sack 0.18859 463.62 99.77
Vegas 0.12057 473.83 100.00
Fig. 4 plots sequence numbers versus time for the
congestion control mechanism and it represent the differences
between them, the Reno and Tahoe has small curve in their
lines due to the to the operations procedures that is used to
handle the lost packets in the network.
Fig. 4 sequence numbers vs. time
Fig. 5 depicts the number of lost packet versus time for
the different TCP congestion control techniques, during
initialization period from 0 to 5 seconds there were multiple
packets dropped, after that the ratio is vary according to the
TCP technique that is implemented, TABLE I shows total
numbers of the lost packets.
Fig. 5 Number of lost packet vs. time
In the Fig. 6 from the start time 0 to approximately time
equal to 50 second Sack shows the highest throughput in
contrast to the other congestion control mechanism after 50
second Vegas shows the highest throughput after it reach the
steady state, Sack has highest throughput than Tahoe, Reno
and Newreno because it has ability to send only segments that
are lost and use the list of duplicate segments, and use the
SACK option, however SACK option can only be used for
TCP connections when both TCP end-nodes support the
SACK option. The Reno show the worst performance because
when the number of the lost segments in the RTT more than
one it handle the first segment and wait for time-out and start
slow-start phase.
Fig. 6 Comparison of throughput vs. time.
ISSN 1947-5500

In Fig. 7 blow we see that the slow-start is initiated and
the exponential increase continues until cwnd equal to the
ssthresh value 60, except Vegas doesn’t exceed half of the
ssthresh value.
Fig. 7 Comparison of congestion window behavior of various congestion
algorithms.
Tahoe in Fig. 8 start the slow-start phase it set the value of
the cwnd to one and then for each receiving ACK increase the
cwnd by one, so the cwnd increased exponentially until the
loss of the packet occur (the packet loss detected by time-out)
this is sign of congestion, when congestion occur the sending
rate decreased and the cwnd is set to one, in the congestion
avoidance phase Tahoe apply additive increase multiplicative
decrease, also a packet loss is consider as sing of congestion,
then threshold is set to the half of the current window.
Fig. 8 Congestion window behavior and threshold values of Tahoe congestion
algorithms.
Fig. 9 shows the effect of the cwnd and the value of
ssthresh in Reno, after 5 seconds the slow-start is initiated and
the value of the window is increased by one, when loss is
detected by three repeated ACKs then the cwnd drops by half
15 and remain in the congestion avoidance phase, the value of
the window is drops to one only if the loss is detected through
a time-out.
Fig. 9 Congestion window behavior and threshold values of Reno congestion
algorithms.
Fig. 10 shows the effect of the cwnd and the value of ssthresh
in Newreno, Newreno can recover without a retransmission
timeout, New-Reno remains in Fast Recovery until either a
retransmission timeout occurs or an ACK arrives that
acknowledges all of the data up to and including all of the
data outstanding.
Fig. 10 Congestion window behavior and threshold values of Newreno
congestion algorithms.
In Fig. 11 Sack also start with slow-start phase at time
from 0 to 5 seconds some segments had been lost, the window
it reduced to half 30 this is will lead to decrease the throughput
as shown in Fig. 6, after it reach the steady-state the TCP
ISSN 1947-5500

sustain in congestion avoidance and the value of the window
increase linearly until congestion occurs again.
Fig. 11 Congestion window behavior and threshold values of SACK
Fig. 12 shows the effect of the cwnd and the value of
ssthresh in Vegas, it used α and β thresholds to control the
size of the congestion window. The congestion window has
fixed size due to the performance techniques that is applied to
increase throughput and decrease losses of the packet.
Fig. 12 Congestion window behavior and threshold values of Vegas
V. CONCLUSION
In this paper, we have presented TCP congestion control
mechanisms, our studies evaluate flow and congestion
mechanisms for different TCP variants, Tahoe show poor
performance when packets loss, it’s complete timeout interval,
Reno unable to control the congestion when recovering from
dropped packet it perform like Tahoe when network encounter
extremely packet loss, Newreno more powerful it overcome
the problem faced by Reno it can detect multiple packet loss
per sending window, it’s use partial ACK to indicate that the
segment follow ACK has been lost, SACK use selective ACK
to enhance network performance it shows better performance
than Newreno, but the receiver must also support the selective
ACK, Vegas with the proactive measurement shows the best
performance to encounter congestion.
REFERENCES
[1] V.Jacobson, “Congestion Avoidance and Control,” SIGCOMM
Symposium on Communications Architectures and Protocols, pages
314–329, 1988.
[2] L.Brakmo, S. O'Malley, and L.Peterson. TCP vegas: Newtechniques for
congestion detection and avoidance. In Proceedings of the
ACMSIGCOMM, pages 24-35, August1994.
[3] Z. Wang and J. Crowcroft. A New Congestion Control Scheme: Slow
Start and Search (Tri-S). ACM Computer Communication Review,
21(1):32–43, Jan 1991.
[4] Matthew Mathis, Jamshid Mahdavi, Sally Floyd, and Allyn Romanow.
“TCP Selective Acknowledgment Options,” (Internet draft, work in
progress), 1996.
[5] K. Fall and S. Floyd. Simulation-based comparisons of Tahoe, Reno,
and SACK TCP. In ACM Computer Communication Review, volume
26, pages 5-21, July 1996.
[6] M.Mathis,J .Mahdavi, S.Floyd, and A.Romanow. TCP selective
acknowledgement options. RFC2018, October1996.
[7] S. Floyd, A. Gurtov and T. Henderson “The NewReno Modification to
TCP's Fast Recovery Algorithm,” RFC 3782, April 2004.
[8] W. Richard Stevens, “TCP/IP Illustrated,” Vol 1, the Protocols. Addison
Wesley, 1994.
[9] M. Allman, V. Paxson, E. Blanton, “TCP Congestion Control,”
RFC2581, September 2009.
[10] Jacobson, V., "Modified TCP Congestion Avoidance Algorithm", April
30, 1990.
[11] S. Floyd, Ed, “Metrics for the Evaluation of Congestion Control
Mechanisms”, RFC 5166, March 2008.
[12] “NS-2 Network Simulator,” [Online]. Available.
http://www.isi.edu/nsnam/ns/, 2000.
[13] O. Vermesan and P .Friess, “Internet of Things – From Research and
Innovation to Market Deployment”, 2014.
[14] L.Atzori A.Iera G.Morabito “The Internet of Things: A survey,”
Computer Networks 54, 2010.
[15] M. Del, “Transmission Control Protocol,” RFC 793 September 1981.
[16] B.Fourzan, “TCP/IP Protocol Suite,” Vol 4, McGraw-Hill, 2010.
[17] B.Fourzan, “Data communication and Networking,” Vol 4, McGraw-
Hill, 2007.
ISSN 1947-5500

Studying_the_TCP_Flow_and_Congestion_Con.pdf

More Related Content

What's hot

Similar to Studying_the_TCP_Flow_and_Congestion_Con.pdf

Recently uploaded

Studying_the_TCP_Flow_and_Congestion_Con.pdf