A new congestion control algorithm for Datagram Congestion Control Protocol (DCCP) based real-time multimedia applications

Abstract

In recent times, the applications like streaming audio-video, Internet telephony and multi-player online games are the most prevalent in the Internet world. So, it becomes a great concern to carry out these applications effectively and efficiently. These applications prefer timeliness in packet delivery to reliability. TCPs reliability through packet re-transmission and abrupt rate control features are unsuitable for these applications. As a result, these applications prefer UDP as the transport layer protocol. UDP does not have any congestion control mechanism which is vital for the overall stability of the Internet. For this reason, a new transport layer protocol Datagram Congestion Control Protocol (DCCP) has been introduced which is suitable for these applications because of its exclusive characteristics. But the congestion control algorithm of DCCP seems a little bit faulty as they have some limitations. This paper describes another one congestion control algorithm for DCCP.

Full text

A New Congestion Control Algorithm for
Datagram Congestion Control Protocol (DCCP)
Based Real-time Multimedia Applications
Joy Rahman,1 Sajeeb Saha,2 and Syed Faisal Hasan3
1Information and Communication Technology Section, United Nations
Santiago, Chile
2Department of Computer Science and Engineering, Dhaka International University
Dhaka, Bangladesh
3Department of Computer Science and Engineering, University of Dhaka
Dhaka, Bangladesh
1joy.rahman@gmail.com
2sascsedu@yahoo.com
3hasansf@gmail.com
Abstract—In recent ti mes, the applications like strea ming
audio-video, Internet telephony and multi-player online games
are the most prevalent in the Internet world. So, it becomes a
great concern to carry out these applications effectively and
efficiently. These applications prefer timeliness in packet
delivery to reliability. TCPs reliability through packet re-
transmission and abrupt rate control features are unsuitable for
these applications. As a result, these applications prefer UDP as
the transport layer protocol. UDP does not have any congestion
control mechanism which is vital for the overall stability of the
Internet. For this reason, a new transport layer protocol
Datagram Congestion Control Protocol (DCCP) has been
introduced which is suitable for these applications because of its
exclusive characteristics. But the congestion control algorithm of
DCCP seems a little bit faulty as they have some limitations.
This paper describes another one congestion control algorithm
for DCCP.
Index Terms—DCCP, CCID, Real-time multimedia
applications, congestion control algorithm.
I. INTRODUCTION
The real time multimedia applications are the dominant
applications in today’s Internet. That’s why many transport
level solutions have been suggested for transferring these
wide variety of applications precisely. Most of them do not
use any congestion control mechanism which can be
threatening for our today’s Internet. As a remedy, a new
transport layer protocol DCCP [1] is offered with some
congestion control mechanisms for real time applications.
DCCP is desirable for the applications where timing
constraints exists but reliability is not expected.
The application programmer do not need to provide
congestion control at the application layer while using DCCP.
There are two built-in congestion control mechanisms of
DCCP are TCP-like (Congestion Control IDentifier 2) and
TCP-friendly (Congestion Control IDentifier 3). These are
useful for those applications where a steady rate of data
transmission is required rather than reliable in-order delivery
of packets.
Some experiments [3] have demonstrated that the
performance of the congestion control algorithms of DCCP is
not always excellent [2]. The objective of this paper is to
make up a new congestion control algorithm for DCCP to
win over the limitations of CCID 2 (Congestion Control
IDentifier 2) and CCID 3 (Congestion Control IDentifier 3).
II. RELATED WORKS
Floyd et al. [4] initially proposed and introduced the
definition of TCP-friendly flows.
In an experimental study, Timothy Sohn and Eiman
Zolfaghari [5] reported an initial implementation and
experimentation of Datagram Control Protocol (DCP) and its
equation-based congestion control mechanism to show its
TCP-friendliness behaviours.
Horia Vlad Balan, Lars Eggert, Saverio Niccolini and
Marcus Brunner [6] evaluated the voice quality that Internet
telephony calls achieve over prototype implementations of
basic DCCP and several DCCP variants, under different
network conditions and with different codecs.
Saleem Bhatti, Martin Bateman and Dimitris Miras [7]
compared the performance of DCCP CCID2 relative to TCP
NewReno.
III. BACKGROUND STUDY
Recently, works on the new transport layer protocol DCCP
is going on to meet various dynamic changes of network
bandwidth.
Α.
TCP Congestion Control
Fig. 1 depicts that when a TCP connection begins, the
value of congestion window (CongWin) is typically
initialized to 1 MSS (RFC 3390), resulting an initial sending
rate of roughly MSS/RTT. After every RTT, the sender
increases its rate exponentially by doubling its value of
CongWin.

