Congestion Control

Over the past few years, developers have unveiled a new generation of network applications that transmit and receive multimedia content over the Internet. New multimedia applications based on technologies such as Voice over IP, Internet radio, online gaming, and video conferencing are becoming increasingly popular thanks to the availability of development libraries and the abundance of high-speed networks.

In the past, most Internet applications have used either the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP) to manage communication at the Transport layer of the TCP/IP protocol stack, but multimedia developers now have an alternative to TCP and UDP. IETF recently standardized the Datagram Congestion Control Protocol (DCCP) (RFC4340) [1], a new transport protocol designed to transmit congestion-controlled multimedia content. DCCP is becoming very popular for multimedia data transmission, mainly because it is more effective than UDP at sharing the available bandwidth.

In this article, I examine the DCCP protocol and show how to enable DCCP in Linux. Also, I will explain how to use the GStreamer DCCP plugin to create a simple client-server DCCP application.

DCCP was first introduced by Kohler et al. in July 2001 at the IETF transport group. The DCCP protocol provides specific features designed to address some of the problems developers have faced writing multimedia applications with TCP and UDP, such as delay and jitter caused by network congestion. DCCP offers a connection-oriented transport layer for congestion-controlled but unreliable data transmission. Also, DCCP provides a framework that enables the addition of new congestion-control mechanisms, either added during the connection handshake or negotiated during an established connection. DCCP also provides a mechanism for getting connection statistics, a congestion-control mechanism with Explicit Congestion Notification (ECN) support, and a method for Path Maximum Transmission Unit (PMTU) discovery.

DCCP inherits the connection-oriented and congestion-control features from TCP, and, from UDP, DCCP inherits unreliable transmission.

In addition to connection-oriented and congestion-control features, TCP provides reliable data transfer. This reliability feature limits the transmission rate for a given connection. When packets are lost, TCP decreases its transmission rate, and it increases the transmission rate again when it sends packets successfully. To implement reliable data transfer, when TCP loses packets, it retransmits them. In this case, new data generated by the application is queued until all lost packets are sent. Because of this way of implementing reliable data transfer, TCP might lead to a high level flow delay. Consequently, the user might experience interruptions in multimedia content.

On the other hand, UDP is a simple protocol, implementing minimal functions to transport data from one computer to another. It is a connectionless protocol and does not care about data packet delivery or network congestion control. Also, UDP does not provide packet reordering on the receiver end. Because of the lack of any type of congestion control, UDP might lead to network congestion collapse. Hence, a UDP application can send data as much as it wants, but much of this data might be lost or discarded by the routers because of network congestion.

Before DCCP, multimedia application developers had to choose between TCP and UDP. If they used TCP, end users might experience high streaming delays because of packet retransmission. If they used UDP, the result might be a network collapse or bad streaming quality. DCCP puts together the best features of TCP and UDP to provide higher quality multimedia data streaming and better sharing of bandwidth [2].

DCCP Congestion Control

DCCP offers two congestion-control algorithms, called CCIDs (Congestion Control IDentifiers). The CCIDs are the components responsible for providing congestion control for a DCCP connection. In Linux, CCIDs are kernel modules working on top of the DCCP core implementation. Because they are kernel modules, the CCIDs can be loaded or unloaded at any time, and applications can select a CCID appropriate for the task. For instance, a Voice over IP (VoIP) application is characterized by bursts of small packets followed by periods of silence, whereas a Video on Demand (VoD) application generally transmits multimedia content at a constant bit rate. In this case, it is better for a VoIP application to use a congestion-control technique tailored to VoIP.

Currently there are two standardized CCIDs: CCID-2 and CCID-3. CCID-2 (RFC 4341) [3] is better for applications that use the maximum bandwidth available at the network, but it can easily be adapted to sudden bandwidth changes. It is similar to TCP congestion control, which is based on the congestion window concept. The congestion window size dictates how many packets the sender is allowed to transmit over the network. This means that the bigger the congestion window size, the more packets TCP sends over the network. When DCCP CCID-2 detects a packet loss, it halves the congestion window, which is an abrupt change in the transmission rate, especially for multimedia applications.

In the initial transmission state, the congestion window size increases in an exponential fashion as the sent packets are acknowledged, until it reaches the congestion-avoidance phase. At this point, CCID-2 increases the congestion window size by 1 when the receiver acknowledges a packet.

On the other hand, CCID-3 (RFC 4342) [4] implements a receiver-based congestion control algorithm in which the sender is rate-limited by the receiver. Periodically, the receiver sends feedback packets to the sender containing lost event information and other connection statistics that are plugged into the TCP-Friendly Rate Control equation (TFRC) (RFC 3448) [5].

