Matrix Academic International Online J ournal Of Engineering And Technology

MAIOJ ET
2013

13


Evolution of Congestion Control Mechanisms
for TCP and Non TCP Protocols
Dr. Atul M Gosai
#1
, Bhargavi H Goswami
*2,
Uditnarayan Kar
#3
#
Department of MCA, Saurashtra University,
Rajkot, Gujarat, India
*
Department of Computer Science, NIMS University,
Jaipur, Rajasthan, India
1
atul.gosai@gmail.com,
2
bhargavigoswami@gmail.com,
3

uditnarayankar@gmail.com
Abstract Modern world of communication is
demanding wired as well as wireless communication to
provide faster data transmission that too in huge data
amount. Now mobiles are no more just for calling. Each
and every application of mobile is demanding Internet.
This paper is written with the aim to study upon how the
problem of congestion is taken care by the existing
congestion control mechanisms. What are the options
available in congestion control and what are their
characteristics. This paper also explains the classification
of congestion control schemes which came one after the
other in the last decade. This paper briefly describes
study on congestion control algorithms, its classification,
its compatibility with TCP which is a most widely used
protocol, few non TCP but popular congestion control
algorithms and the analysis and conclusion of problem
statement.

Keywords TCP, Congestion, TCP Window, TCP Data
Rate, RCP, XCP, DCCP, Congestion Control
Mechanism, TFRC, Single Rate, Multi Rate.

1. Introduction:
For every type of mediums and for every kind of
traffics, for the last few years, congestion control has
been the area of interest in research. Also there is a
drastic increase in audio, video, multimedia, video
conferencing and streaming traffic in last few years.
Even now the number of users have increased, aided
with services like VoIP(Video over IP) and
VoD(Video on Demand), video conferencing, etc.
Continuous increase in such traffic has resulted to
congestion. Heterogeneous traffic also fails in
maintaining fair bandwidth allocation among each of
data flows. These entire situations inspire the research
upon congestion control measures to be taken into
consideration on priority bases. But, congestion
control has always been the focus of researchers since
communication started evolving. This raise question
that whether the existing congestion control
mechanisms are enough to handle the current
communication demands and does it fit the current
technology scenario? And therefore, it is desirable to
survey upon congestion control mechanisms available
and already deployed and how much are they capable
of handling the current situations and demands. This
paper is a small effort in this direction which helps the
researchers to know the mechanisms evolved to
control congestion, how they benefit the current
communication scenario and how much still they are
lagging behind of fulfilling demands of current
internet.
Congestion can be defined as a network state, result
of network resources overloaded at the end resulting
to uneven behaviour of network with the users which
also may lead to delay and packet loss. The solution to
the above stated problem of congestion is congestion
control mechanisms. Congestion control is the
mechanism to share the network resources among the
existing competing traffics[1].
Following structure, in Section-II we have listed
objectives of congestion control mechanisms,
followed by Section-III, classification of congestion
control schemes, followed by Section-IV,
classification of protocols, followed by Section-V,
TCP congestion control algorithms, followed by
Section-VI, Non-TCP congestion control algorithms,
followed by Section-VII, popular non-TCP congestion
control algorithms. Ending this paper, then we give
the conclusion which is then followed by references.

II. Objectives of congestion control
mechanisms:

(a) Controlling the network traffic in network
communication.
(b) Avoiding unfair resource allocation.
(c) Prevent congestion resulting to collapses.
(d) Accomplish high bandwidth utilization.
(e) Inspire quick and efficient fairness for
bandwidth allocation.
(f) Be adaptive and compatible to heterogeneous
combination of protocol co-existence.
(g) Increase responsiveness by bringing
equilibrium in minimum round trip time.

III. Classification of Congestion Control
Schemes:

(a) Window Based or Rate Based
Matrix Academic International Online J ournal Of Engineering And Technology
MAIOJ ET
2013

14


(b) Unicast or Multicast
(c) Single Rate or Multi-rate
(d) Peer to Peer or Network Layer Supported
As shown in the Fig.1, we classified the Congestion
Control Schemes. Following is the brief description of
the distribution shown in Fig.1.
A. Window Based or Rate Based Congestion
Control Scheme:
Congestion control mechanisms may adapt to the
networks offered load based on congestion window
or transmission rate[2].