Fig. 1: TCP Congestion Control Mechanism
Β.
Datagram Congestion Control Protocol
Datagram Congestion Control Protocol (DCCP) differs
from UDP, in that, it includes congestion control mechanism
and it differs from TCP, in that, it does not provide
guaranteed reliability.
1) The DCCP Connection
Fig. 2: DCCP’s Two Half Connection
DCCP implements bidirectional connections between
hosts. The connection is established between two hosts and
any host can initiate the connection [8]. Data may passes
from any host to another host which is depicted in Fig. 2, A
DCCP connection consists of two unidirectional connections,
called half-connection but this distinction is logical [9].
2) Unreliable Data Transfer
Each DCCP packet carries a sequence number so that
losses can be detected and reported. But there is no re-
transmission of lost packets and hence DCCP is an unreliable
protocol [9].
3) DCCP Connection Management
DCCP server and client go through many states when
establishing a connection between them. The steps are
depicted at Fig. 4.
4) DCCP Congestion Control
CCID 2 is TCP-like congestion control mechanism [10]. It
is perfect for those applications which can adapt to the
changes of congestion control window and which need as
much bandwidth as possible in the network.
Fig. 4: DCCP’s Connection Management
CCID 3 is TCP-friendly rate control mechanism [11]. It
provides TCP friendly rate by reducing the changeable
characteristics of TCP or TCP like congestion control. The
sender maintains its sending rate by observing the loss event
sent by the receiver and goes through a constant sending rate
[12]. CCID 3 uses TCP friendly rate control mechanism for
congestion control. The DCCP sender calculates its smoother
transmission rate based on the following equation-
 


 1
• T = transmission rate in bytes/second
• s = packet size in bytes
• R = round trip time in seconds
• b = number of packets acknowledged by a single
TCP acknowledgement
• p = loss event rate
• t = TCP re-transmission time out value in seconds
IV. METHODOLOGY
The algorithm which has been used throughout the work is
given in this section. We have aimed our new congestion
control algorithm for real-time multimedia applications.
That’s why our focal point was the basic requirements of
multimedia applications.
After surveying the fundamental necessities (RFC 4710),
we have observed that it is important for real-time
applications to maintain the transmission rate. That means to
have a equal timing interval between two packets.
On the other hand, during congestion we will reduce the
size of the packets rather than the transmission rate. Small
packets incur less burden on congested network.
Connection establishment using principle of CCID 3
Calculate the initial transmission rate using TFRC equation
while until closing the connection do
if currentLostRate > previousLostRate then
packetSize←currentPacketSize *
(currentLostRate ― previousLostRate)
end if
if currentLostRate < previousLostRate then
packetSize ← currentPacketSize *
(previousLostRate ― currentLostRate)

