Datagram Congestion Control Protocol

Since UDP does not offer congestion control, it is the responsibility of applications to implement appropriate congestion control functions. As it is not easy to program TCP-friendly congestion control into an application, a protocol called the Datagram Congestion Control Protocol (DCCP) was developed by IETF. The basic idea is that this protocol is part of the operating system and it offers congestion control for unreliable applications. DCCP can briefly be described as TCP without byte-stream semantics and reliability, or like UDP with added congestion control, handshakes, and acknowledgments for congestion feedbacks.

Congestion control is not part of DCCP itself. Instead, DCCP allows applications to choose from a set of congestion control mechanisms. Different kinds of congestion control mechanisms can be used with DCCP. Therefore, at least in theory, the congestion control mechanisms developed in this thesis can be used as part of the DCCP world. At this moment, two main mechanisms have been specified: TCP-like Congestion Control (Kohler and Floyd 2006) and TCP-Friendly Rate Control (TFRC) (Floyd et al. 2008). The

62

TCP-like mechanism probes the available bandwidth aggressively. It is suitable for applications that want to use as much bandwidth as possible but can tolerate significant rate fluctuations. TFRC is designed for applications that prefer a smooth rate. Many real-time mulreal-timedia applications are such applications. Therefore, TFRC is discussed in more detail later after a brief introduction of the main DCCP protocol.

3.3.5.1 Main DCCP protocol

Most of the congestion control mechanisms described in this thesis are merely schemes and not complete protocols. A transport protocol often includes many functions that are not necessarily congestion control specific. For example, there are checksums for error checking and port numbers to ensure that applications can be identified. DCCP offers all the necessary functions. Kohler et al. (2006b) introduce the core DCCP protocol. The paper by Kohler et al. (2006a) is also significant because it discusses the motivations behind the design of DCCP. Their paper explains the functions needed for this kind of transport protocol.

DCCP is a connection-based protocol even though it is an unreliable protocol. This guarantees better cooperation with middle-boxes, like firewalls. It also creates ground for feature negotiation. One important feature is CCID, Congestion Control Identity. Every approved congestion control mechanism has its own number for CCID. DCCP connections are bidirectional. Data may pass from both endpoints to the other or only in one direction. Acknowledgements can also be piggybacked by data packets. Logically, however, a DCCP connection consists of two separate unidirectional connections called half-connections. It is possible that a half-connection uses its own congestion control mechanism, which is different to that used by the other half-connection.

3.3.5.2 TCP Friendly Rate Control

TCP Friendly Rate Control (TFRC) (Floyd et al. 2008) is designed to be reasonably fair when competing for bandwidth with TCP flows. It is difficult to define TCP friendliness exactly but Floyd et al. (2008) state that TFRC is "reasonably fair" if its sending rate is generally within a factor of two of the sending rate of a TCP flow under the same conditions. TFRC has a much lower variation in sending rate over time compared to TCP.

This smoothing behavior makes it suitable for applications such as streaming media where a relatively smooth sending rate is important. With a smoothed sending rate, TFRC responds to changes in available bandwidth more slowly than TCP. For this reason, TFRC is not recommended for applications that simply need to transfer as much data as possible in as short a time as possible.

63

TFRC is best suited for applications that use a fixed packet size and respond to congestion by varying the sending rate in packets per second. TFRC can also be used with applications that do not have a fixed packet size, but where the packet size varies according to the needs of the application (for example with video applications). With these kinds of applications, TFRC perhaps does not work in the optimal way. TFRC is not suitable for applications that require a fixed interval of time between consecutive packets and vary their packet size in response to congestion. TFRC is more a receiver-based mechanism than a sender-receiver-based mechanism. Therefore, TRFC is well-suited for an application where the sender is a multi-connection server and the receiver has more processing power for congestion control computation.

TFRC is an equation-based congestion control mechanism. It uses a throughput equation to calculate the allowed sending rate. Because DCCP tries to be fair toward TCP, TFRC uses the TCP throughput equation. This equation describes the TCP sending rate as a function of the loss event rate, round-trip time, and segment size:

𝐵(𝑝) = 𝑠

𝑅𝑇𝑇√^2𝑝₃ + (4𝑅𝑇𝑇 ∗ 3√^3𝑝₈) 𝑝(1 + 32𝑝²)

, (3 − 11)

where:

𝐵(𝑝) = the sending rate bytes/sec 𝑅𝑇𝑇 = the round-trip time

𝑠 = the segment size in bytes 𝑝 = the loss event rate.

Equation 3-11 is the same equation as 2-7 but with the TCP retransmission timeout value set to the value of 4*RTT and the sending rate presented in bytes. It is also supposed that the maximum number of packets acknowledged by a single TCP acknowledgement is one. On the other hand, the unanswered question is why the factor of 1.3 is replaced by the factor of 3.

To simplify, a loss event interval involves a group of packets between two consecutive packet losses. The duration of the loss event interval is at least one RTT so that TFRC does not react to multiple packet losses inside the same window. The loss event rate is the inverse of the number of packets in the particular loss event interval. The receiver measures the weighted average loss event rate. The receiver sends this average information back to the sender. The sender also uses these feedback messages to measure RTTs. The loss event rate and smoothed RTT estimate are then fed into TFRC's throughput equation to obtain the allowed sending rate, which is limited to be at most twice as high as the receive rate. To obtain this receive rate, the receiver continually calculates the received data rate and reports it back to the sender.

64

TFRC is a well-designed congestion control mechanism. All kinds of exceptions have been taken into consideration. For example, if the sender does not receive any feedback report during four round-trip times, the sender halves its sending rate. This is accomplished by a timer known as the no-feedback timer. The so-called data limited period has also been taken into consideration. The data limited period means that the sender cannot send data using the allowed rate because the application layer is unable to deliver enough data to the DCCP entity. There is also an initial slow-start phase, which continues until the first loss event is experienced. In addition to being a well-designed mechanism, TRFC has also been well analyzed by many research studies. These studies often suggest some improvements. For example, Li and Chen (2005) suggested that jitters could be used as a warning for congestion.

In fact, TFRC also contains a delay-based congestion control property, although this property is an optional part of the implementation, which is used to reduce oscillation.

The sender maintains a long-term estimate of the square root of RTT. The sender modifies its sending rate depending on how the square root of the RTT sample differs from the long-term estimate. When the square root of RTT is greater than the long-term estimate, it implies that the queuing delay is probably increasing. In this case, the sending rate is decreased beforehand to minimize oscillation.

There is also the Small-Packet variant of TFRC (TFRC-SP) (Floyd and Kohler 2007) that has been designed for applications that send small packets. It uses the same TCP throughput equation as TFRC. Instead of using an actual segment size in the equation, TFRC-SP version uses a nominal segment size. A typical value for the nominal size is 1460 bytes. In addition, the loss event rate is calculated in a slightly different way. Packet headers have also been taken into account. The allowed sending rate presented in bytes per second is reduced by a factor that takes into account the header sizes of both the network and transport layers. TFRC-SP enforces the use of a minimum interval of 10 milliseconds between data packets to prevent a single flow from sending small packets arbitrarily often.