Fig: 1. Classification of Congestion Control Schemes:
Window: Packets transmitted consume congestion
window slots. Once packet is acknowledged, sets that
window slot free. Sender can transmit only when
window has available free slots otherwise sender has
to wait until that window slot gets free. We may also
vary window size based on congestions intensity by
increasing it and reducing it. The protocols falling
under this category doesnt need Round Trip Time
information[2].
Rate: This scheme is based on feedback mechanism.
They dynamically adapt to transmission rate. Additive
Increase and Multiplicative Decrease (AIMD) is best
suitable to this category, also used in TCP. Sending
rate is set based on bandwidth availability which may
require to update transmission rate every few RTTs.
Critical point here is Rate calculation and frequency
on which it is updated. The protocols falling under this
category does need RTT computation[5].

B. Unicast or Multicast Congestion Control
Scheme:
Unicast: It is easy and efficient to design good unicast
congestion control. Here, only one receiver is there, so
it becomes easy for sender to decide rate of
transmission or window size setting for single
receivers.
Multicast: Designing good multicast congestion
control algorithm is a bit difficult. Here, all receivers
and only one sender, so at what rate data is transmitted?
Large multicast sessions may result to busty errors
that too not related to each other[5],[11].

C. Single Rate or Multi rate Congestion Control
Scheme:
Single Rate: Users obtain fair rate for bottleneck
receivers also. Rate remains same for all receivers
without considering how many senders are sending to
that receiver. Generally, unicast protocols are based on
single rate[2].
Multi Rate: It is more flexible for bandwidth
allocation for multiple users over multiple lines. Here,
sender sends to groups of receiver and based on such
subdivision, rate is measured and allocated to
individual receivers. Fair allocation is observed in
such schemes. Layered approach reduces congestion,
thus, handling congestion becomes efficient for
bottleneck links[2],[5],[11].

Congestio
n Control
Schemes
Feedbac
k
Window
Based
Rate
Based
Transmis
sion
Unicast
Multicas
t
Rate
Single
Rate
Multi
Rate
Layer
Peer to
Peer
Network
Based
Matrix Academic International Online J ournal Of Engineering And Technology
MAIOJ ET
2013

15


D. Peer to Peer Control or Network Layer
Supported Congestion Control Scheme:
Peer to Peer Control: In this approach, no help from
network layer is obtained for congestion control. In
this kind of approach, generally sender and receiver
communicate control frames on their own to provide
congestion control. For example, TCP performs
congestion control through handshaking and ACKs.
Mechanism is not too bad but issues here of concern
are even though when some bandwidth is still
available, TCP indicates congestion, resulting to
timeouts and requesting retransmission, which
adversely affect the network. It is also following slow
start strategy which, initially perform very bad and
even single packet drop reduces the data rate to half.
Network Layer Supported: This method is the one
where network assistance is available for congestion
control. In network supported approach we have two
sub-approaches. First one is direct feedback approach
achieved by using choke packets. According to
Technopedia, a choke packet is used in network
maintenance and congestion management to inform a
transmitting node or transmitter that its transmitted
traffic is creating congestion over the network. This
forces the node or transmitter to reduce its output rate.
Here, router sends to sender choke packets to slower
down the transmission rate considering the state of
receiver which is about to start dropping packets. And
so, receiver sends choke packets directly to the sender.
Second approach is given by Indirect Feedback, where,
congestion can be indicated by flags or single bit
indication. This bit is set no sooner router founds that
now the receiver is congested and indicates the
receiver and indirectly to the sender that there exist
congestion at that router. This further gets forwarded
to the sender that there exist congestion at the router.
This further gets forwarded to the sender through
ACK indicating sender to slower down the data rate
for avoiding data lost due to packet loss. And thus,
receiver performs the responsibility for indicating the
sender about the congestion.

IV. Categorization of Congestion Control Protocol:

1) Single Rate Congestion Control Protocol
a) Rate Based Approach
i) Rate Adaption Protocol
ii) Low Delay Based Adaptive Algorithm
iii) TCP Friendly Rate Control Protocol
iv) TCP Emulation At Receivers
b) Window Based
i) Random Listening Algorithm
ii) Linear Proportional Response
iii) Multicast TCP
iv) Nominee Based Congestion Avoidance
v) Pragmatic General Multicast Congestion
Control
2) Multi Rate Congestion Control Protocol
a) Rate Based Approach
i) Receiver Driven Layered Congestion
Control
ii) Fair Layered Increase / Decrease with
Dynamic Layering
iii) Layered Transmission Scheme
iv) TCP Friendly Transport Protocol
v) Multicast Loss Delay based Adaption
Algorithm
b) Window Based Approach
i) Rainbow