end if
if currentLostRate =
p
reviousLostRa
t
packetSize ← currentPacketSize *
(currentLostRate)
end if
if packetSize < minimumPacketSize t
h
calculate the new transmission rat
e
equation
end if
if packetSize > maximumPacketSize
t
packetSize ← maximumPacketSize
end if
end while
Besides, the algorithm will retain the
rate as much as possible.
The complete algorithm is described
b
el
• The connection will start us
i
connection initiation protocol (RF
• This transmission rate will conti
n
the packet falls below the mi
n
packets.
• After receiving a loss event ra
t
modify the packet size based o
n
Previous work [
13
] on variabl
e
aimed for TCP. But our work is s
o
• If the packet size falls below th
e
size, the TFRC equation will be
u
the transmission rate. This time
t
size, weighted average of R
T
average of lost event rate will
equation.
• This transmission rate will conti
n
packet size reaches the minimum
algorithm continues.
V. E
XPERIMENTAL
R
ESU
L
This section is going to shed light on T
e
and at last the Performance Evaluation Res
A. Testing
Fig. 5: The Test bed Configurati
The setup of two machines is illustra
t
machine acts as DCCP sender and othe
DCCP receiver. Sender machine is used t
o
changes. The receiver machine acts as a s
i
conditions are applied on the interface of
t
using application level programming.
B. Performance Evaluation
We have not mentioned User Datagram
our main focus is on the improvement of
mechanism of DCCP. For our every ex
p
t
e then
h
en
e
using TFRC
t
hen
equal transmission
o
w
-
i
ng the CCID 3
C 4342).
n
ue until the size of
n
imu
m
size of the
t
e, the sender will
n
some constraints.
e
packet size was
o
lel
y
for DCCP.
e
minimum packet
u
sed for calculating
t
he average packet
T
T and weighted
be used in TFRC
n
ue until again the
packet size and the
L
TS
e
sting Environment
ult.
o
n
t
ed in Fig. 5. One
r
machine acts as
o
emulate network
i
nk. These network
t
he sender machine
Protocol (UDP) as
congestion control
p
eriments, we have
considered “Timestamps” alon
g
in Mbps along the Y-axis.
1) Smoothness
Fig. 6: Throughput
o
Fig. 6 shows us that the
b
i
t
somewhat smoother. In the gra
p
4-5 and 7-8 to the time axis, t
h
The reason for this reduction i
n
packet size falls below the min
i
sharp rise and fall in the grap
h
real-time applications.
2) Addition in TFRC
Fig. 7: Comparison between
Fig. 7 Shows TFRC has sha
rp
rise at interval 10-11. Though
T
rate for carrying out the data,
data rate is quite inadequate for
other hand, the new algorithm
changes.
3) Variation in Packet Size
Fig. 8 shows the packe
t
corresponding to the time in
s
shows us that the packet size
o
varied (maximum 16 bytes a
n
TFRC uses the same packet siz
e
g
the x-axis and “Throughput”
of
New Algorithm
t
rate of the new algorithm is
p
h, we observe that at interval
h
e bit rate has been decreased.
n
rate is due to the fact that the
i
mu
m
packet size. There is no
h
, which is really required for
TFRC and New Algorithm
rp
fall at interval 5-6 and sharp
T
FRC gives us a moderate bit
but this sharp rise and fall in
real-time applications. On the
does not have so such abrupt
t
size in bytes to y-axis
s
econds to x-axis. The graph
o
f the new algorithm has been
n
d minimum 12 bytes). But
e
during the t
r
ansmission.