TFRC is reasonably fair when competing for bandwidth with TCP flows, but it has a lower variation of throughput over time compared with other TCP congestion-control mechanisms, making it more suitable for applications such as telephony or streaming media, for which a relatively smooth sending rate is important.

Set Up the Environment

To start exploring the world of DCCP on Linux, you first need to enable DCCP in the Linux kernel and then install some applications to test your environment.Because DCCP is a new protocol, it is in constant development. If you want the latest available changes for the DCCP implementation in the Linux kernel, you must fetch the kernel from the DCCP git test tree repository [6], which is managed by the git tool, a version control system used by kernel developers. After you have installed git – it is available from package managers such as emerge, apt-get, and urpmi – you can fetch the entire kernel source tree, including the DCCP source subtree, as follows:

git-clone git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp

The my_dccp argument is the directory where git will put the fetched Linux kernel source code. This directory must not exist. If you have a fairly recent git kernel source, you can speed up the fetching process by passing to the git-clone command the directory as a reference:

git-clone --reference old_git_kernel git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp

In both cases, git-clone will take a while to fetch the kernel source from over the network. While you wait for the end of the fetch process, you can read about DCCP on Linux wiki [7] to learn more about DCCP. Once git has downloaded the Linux kernel containing the latest available version of DCCP, enter in the newly created directory (in my example, the my_dccp directory) and check out the DCCP branch:

git-checkout --track -b dccp origin/dccp

This command will effectively give you the latest changes of the DCCP source code. For future updates of the DCCP source code, run the following command in the source folder:

git-pull git://eden-feed.erg.abdn.ac.uk/dccp_exp dccp

The dccp argument is not a folder; it is the branch previously created with git-checkout.

Now that you have the Linux kernel source code with the latest changes of the DCCP subtree, you'll need to set up the kernel according to your machine architecture. Inside the kernel source directory, the Linux kernel configuration is described in the .config file. You can change this configuration both from make menuconfig or by directly editing the .config file. To determine what Linux modules are up, use lsmod, and use lspci to get a list of devices. Additionally, look in your hardware documents and vendor support. For more on compiling the kernel, refer to the Linux kernel documentation [8].

If you are familiar with the Linux kernel compilation process, use the menuconfig mechanism to specify the Linux kernel options; DCCP is enabled under the Networking option as follows:

Networking -->
   Network options -->
      The DCCP Protocol -->

Inside this option, you can specify the CCIDs and some other DCCP options. After you select everything you need, just compile the kernel using instructions specified in the documentation [8]. After you load your new compiled kernel, you can switch between the CCIDs and change the sequence window number by running the following commands:

sudo sysctl -w net.dccp.default.seq_window=1000
sudo sysctl -w net.dccp.default.rx_ccid=2
sudo sysctl -w net.dccp.default.tx_ccid=2

This set specifies 1000 as the sequence window and CCID-2 in both directions for all connections started by DCCP. Note that you also can specify these parameters through a programming language using the setsockopt socket function.

Testing DCCP

IPerf is a network measurement tool that was originally designed to work over TCP and UDP. But thanks to a patchset provided by Gerrit Renker, it also supports the DCCP protocol, wherein you can run it as a DCCP client or a server. To use IPerf with DCCP support, first download and install IPerf [9]. If you are lucky, the process of compiling and installing is straightforward with the make and make install procedures. The site also provides useful information on IPerf with DCCP.

To test DCCP, set a server with the following arguments:

iperf -s -d -l 1424 -i 1

This command tells IPerf to open a DCCP connection (-d option) and to act as a server (-s option). The server will transmit data packets of size 1424 bytes (-l 1424), and it will output reports about the transmission every one second. To run an IPerf client that will connect to the specified server, execute the following command:

iperf -c SERVER_IP -d -l 1424 -i 1 -t 100

The -c option specifies the server IP, and -t specifies the duration of the transmission, in seconds. For a quick introduction to DCCP, consider a simple Python application that sends hello world to a remote application. The Python DCCP server code is shown in Listing 1, and the Python DCCP client is in Listing 2.

In line 7 of Listing 1, the socket instantiation is done using the values of socket.SOCK_DCCP and socket.IPPROTO_DCCP. socket.IPPROTO_DCCP is equal to 33, which is the number allocated to the DCCP protocol by IANA (Internet Assigned Numbers Authority). The other lines are very similar to an implementation of a TCP socket connection. The client in Listing 2 connects to the DCCP server implemented in Listing 1.

Now that the server and client are communicating, it is time to add some additional multimedia features through the GStreamer framework.

GStreamer is an open source multimedia framework that allows the programmer to write many types of streaming multimedia applications [10]. Many well-know applications use GStreamer, such as Kaffeine, Amarok, Phonon, Rhythmbox, and Totem. The GStreamer framework facilitates the process of writing multimedia applications, ranging from audio and video playback to streaming multimedia content.