Brief description for each protocol stated in Fig. 2 is
done as following. Our idea is to discriminate between
each protocol by specifying its key characteristics.

Rate Adaption Protocol:
Rate Adaption Protocol, uses simple AIMD scheme
where, ACK detect loss and thus reduces RTT time.
Considering AIMDs behaviour, sending rate reduces
to half once congestion is detected by the means of
Packet Drop or Chock Packet or Pause Frames.[5].
Smooth behaviour due to fine grained delay based
congestion avoidance. But, it is proved more
aggressive when timeout events are not taken into
consideration.

Low Delay based Adaptive Algorithm:
This algorithm relies upon RTCP for computing
feedback like in real time TCP. It is based on AIMD
with dynamic adjustment of AIMD as per the network
situation demands[5]. Low bandwidth flows, slowly
increase rate and high bandwidth flows, slowly reduce
rate. It prevents over dropping of bottleneck links.
Only drawback is less frequent feedback.

Fig. 2, Single Rate based Congestion Control
Protocols:
Single Rate Congestion Control Protocol
Rate
Adaption
Protocol
Low Delay
Based
Adaptive
Algorithm
TCP Friendly
Rate Control
Protocol
TCP
Emulation At
Receivers
Rate
Based
Random
Listening
Algorithm
Linear
Proportional
Response
Multicast
TCP
Nominee
Based
Congestion
Avoidance
Pragmatic
General
Multicast
Congestion ctrl
Window
Based


Matrix Academic International Online J ournal Of Engineering And Technology
MAIOJ ET
2013

16



TCP Friendly Rate Control Protocol:
This algorithm dynamically transmission rate based on
load, bandwidth and queue occupancy. Loss events are
based on loss rate which later proved unstable
protocol due to strong reaction. Senders rate is time
stamped by using dynamic feedback
mechanism[5],[10]. It is far better than slow start of
TCP. Also carry relatively stable sending rate for all
the competing loads[2].

TCP Emulation At Receivers:
It is hybrid by nature having combined qualities of
window and rate based congestion control. Here, fair
rate of transmission is computed at receivers end and
communicated to sender. Congestion window is also
maintained here and updated at receivers end. But,
ACK control is very less resulting to approximate
estimation of timeout events[5]. Even, frequency of
rate change is low which indicates stable behaviour of
protocol.

Random Listening Algorithm:
It extends TCP SACK and multicast usability
enhancement. Computes RTT and congestion
estimation is made at receiver. Loss detection based
on sequence of ACK which later helps filter highly
congested receivers. Retransmission and quick
recovery facilitates path lost multiplicity problem.
Overall, this algorithm was proved fair for TCP.

Linear Proportional Response Protocol:
It filter lost data and improves Random Listening
Algorithm. Loss filtering is directly proportional to
decremented congestion window. This algorithm is
performing better in multicast than in unicast. Results
were proved better and friendly when worked with
RLA simultaneously.

Multicast-TCP:
Its main characteristic is TCP friendliness. Purely
based on tree structure, MTCP divides the sessions.
There exist parent child relationship between senders
and receivers. Here, feedback is provided by ACK to
parents for successful delivery of packets at children
ends, one for congestion and another for transmission
record[5]. Three consecutive NACKs reduce cwnd
(congestion window) to half. Transit window keep
tracks of unacknowledged packets. Bottleneck info is
passed back to parents about each child. Only
drawback is that algorithm is quite complex.

Nominee-based Congestion Avoidance:
This algorithm selects monitor of the bottleneck
receivers and they are provided with worst
connectivity. Issue the researchers need to handle here
is, how to select the monitor of receivers group. For
this, they consider loss probability and RTT. Expected
rate is piggybacked, which helps select monitor by
senders also. Approach is very promising and fairness
is high enough.

Pragmatic General Multicast Congestion Control:
This algorithm came simultaneously with NCA and
was almost same as NCA. There is no relevant
difference between them.

Fig:3, Multi Rate Congestion Control Protocols:
Multi Rate Congestion Control Protocol
Receiver Driven Layered
Congestion Control
Fair Layered Increase /
Decrease with Dynamic
Layering
Layered Transmission
Scheme
TCP Friendly Transport
Protocol
Multicast Loss Delay
based Adaption
Algorithm
Rate Based
Rainbow
Window
Based


