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 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.

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.

2012 7th International Conference on Electrical and Computer Engineering20-22 December, 2012, Dhaka, Bangladesh

533

978-1-4673-1436-7/12/$31.00 ©2012 IEEE

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)

534

end if if currentLostRate = previousLostRat

packetSize ← currentPacketSize *(currentLostRate)

end if if packetSize < minimumPacketSize th

calculate the new transmission rateequation

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 bel

• The connection will start usiconnection initiation protocol (RF

• This transmission rate will continthe packet falls below the minpackets.

• After receiving a loss event ratmodify the packet size based onPrevious work [13] on variableaimed for TCP. But our work is so

• If the packet size falls below thesize, the TFRC equation will be uthe transmission rate. This time tsize, weighted average of RTaverage of lost event rate will equation.

• This transmission rate will continpacket size reaches the minimum algorithm continues.

V. EXPERIMENTAL RESUL

This section is going to shed light on Teand at last the Performance Evaluation Res

A. Testing

Fig. 5: The Test bed Configurati

The setup of two machines is illustratmachine acts as DCCP sender and otheDCCP receiver. Sender machine is used tochanges. The receiver machine acts as a siconditions are applied on the interface of tusing 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 exp

te then

hen e using TFRC

then

equal transmission

ow- ing the CCID 3 C 4342).

nue until the size of nimum size of the

te, the sender will n some constraints. e packet size was olely for DCCP. e minimum packet used for calculating the average packet TT and weighted be used in TFRC

nue until again the packet size and the

LTS esting Environment ult.

on

ted in Fig. 5. One r machine acts as o emulate network ink. These network the sender machine

Protocol (UDP) as congestion control

periments, we have

considered “Timestamps” alongin Mbps along the Y-axis.

1) Smoothness

Fig. 6: Throughput o

Fig. 6 shows us that the bitsomewhat smoother. In the grap4-5 and 7-8 to the time axis, thThe reason for this reduction inpacket size falls below the minisharp rise and fall in the graphreal-time applications.

2) Addition in TFRC

Fig. 7: Comparison between

Fig. 7 Shows TFRC has sharprise at interval 10-11. Though Trate 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 packet

corresponding to the time in sshows us that the packet size ovaried (maximum 16 bytes anTFRC uses the same packet size

g the x-axis and “Throughput”

of New Algorithm

t rate of the new algorithm is ph, we observe that at interval

he bit rate has been decreased. n rate is due to the fact that the imum packet size. There is no h, which is really required for

TFRC and New Algorithm

rp fall at interval 5-6 and sharp TFRC 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 seconds to x-axis. The graph of the new algorithm has been nd minimum 12 bytes). But e during the transmission.

535

Fig. 8: The Variation in the Size of the

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 abtime interval of 5-6 and 8-9. But still this than TCP as expected [14]. Besides, ouralso more smoother though the bit rate is no

5) Comparison During Congestion Now, we have inject congestion to emuenvironment. Fig. 10 shows TCP and CCID

e Packets

New Algorithm

gorithm in Congestion

brupt change in the is much smoother

r new algorithm is ot always constant.

ulate the real-world D 3 has more sharp

change in the bit rate than in Fishowing some smoother bit ratransmission rate of our new algtwo flows, but it can practice it’

VI. CONCLUSION AN

In this paper, we have comcontrol algorithm for DCCP baThe limitations are-only fewTelephony can use this new algapplicable for the real-time applis fixed. Moreover, as we haoverhead may be incurred whictransmission rate.

In future, we will have a tryfriendly and make the algorithmreal-time multimedia applicatiodirected towards those applicatiwithout any form of end-to-endinterest would be to implement the DCCP layer.

REFERE[1] S. Floyd and M. Handley and E

Datagram Congestion Control P2006.

[2] S. Stanimir and M. Seferin, Expcongestion control protocol in vareport, Technical University of S

[3] I. Chowdhury and J. Lahiry andDatagram Congestion Control Pproceeding of International ConfTechnology, 2009.

[4] S. Floyd and K. Fall, PromotingControl in the Internet, IEEE/ACAugust 1999.

[5] T. Sohn and E. Zolfaghari, ExperProtocol. California, USA, 2002

[6] H. Balan and L. Eggert and S. NExperimental Evaluation of VoicCongestion Control Protocol, ApIEEE International conference onPublicaation date : 6-12 May 200

[7] S. Bhatti and M. Bateman and DEvaluation of DCCP. London, U

[8] lwn.net-linux info source, http://[9] E. Kohler and M. Handly and S.

Control Protocol (DCCP). IETF[10] S. Floyd and E. Kohler, Profile f

Protocol (DCCP), Congestion CControl. IETF, RFC 4330, LA, U

[11] J. Padhye and S. Floyd and E. KoControl ID 3: TFRC CongestionForce, 2002

[12] S. Floyd and E. Kohler and J. PaCongestion Control Protocol (DTCP-Friendly Rate Control (TFR2006.

[13] P. Vasallo, Variable Packet Size International Computer Science

[14] I. Chowdhury and J. Lahiry and Performance Analysis of Datagr(DCCP). International Journal ofVol. 3, No. 5, October 2011.

ig. 9. But our algorithm is still ate. It has happened that the gorithm is lesser than the other s constant rate.

ND FUTURE WORKS me up with a new congestion

ased multimedia applications. w applications, like Internet gorithm. This algorithm is not lications where the packet size ave reduced the packet size, ch can give us the unexpected

y to make the algorithm media m able to be used by all kind of ons. Finally, because DCCP is ions which currently use UDP

d congestion control, an area of a layer of reliability on top of

ENCES E. Kohler, Problem statement for Protocol. IETF, RFC 4336, LA, USA,

perimental study of datagram aried network states. Technical Sofia, Bulgaria, 2008. d S. Hasan, Perfomance analysis of Protocol (DCCP), IEEE, In the ference of Computer and Information

g the Use of End-to-End Congestion CM Transactions on Networking,

rimentation of the Datagram Control 2. iccolini and M. Brunner, An

ce Quality over the Datagram ppeared in INFOCOM 2007. 26th n computer communicaations. IEEE, 07, on pages 2009-2017

D. Miras. A Comparative Performance Uk. /lwn.net/Articles/149756/ Floyd, Datagram Congestion

F, RFC 4330, LA, USA, 2006. for Datagram Congestion Control

Control ID 2: TCP-like Congestion USA, 2006. ohler. Profile for DCCP Congestion Control. Internet Engineering Task

adhye. Profile for Datagram CCP), Congestion Control ID 3: RC). IETF, RFC 4342, LA, USA,

Equation based Congestion Control, Institute, California, USA, S. Hasan and C. Rahman.

ram Congestion Control Protocol f Computer Theory and Engineering,

536