IJCST Vol. 3, Issue 4, Oct - Dec 2012

ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)

End-to-End Congestion Control for TCP
1
1

K. Pavan Kumar, 2Y. Padma

Dept. of CSE, Usha Rama College of Engineering and Technology, Telaprolu, AP, India
2
Dept. of IT, PVP Siddhartha Institute of Technology, Kanuru, Vijayawada, AP, India

Abstract
Reliable transport protocols such as TCP are tuned to perform well in traditional networks where packet losses occur mostly because of congestion. However, networks with wireless and other lossy links also suffer from significant losses due to bit errors and handoffs. TCP responds to all losses by invoking congestion control and avoidance algorithms, resulting in degraded end-to-end performance in wireless and lossy systems. The proposed solutions focus on a variety of problems, starting with the basic problem of eliminating the phenomenon of congestion collapse, and also include the problems of effectively using the available network resources in different types of environments (wired, wireless, high-speed, long-delay, etc.). In a shared, highly distributed, and heterogeneous environment such as the Internet, effective network use depends not only on how well a single TCP based application can utilize the network capacity, but also on how well it cooperates with other applications transmitting data through the same network. Our survey shows that over the last 20 years many host-to-host techniques have been developed that address several problems with different levels of reliability and precision.
There have been enhancements allowing senders to detect fast packet losses and route changes. Other techniques have the ability to estimate the loss rate, the bottleneck buffer size, and level of congestion. Keywords
Computer Networks, TCP, Congestion Control, Congestion
Collapse, Packet Reordering in TCP
I. Introduction
The increasing popularity of wireless networks indicates that wireless links will play an important role in future internetworks.
Reliable transport protocols such as TCP [2], have been tuned for traditional networks comprising wired links and stationary hosts. These protocols assume congestion in the network to be the primary cause for packet losses and unusual delays. TCP performs well over such networks by adapting to end-to-end delays and congestion losses. The TCP sender uses the cumulative acknowledgments it receives to determine which packets have reached the receiver, and provides reliability by retransmitting lost packets. For this purpose, it maintains a running average of the estimated roundtrip delay and the mean linear deviation from it. The sender identifies the loss of a packet either by the arrival of several duplicate cumulative acknowledgments or the absence of an acknowledgment for the packet within a timeout interval equal to the sum of the smoothed round-trip delay and four times its mean deviation. TCP reacts to packet losses by dropping its transmission
(congestion) window size before retransmitting packets, initiating congestion control or avoidance mechanisms (e.g., slow start [1]), and backing off its retransmission timer (Karn’s algorithm [6]).
These measures result in a reduction in the load on the intermediate links, thereby controlling the congestion in the network.
Unfortunately, when packets are lost in networks for reasons other than congestion, these measures result in an unnecessary reduction in end-to-end throughput, and hence, in suboptimal performance.
Communication over wireless links is often characterized by w w w. i j c s t. c o m

sporadic high bit-error rates, and intermittent connectivity due to handoffs. TCP performance in such networks suffers from significant throughput degradation and very high interactive delays The most essential element of TCP is congestion control, it defines
TCP’s performance characteristics. In this paper we present a survey of the congestion control proposals for TCP that preserve its fundamental host-to-host principle, meaning they do not rely on any kind of explicit signaling from the network. The proposed algorithms introduce a wide variety of techniques that allow senders to detect loss events, congestion state, and route changes, as well as measure the loss rate, the RTT, the RTT variation, bottleneck buffer sizes, and congestion level with different levels of reliability and precision.
A. TCP Flow Control
One of TCP’s primary functions is to properly match the transmission rate of the sender to that of the receiver and the network. It is important for the transmission to be at a high enough rate to ensure good performance, but also to protect against overwhelming the network or receiving host. TCP’s 16-bit window field is used by the receiver to tell the sender how many bytes of data the receiver is willing to accept. Since the window field is limited to a maximum of 16 bits, this provides for a maximum window size of 65,535 bytes.
The window size advertised by the receiver tells the sender how much data, starting from the current position in the TCP data byte stream can be sent without waiting for further acknowledgements.
As data is sent by the sender and then acknowledged by the receiver, the window slides forward to cover more data in the byte stream. This concept is known as a “sliding window” and is depicted in figure 1 below.

Fig. 1: Sliding Window
As shown above, data within the window boundary is eligible to be sent by the sender. Those bytes in the stream prior to the window have already been sent and acknowledged. Bytes ahead of the window have not been sent and must wait for the window to “slide” forward before they can be transmitted by the sender. A receiver can adjust the window size each time it sends acknowledgements
International Journal of Computer Science And Technology 573

IJCST Vol. 3, Issue 4, Oct - Dec 2012