Following given is the brief description of
characteristics of protocols stated in Fig.3.

Receiver driven Layered Congestion Control:
It is a layered approach that provides bandwidth
exponentials. As layer increases, data transmission
rate also increases. No sooner, congestion is observed,
layer is dropped on each packet loss. One layer when
dropped, data rate becomes half. Here,
synchronization points are maintained where receivers
may join to the synchronization points. Here,
disadvantage is that it is not fair enough and may
result to unstable behaviour. This algorithm doesnt
take RTT into the account, and so may be called
biased algorithm.

Fair Layered Increase/Decrease with Dynamic
Layering:
This protocol uses digital fountain at source. At
senders end, data plus redundancy is encoded and at
receiver it is decoded. It implements dynamic layering
which reduces delay. Simply joins the layer and gain
the rate, leave the layer and loose the data rate[5].
Bandwidth distribution here is very flexible. But, as it
Matrix Academic International Online J ournal Of Engineering And Technology
MAIOJ ET
2013

17


doesnt consider RTT, it is unfair. It is crucial to take
decision that when to join and when to leave the layer.

Layered Transmission Scheme (LTS) and TCP
Friendly Transport Protocol (TFRP):
Both the protocols are similar in functionality used for
video streaming and transmission. Communicating
parties simply demands for available bandwidth.
Sender communicates rate computed by equation to
the receiver and receiver adjust its level to given rate
given by sender. It is fair enough as it considers RTT
and loss rate at receiving end[5]. Also has provision to
provide high throughput at low rate of packet loss.

Multicast Loss Delay based Adaption Algorithm:
It is based on LDA and RTCP feedback mechanism.
All rate calculation is performed at receiving end. It
uses timers to avoid feedback mechanism and
acknowledging rate at sender. To provide rate, it is
piggybacked. Sender needs to continuously update
data rate. Complexity lies in measuring RTT
estimation[5]. It is proved that the algorithm can
recover faster to congestion. Only demerit of this
algorithm is its complexity.

Rainbow:
Reliable Transfer of bulk data which is digital by
nature, uses fountain like approach and it is purely
window based protocol. Here, receiver request for
each data packet with window position marked over
label. Router stores information about request made.
Packets are forwarded in reverse direction of
receiver[5]. When first packet loss is found, window
size reduces to half and thus, rate reduces. Additive
Increase of window size on each packet arrival is
performed. It is the only congestion control approach
where data is transmitting with variable rates.
Limitation, routers heavily loaded as it stored data.

V. TCP Congestion Control Algorithms:
a. Slow Start
b. Congestion Avoidance
c. Fast Retransmission
d. Fast Recovery : TCP Reno
e. TCP New Reno
f. TCP SACK
g. FACK
h. TCP Vegas


Moving forward we discuss the characteristics of the
protocols shown in Fig.4.

Fig: 4, TCP Congestion Control Algorithms:
Slow Start:
This algorithm performs sender based flow control. It
maintains senders rate based on ACK receiver returns.
Congestion window is incremental based on ACK
receiver sends back like 1,2,4,8,16. And so on.
These results to packet loss and packet drops. Senders
ACK wait time outs and thus, sender reduces
cwnd(congestion window) size of half, and keeps on
decrementing until packet drops are encountered at
receiving end[3],[4],[RFC5681],[8].

Congestion Avoidance:
To control slow start behaviour before packets start to
drop, congestion avoidance controls the data
transmission to go out of control. For this, duplicate
ACK is used to signal sender that congestion exist,
slow down or else receiver may start packet
dropping[RFC896]. In such a situation, sender slow
down its rate and call Fast Retransmission or Fast
Recovery algorithms. Disadvantage of this algorithm
is only that it takes too long to reach the desired rate
of transmission for long and busty data
flows[4],[RFC2914],[8].

Fast Retransmission:
When duplicate ACK arrives, algorithm doesnt
specify out of the two following situation which one
has occurred. i) TCP segment is lost ii) There is a
delay or out of order delivery of segments has
happened. As a solution, if less than two duplicate
ACK is obtained; out of order of delivery of segments
is assumed. And if more than three duplicate ACK s
are observed, data segment lost is assumed. Advantage,
now no need to wait for timers to get timeout, start
retransmission, hence called Fast Retransmission
algorithm[4],[6],[8].