Fig. 8: The Variation in the Size of th
e
4) Comparison Among Three Flows
Fig. 9: Comparison among DCCP, TCP and
N
Fig. 10: Comparison among DCCP, TCP and New Al
On the other hand, CCID 3 has also a
b
time interval of 5-6 and 8-9. But still this
than TCP as expected [14]. Besides, ou
r
also more smoother though the bit rate is n
o
5) Comparison During Congestion
Now, we have inject congestion to em
u
environment. Fig. 10 shows TCP and CCI
D
e
Packets
N
e
w
Algorithm
gorithm in Congestion
b
rup
t
change in the
is much smoother
r
new algorithm is
ot
always constant.
u
late the real-world
D
3 has more sharp
change in the bit rate than in F
i
showing some smoother bit r
a
transmission rate of our new al
g
two flows, but it can practice it’
VI. C
ONCLUSION A
N
In this paper, we have co
m
control algorithm for DCCP
ba
The limitations are-only fe
w
Telephony can use this new al
g
applicable for the real-time app
l
is fixed. Moreover, as we h
a
overhead may be incurred whi
c
transmission rate.
In future, we will have a tr
y
friendly and make the algorith
m
real-time multimedia applicati
o
directed towards those applicat
i
without any form of end-to-en
d
interest would be to implement
the DCCP layer.
R
EFER
E
[1] S. Floyd and M. Handley and
E
Datagram Congestion Control
P
2006.
[2] S. Stanimir and M. Seferin,
E
x
p
congestion control protocol in v
a
report, Technical University of
S
[3] I. Chowdhury and J. Lahiry an
d
Datagram Congestion Control
P
proceeding of International Con
f
Technology, 2009.
[4] S. Floyd and K. Fall,
P
romotin
g
Control in the Internet, IEEE/A
C
August 1999.
[5] T. Sohn and E. Zolfaghari,
E
xpe
r
Protocol. California, USA, 200
2
[6] H. Balan and L. Eggert and S. N
Experimental Evaluation of Voi
c
Congestion Control Protocol, A
p
IEEE International conference o
n
Publicaation date : 6-12 May 20
0
[7] S. Bhatti and M. Bateman and
D
Evaluation of DCCP. London,
U
[8] lwn.net-linux info source, http:/
/
[9] E. Kohler and M. Handly and S.
Control Protocol (DCCP). IET
F
[10] S. Floyd and E. Kohler, Profile
f
Protocol (DCCP), Congestion
C
Control. IETF, RFC 4330, LA,
U
[11] J. Padhye and S. Floyd and E. K
o
Control ID 3: TFRC Congestion
Force, 2002
[12] S. Floyd and E. Kohler and J. P
a
Congestion Control Protocol (D
TCP-Friendly Rate Control (TF
R
2006.
[13] P. Vasallo, Variable Packet Size
International Computer Science
[14] I. Chowdhury and J. Lahiry and
Performance Analysis of
D
atag
r
(DCCP). International Journal o
f
Vol. 3, No. 5, October 2011.
i
g. 9. But our algorithm is still
a
te. It has happened that the
g
orith
m
is lesser than the other
s constant rate.
N
D
F
UTURE
W
ORKS
m
e up with a new congestion
a
sed multimedia applications.
w
applications, like Internet
g
orithm. This algorithm is not
l
ications where the packet size
a
ve reduced the packet size,
c
h can give us the unexpected
y
to make the algorithm media
m
able to be used by all kind of
o
ns. Finally, because DCCP is
i
ons which currently use UDP
d
congestion control, an area of
a layer of reliability on top of
E
NCES
E
. Kohler, Problem statement for
P
rotocol. IETF, RFC 4336, LA, USA,
p
erimental study of datagram
a
ried network states. Technical
S
ofia, Bulgaria, 2008.
d
S. Hasan, Perfomance analysis of
P
rotocol (DCCP), IEEE, In the
f
erence of Computer and Information
g
the Use of End-to-End Congestion
C
M Transactions on Networking,
r
imentation of the Datagram Control
2
.
iccolini and M. Brunner, An
c
e Quality over the Datagram
p
peared in INFOCOM 2007. 26th
n
computer communicaations. IEEE,
0
7, on pages 2009-2017
D
. Miras. A Comparative Performance
U
k.
/
lwn.net/Articles/149756
/
Floyd, Datagram Congestion
F
, RFC 4330, LA, USA, 2006.
f
o
r
Datagram Congestion Control
C
ontrol ID 2: TCP-like Congestion
U
SA, 2006.
o
hler. Profile for DCCP Congestion
Control. Internet Engineering Task
a
dhye. Profile for Datagram
CCP), Congestion Control ID 3:
R
C). IETF, RFC 4342, LA, USA,
Equation based Congestion Control,
Institute, California, USA,
S. Hasan and C. Rahman.
r
am Congestion Control Protocol
f
Computer Theory and Engineering,