to the sender. The maximum transmission rate is ultimately bound by the receiver’s ability to accept and process data. However, this technique implies an implicit trust arrangement between the
TCP sender and receiver. It has been shown that aggressive or unfriendly TCP software implementations can take advantage of this trust relationship to unfairly increase the transmission rate or even to intentionally cause network overload situations.
B. Retransmissions, Timeouts and Duplicate Acknowledgements
TCP is relegated to rely mostly upon implicit signals it learns from the network and remote host. TCP must make an educated guess as to the state of the network and trust the information from the remote host in order to control the rate of data flow. This may seem like an awfully tricky problem, but in most cases TCP handles it in a seemingly simple and straightforward way.
A sender’s implicit knowledge of network conditions may be achieved through the use of a timer. For each TCP segment sent the sender expects to receive an acknowledgement within some period of time otherwise an error in the form of a timer expiring signals that that something is wrong. Somewhere in the end-to-end path of a TCP connection a segment can be lost along the way. Often this is due to congestion in network routers where excess packets must be dropped. TCP not only must correct for this situation, but it can also learn something about network conditions from it.
Whenever TCP transmits a segment the sender starts a timer which keeps track of how long it takes for an acknowledgment for that segment to return. This timer is known as the retransmission timer.
If an acknowledgement is returned before the timer expires, which by default is often initialized to 1.5 seconds, the timer is reset with no consequence. If however an acknowledgement for the segment does not return within the timeout period, the sender would retransmit the segment and double the retransmission timer value for each consecutive timeout up to a maximum of about
64 seconds [2]. If there are serious network problems, segments may take a few minutes to be successfully transmitted before the sender eventually times out and generates an error to the sending application Fundamental to the timeout and retransmission strategy of
TCP is the measurement of the round-trip time between two communicating TCP hosts. The round-trip time may vary during the TCP connection as network traffic patterns fluctuate and as routes become available or unavailable. keeps track of when data is sent and at what time acknowledgements covering those sent bytes are returned. TCP uses this information to calculate an estimate of round trip time. As packets are sent and acknowledged, TCP adjusts its round-trip time estimate and uses this information to come up with a reasonable timeout value for packets sent. If acknowledgements return quickly, the roundtrip time is short and the retransmission timer is thus set to a lower value. This allows TCP to quickly retransmit data when network response time is good, alleviating the need for a long delay between the occasional lost segment. The converse is also true. TCP does not retransmit data too quickly during times when network response time is long.
If a TCP data segment is lost in the network, a receiver will never even know it was once sent. However, the sender is waiting for an acknowledgement for that segment to return. In one case, if an acknowledgement doesn’t return, the sender’s retransmission timer expires which causes a retransmission of the segment. If however the sender had sent at least one additional segment after the one that was lost and that later segment is received correctly,

574

International Journal of Computer Science And Technology

ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)

the receiver does not send an acknowledgement for the later, out of order segment.
II Congestion Collapse
To resolve the congestion collapse problem, a number of solutions have been proposed.
A. TCP TAHOE
Tahoe refers to the TCP congestion control algorithm which was suggested by Van Jacobson . TCP is based on a principle of
‘conservation of packets’, i.e. if the connection is running at the available bandwidth capacity then a packet is not injected into the network unless a packet is taken out as well.
TCP implements this principle by using the acknowledgements to clock outgoing packets because an acknowledgement means that a packet was taken off the wire by the receiver. It also maintains a congestion window CWD to reflect the network capacity.
However there are certain issues, which need to be resolved to ensure this equilibrium.
1. Determination of the available bandwidth.
2. Ensuring that equilibrium is maintained.
3. How to react to congestion.
For congestion avoidance Tahoe uses ‘Additive Increase
Multiplicative Decrease’. A packet loss is taken as a sign of congestion and Tahoe saves the half of the current window as a threshold value.
The problem with Tahoe is that it takes a complete timeout interval to detect a packet loss. It doesn’t send immediate ACK’s, it sends cumulative acknowledgements, therefore it follows a ‘go back n approach.
B. TCP RENO
This Reno retains the basic principle of Tahoe, such as slow starts and the coarse grain re-transmit timer. So Reno suggest an algorithm called ‘Fast ReTransmit’. Whenever we receive 3 duplicate ACK’s we take it as a sign that the segment was lost, so we re-transmit the segment without waiting for timeout.
Reno perform very well over TCP when the packet losses are small.
But when we have multiple packet losses in one window then
RENO doesn’t perform too well and it’s performance is almost the same as Tahoe under conditions of high packet loss.
C. New-Reno
It prevents many of the coarse grained timeouts of New-Reno as it doesn’t need to wait for 3duplicate ACK’s before it retransmits a lost packet. Its congestion avoidance mechanisms to detect
‘incipient’ congestion are very efficient and utilize nework resources much more efficiently.
Because of its modified congestion avoidance and slow start algorithm there are fewer retransmits.
D. TCP SACK
TCP with ‘Selective Acknowledgments’ is an extension of TCP
Reno and it works around the problems face by TCP RENO and New-reno namely detection of multiple lost packets, and re-transmission of more than one lost packet per RTT. SACK retains the slow-start and fast retransmits parts of RENO. It also has the coarse grained timeout of Tahoe to fall back on, in case a packet loss is not detected by the modified algorithm. SACK
TCP requires that segments not be acknowledged cumulatively but should be acknowledged selectively. Thus each ACK has a block which describes which segments are being acknowledged. w w w. i j c s t. c o m