Fast Recovery, TCP Reno:
Slow start was incremental by nature and was starting
with window size of one which made it too slow to
achieve its desired data transmission rate. As a
Matrix Academic International Online J ournal Of Engineering And Technology
MAIOJ ET
2013

18


solution, fast recovery algorithm came into existence.
Here, sender starts transmission with large window
size providing benefit of higher data rate achieved in
small time span. It has partial ACK strategy
facilitating Fast Recovery[4],[RFC5681],[6], [8].

TCP New Reno:
Because of timeout, congestion window starts with
segment one, it is reliable but indirectly compromising
with performance. Here, sender receives partial ACK
but doesnt opt for Fast Recovery, instead, assumes
that every next packet of last ACK segment is lost and
so follow Retransmission for that packet. It doesnt
wait for timer to timeout for igniting for
retransmission[4],[8].

TCP with SACK:
Selective Acknowledgement is an algorithm where,
receiver queue is maintaining the missing and received
segment list. Without waiting for retransmission
timeout, sender simply retransmits the missing
segment. Once, all segments are acknowledged, next
block is sent. Similar to Reno, once 3 duplicates are
observed, it calls for Fast Recovery[4],[8].

Forward Acknowledgements:
FACK came with purpose of better recovery from
multiple losses. It maintains two variables. 1) Last
segment acknowledged, 2) Remaining outstanding
retransmitted data. Using these two values, it
maintains outstanding number of segments with
congestion. And if required, algorithm may call for
Fast Retransmission[8].

TCP Vegas:
Expected =Window Size / Base RTT. This algorithm
doesnt wait for packet loss. Higher the packet
delivery ratio, higher has to be the cwnd (congestion
window). It calculates runtime RTT for segment
delivered calculation. Exponentially increases window
size based on previous and current RTT difference.
Here, retransmission strategy is limited to one
duplicate ACK[8].

VI. Non-TCP Congestion Control Algorithms:
a) Drop Tail
b) RED
c) Choke
d) Blue
e) Fair Queuing
f) Virtual Queue
g) Adaptive Virtual Queue

Discussion of above stated protocols in Fig.5 becomes
necessary to discriminate between features of each of
them.

Drop Tail:
Drop Tail has great accuracy, widely deployed
algorithm where, packets are dropped from Tail once
buffer is full. Beneficial for heterogeneous network
but also has disadvantage of missing fairness and QoS
and not suitable for multimedia flows[2],[9].

Random Early Detection (RED):
It is proposed for deploying AQM(Active Queue
Management). If q < min, then no dropping is
performed. If min <q <max, then packets are dropped
with probability p. And, p =max (q-min)/(1-count.p).
If q >max, all packets are dropped. Once packet lost,
senders follow slow start and congestion avoidance[9].
RED helps prevent high bandwidth flows dominating
low bandwidth flows. Complexity lies in threshold
value assumption[2].



Fig:5, Non TCP Congestion Control Algorithms:

Choke:
When a new packet reaches congested router, it is
checked to be with randomly selected queue packets.
If both found to be belonging to the same flow, both
are dropped, otherwise, next packet is checked as
stated above. Similar to RED, but it is less complex
and enhancement of RED. This technique reduces
particular senders flow rate and it is widely deployed
for multiple flows between routers[2],[9].

Blue:
RED (Random Early Detection) as we discussed
before, provides very less information regarding
number of connection and flows passing by the same
queue. Blue algorithm is based on Stochastic Fair Blue
Algorithm (SFB) designed especially as remedy of
disadvantage of RED. SFB enforce fairness by
maintaining small queue size and state information. It
identifies the flows that are very less responsive[2].

Fair Queuing:
This mechanism is also called Stochastic Fair Queuing
Algorithm. Most multimedia flows face high delay
and also has less fairness over network[2]. In this
algorithm, Round Robin Scheduling is followed by
implementing buffers for each flow and additional
facility of weighted Round Robin helps it achieve
fairness for multimedia flows.
Matrix Academic International Online J ournal Of Engineering And Technology
MAIOJ ET
2013

19



Virtual Queue:
Extra queue appears simultaneously with existing
queue which is actually the original queue getting
distributed in two parts. Virtual Queue carry highly
probable data grams to be dropped[2]. Link arrival
rate remains same for virtual and real queues. It
appears that packet is dropped in VQ but actually it is
just indication to sender that dropping has happened,
slow down please. This helps reduction of congestion
without actual data loss.

Adaptive Virtual Queue:
VQ is not able to handle dynamic traffic and so
Adaptive VQ came into existence[2]. Desired link
utilization is measured and based on that, virtual
queue capacity is updated dynamically. Here, virtual
queue is equal to real queue.

VII. Popular Non TCP Congestion Control
Protocols:
a) DCCP
b) XCP
c) RCP
d) ACP

DCCP:
Data gram Congestion Control Protocol is a transport
protocol that provides duplex uni-cast communication
over datagram communication with congestion control.
It is widely used in applications that transfer bulky
data with the trade-off of delay and reliability. Here,
congestion control incorporates Explicit Congestion
Notification (ECN) and ECN Nonce. Algorithm has
limitation like streaming media applications, that
support reliable in-order datagram delivery, are not
recommending DCCP. Useful applications including
online games, internet telephony use DCCP. It is a
Congestion control mechanism especially used by
UDP as it does not provide reliability. DCCP has 48
bit very long sequence number, corresponding to
packet ID of TCP, which guards against blind attacks
and infection over DCCP, is thus secure.
Fig: 6, Some non TCP but popular congestion
control Protocols

Fig. 6 shows the capability of each protocol to handle
the versatile flows based on variable internet
application demands increasing day by day. Thus,
starting from DCCP to ACP, versatile flow handling
capability increases.
XCP:
Explicit Congestion Control Protocol is another
famous solution to congestion that extracts congestion
information directly from routers and achieves
fairness, maximum link utilization and does efficient
use of bandwidth, which is by nature scalable too.
XCP maintains per flow congestion state in packet.
This needs changes in all the routers and this require
large queuing capacity in routers which is difficult to
deploy[7]. Concluding statement says that XCP is
more resource and time consuming which is not a
good deployment option[14].
Popular Non TCP Congestion Control
Protocols
DCCP
XCP
RCP
ACP

RCP:
Rate Control Protocol is a congestion control
algorithm that overcomes the disadvantage of XCP
with minimum changes required in routers. It uses
Feedback Information and uses emulation of processor
sharing. As it is using Feedback information, unlike
TCP and XCP, does not perform incremental window
changes at RTT. Thus, RCP achieves congestion
control without maintaining per flow queues and per
packet calculations is also not required[7]. Especially,
serve long flows, multimedia and streaming videos
and bulky traffics[13].

ACP:
ACP, Adaptive Congestion Control is a window based
protocol which does not require maintenance of per
flow states within the network[12]. It utilizes an
explicit multi-bit feedback signalling scheme to
convey congestion information from the network to
the end users and vice versa[7]. The main objective of
RCP is to minimize the duration of the network flows
whereas the main objective of ACP is to optimize
network centric performance metrics such as fairness,
utilization, queue sizes and packet drops. Both are
congestion control algorithms designed during the
same network era[7],[12].

CONCLUSION:
In this paper we presented the evolution of congestion
control mechanism. We distributed the congestion
control mechanisms and algorithms and classified
them on the bases of the mechanism used for
providing congestion control. We discussed widely
used and most popular congestion control algorithms
also. But, we would like to conclude based on the
Matrix Academic International Online J ournal Of Engineering And Technology
MAIOJ ET
2013

20