IJCST Vol. 3, Issue 4, Oct - Dec 2012

ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)

The biggest problem with SACK is that currently selective acknowledgements are not provided by the receiver To implement
SACK we’ll need to implement selective acknowledgment which is not a very easy task.
E. TCP VEGAS
Vegas is a TCP implementation which is a modification of
Reno. It builds on the fact that proactive measures to encounter congestion are much more efficient than reactive ones. It tried to get around the problem of coarse grain timeouts by suggesting an algorithm which checks for timeouts at a very efficient schedule.
Also it overcomes the problem of requiring enough duplicate acknowledgements to detect a packet loss, and it also suggest a modified slow start algorithm which prevent it from congesting the network. It does not depend solely on packet loss as a sign of congestion. It detects congestion before the packet losses occur.
However it still retains the other mechanism of Reno and Tahoe, and a packet loss can still be detected by the coarse grain timeout of the other mechanisms fail.
F. TCP FACK
Although SACK provides the receiver with extended reporting capabilities, it does not define any particular congestion control algorithms. We have informally discussed one possible extension of the Reno algorithm utilizing SACK information, whereby the congestion window is not multiplicatively reduced more than once per RTT. Another approach is the FACK (Forward
Acknowledgments) congestion control algorithm. It defines recovery procedures which, unlike the Fast Recovery algorithm of standard TCP
(TCP Reno), use additional information available in SACK to handle error recovery (flow control) and the number of outstanding packets (rate control) in two separate mechanisms. The flow control part of the FACK algorithm uses selective ACKs to indicate losses.
It provides a means for timely retransmission of lost data packets, as well. Because retransmitted data packets are reported as lost for at least one RTT and a loss cannot be instantly recovered, the
FACK sender is required to retain information about retransmitted data. This information should at least include the time of the last retransmission in order to detect a loss using the legacy timeout method (RTO). The rate control part, unlike Reno’s and
New Reno’s Fast Recovery algorithms, has a direct means to calculate the number of outstanding data packets using information extracted from SACKs. Instead of the congestion window inflation technique, the FACK maintains three special state variables:
(1) H, the highest sequence number of all sent data packets all data packets with sequence number less than H have been sent at least once; (2) F, the forward-most sequence number of all acknowledged data packets—no data packets with sequence number above F have been delivered .
III. Packet Reordering
The basic idea behind TCP-PR is to detect packet losses through the use of timers instead of duplicate acknowledgments. This is prompted by the observation that, under persistent packet reordering, duplicate acknowledgments are a poor indication of packet losses. Because TCP-PR relies solely on timers to detect packet loss, it is also robust to acknowledgment losses.
Two issues arise when considering TCP-PR over networks without packet reordering: performance and fairness. The first issue is whether TCP-PR performs as well as other TCP implementations under “normal” conditions, i.e., no packet reordering. Specifically, w w w. i j c s t. c o m

for a fixed topology and background traffic, does TCP-PR achieve similar throughput as standard TCP implementations? The second concern is whether TCPPR and standard TCP implementations are able to coexist fairly.