details provided in section I, II and III that none
among the specified algorithms fulfil all the objectives
specified in objectives of congestion control
mechanism. This paper also discussed congestion
control algorithms used with most widely used
protocol of TCP and few Non TCP protocols.
Nearly all of the control schemes have been
congestion recovery schemes. Traditional Transport
protocols such as TCP probe for excess bandwidth by
increasing transmission rates until the network
becomes congested. According to According to RFC
793 and RFC 4340, TCP and DCCP can work together
smoothly over heterogeneous network condition.
Popular non TCP congestion control protocols like
DCCP and XCP provides a way to gain access to
congestion control mechanisms without having to
implement them at the application layer. It allows for
flow-based semantics like in TCP but does not provide
reliable in-order delivery. Sequenced delivery within
multiple streams is not available both in DCCP and
XCP. RCP is another non-TCP congestion control
algorithms that has proved to be very vital in wired
network scenario but is still in its infant stage and
under research. We also discussed ACP and RCP and
according to the authors of [13] and [14] ACP can be
the option of RCP as ACP is working on congestion
windows instead of implying feedback mechanism
like RCP.
So after going though the stated references
in the next section and all other literature review, we
hereby conclude that implementing congestion control
correctly is hard. Its not usually the area of expertise
of the application writer, and certainly doesnt get
their product to market faster. So to implement the
congestion control mechanism correctly in the real
network scenario is still a huge research area. And
efficiently handling heterogeneous traffic over the
world of internet is still the aim not achieved by
researchers even after working for so long duration.
After reviewing all above protocols and algorithms,
we came to know that these algorithms are not talking
about their performance in wireless networks, in
presence of busty traffic of multimedia application
whose demand is increasing day by day as the world is
going mobile. This demanding communication world
can be satisfied only by improving congestion control
mechanisms of the previous decade as they are proved
to be not enough to handle the current demands of the
communication. After reviewing TCP and Non TCP
congestion control protocols, we would like to say that
there is still more research is needed in this area and
the enhancement of congestion control mechanism is
one of the biggest necessities of current network
scenario.
REFERENCES:
[1] B. Braden, D. Clark, J. Crowcroft, Recommendations on
Queue Management and Congestion Avoidance in the
Internet, http://tools.ietf.org/html/rfc2309.
[2] Dr E. Chandra, B. Subramani, "A Survey on Congestion
Control", Global J ournal of Computer Science and
Technology, Vol. 9 Issue 5 (Ver 2.0), J anuary 2010, P a g e
82-87.
[3] S. Floyd Congestion Control Principles, RFC-2914,
http://www.ietf.org/rfc/rfc2914.txt, Network Working Group.
[4] M. Allman, V. Paxson, W. Stevens, "TCP Congestion
Control", RFC 2581, https://tools.ietf.org/html/rfc2581,
Network Working Group.
[5] J oerg Widmer, Robert Denda, and Martin Mauve, "A Survey
on TCP-Friendly Congestion Control", IEEE Network,
May/J une 2001, pg. 28 to 37, 0890-8044/01.
[6] Guiomar Corral, Agustin Zaballos, Tomas Fulgueira, J aume
Abella, "Simulation based study of TCP flow control
mechanisms using OPNET Modeler",
http://web.salleurl.edu/~tomasf/index_fitxers/article.pdf as on
12/12/2012.
[7] Sonia Fahmy, "TCP Congestion Control: Overview and
Survey Of Ongoing Research", Tapan Prem Karwa,
Computer Science Technical Reports, Report Number: 01-
016, 2001, Paper 1513,
http://docs.lib.purdue.edu/cstech/1513.
[8] A. Karnik, Performance of TCP congestion control with rate
feedback: TCP/ABR and rate adaptive TCP/IP, M. Eng.
thesis, Indian Institute of Science, Bangalore, India, J an.
1999.
[9] Aun Haider, Harsha Sirisena, Krzysztof Pawlikowski,
Michael J . Ferguson, Congestion Control Algorithms in
High Speed Telecommunication Networks, Applications
and the Internet, 2007. SAINT 2007.
[10] International Symposium, Obtained from IEEE Explore,
Digital Library published in June 2007. Go Hasegawa and
Masayuki Murata, "Survey on Fairness Issues in TCP
Congestion Control Mechanisms", IEICE TRANSACTIONS
on Communications Vol.E84-B No.6 pp.1461-1472,
published on Date: 2001/06/01, ISSN: 0916-8516.
[11] C. Raiciu, M. Handley, D. Wischik, "Practical Congestion
Control for Multipath Transport Protocols" October 2011,
RFC 6356, http://www.hjp.at/doc/rfc/rfc6356.html
[12] Marios Lestas, Petros Ioannou, "Adaptive Congestion
Protocol: A Congestion Control Protocol with Learning
Capability", J ournal of Computer Networks: The
International J ournal of Computer and Telecommunications
Networking, Volume 51 Issue 13, September, 2007, Pages
3773-3798.
[13] N. Dokkipati, M. Kobayashi, Rui Zhang-Shen, and Nick
McKeown. Processor sharing flows in the internet. InProc.
Thirteenth Intenrational Workshop on Quality of Service
2005,, J une 2005.
[14]. S. H. Low, L. L. H. Andrew, and B. P. Wydrowski.
Understanding XCP: Equilibriumand fairness. InProc. IEEE
INFOCOM, volume 2, pages 10251036, March 2005.