Fig. 2:
In this section we present a number of proposed TCP modifications that try to eliminate or mitigate reordering effects on TCP flow performance. All of these solutions share the following ideas:
(a) they allow nonzero probability of packet reordering, and (b) they can detect out-of-order events and respond with an increase in flow rate (optimistic reaction). Nonetheless, these proposals have fundamental differences due to a range of acceptable degrees of packet reordering, from moderate in TD-FR to extreme in
TCP PR, and different baseline congestion control approaches.
The development of these proposals is highlighted in the above
Figure.
IV. High-Speed/Long-Delay Networks
In connectionless networks, the role of flow control is to modify the natural sending rate of an application to match the realities of network capacity, and to make the data stream better behaved. This is done by insisting that some assertions about the data stream are always valid, for example, that no more than 12 kbtyes of data will be outstanding (sent but unacknowledged) at any given time.
The test of a flow control protocol is its effectiveness in making network operation smoother as a result of this modification.
In a high speed network with large delays, problems can arise from two sources.
• Delay in knowing about network state can cause buffer buildups, and eventual congestion.
• High speed sources can inject data rapidly into the network, causing problems for other sources.
The PP flow control protocol consistently matches or outperforms the competing schemes, because of its short start up times, and ability to monitor network state. Inflexible protocols such as
‘generic’ are unsuitable for high-speed networks with propagation delays. Schemes that involve a slow start phase, such as JK (and
DECbit will discriminate against conversations with a long propagation delay, which will suffer loss of throughput. PP works well in the simulated scenarios, since it can rapidly adapt to changes in the network state.
V. Future Enhancement
Currently, we have as situation where there is no Single congestion control approach for TCP that can universally be applied to all network environments. One of the primary causes is a wide variety of network environments and different (and sometimes opposing) network owners’ views regarding which parameters should be optimized. A number of the congestion control algorithms.
International Journal of Computer Science And Technology 575

IJCST Vol. 3, Issue 4, Oct - Dec 2012

Moreover, the current version of Linux kernel provides an API for software developers to choose any one of the supported algorithms for a particular connection. However, there are not yet the well-defined and broadly-accepted criteria to serve as a good baseline for appropriately selecting a congestion control algorithm. Additionally, objective guidelines to select a proper congestion control for a concrete network environment are yet to be defined.
VI Conclusion
In this work we have presented a survey of various approaches to
TCP congestion control that do not rely on any explicit signaling from the network. The survey highlighted the fact that the research focus has changed with the development of the Internet, from the basic problem of eliminating the congestion collapse phenomenon to problems of using available network resources effectively in different types of environments (wired, wireless, high-speed, long delay, etc.). In the first part of this survey, we classified and discussed proposals that build a foundation for hostto-host congestion control principles. The first proposal, Tahoe, introduces the basic technique of gradually probing network resources and relying on packet loss to detect that the network limit has been reached. Unfortunately, although this technique solves the congestion problem, it creates a great deal of inefficient use of the network. As we showed, solutions to the efficiency problem include algorithms that (1) refine the core congestion control principle by making more optimistic assumptions about the network (Reno, NewReno) or (2) refine the TCP protocol to include extended reporting abilities of the receiver (SACK,
DSACK), which allows the sender to estimate the network state more precisely (FACK, RR-TCP); or (3) introduce alternative concepts for network state estimation through delay measurements
(DUAL, Vegas, Veno).

ISSN : 0976-8491 (Online) | ISSN : 2229-4333 (Print)

K.Pavan kumar received the M Tech degree from ANU in 2010. Currently he is working as Assistant Professorin
Usharama College of Engineering &
Technology, Telaprolu, Andhra Pradesh,
India. He has five years of teaching experience .His research interests are networks and compiler design.

Y. Padma is Assistant Professor in department of Information Technology,
PVPSIT, Kanuru, Vijayawada, India.
She holds M.Tech and B.Tech in 2006 and 2002 respectively. She has 9 years of teaching experience. Her research interests are Software Architecture,Agile
Technologies and Natural Language
Processing.

References
[1] Alexander Afanasyev, Neil Tilley, Peter Reiher, Leonard
Kleinrock,"Host-to-Host Congestion Control for TCP”.
[2] J. Postel,“RFC793—transmission control protocol”, RFC,
1981.
[3] C. Lochert, B. Scheuermann, M. Mauve,“A survey on congestion control for mobile ad hoc networks”, Wireless
Communications and Mobile Computing, Vol. 7, No. 5, pp.
655, 2007.
[4] Stephan Bohacek, Jo˜ao P. Hespanha, Junsoo Lee, Chansook
Lim, Katia Obraczka,"TCP-PR: TCP for Persistent Packet
Reordering”.
[5] Srinivasan Keshav,"Flow Control in High-Speed Networks with Long Delays”.
[6] S. Low, F. Paganini, J. Doyle,“Internet congestion control,”
IEEE Control Syst. Mag., Vol. 22, No. 1, pp. 28–43, February
2002.
[7] M. Gerla, L. Kleinrock,“Flow control: a comparative survey”,
IEEE Trans. Commun., Vol. 28, No. 4, pp. 553–574, April
1980.
[8] J. Nagle,“RFC896—Congestion control in IP/TCP internetworks”, RFC, 1984.
[9] V. Jacobson,“Congestion avoidance and control”, ACM
SIGCOMM, pp. 314–329, 1988.
[10] M. Allman, V. Paxson, and W. Stevens,“RFC2581—TCP congestion control”, RFC, 1999

576

International Journal of Computer Science And Technology

w w w. i j c s t. c o m