Introduction about DCCP

Previous

1.0.- Introduction about DCCP

Datagram Congestion Control Protocol (DCCP) is a new transport protocol designed by the Internet Engineering Task Force. The draft draft-ietf-dccp-spec-03.txt written by Eddie Kohler, Mark Handley, Sally Floyd and Jitendra Padhye in May 2003 specifies the protocol. Here I'm trying to make a brief summary of this document:

The framework (by me)

DCCP is a new transport protocol being designed by IETF to replace UDP as the protocol to be used to transport real-time traffic, but not limited to this type of traffic. The IETF working group in charge of the DCCP specifications is being led by Sally Floyd, a person who has dedicated her entire all life to study the congestion control problem in networks, to give her unvaluable support to the design of the congestion avoidance algorithm implemented in TCP, and that is one of the person in the all world that better known the intrinsic behavior of transport protocols, and their relationship with the necessity to avoid congestion problems in interest of the health of Internet. We are then, in the best hands.

As long as everyday, more and more real-time applications are running over Internet, then the problem of approaching a good congestion avoidance control in the net has been in increase. Due to their intrisic nature, real-time applications require a very fast and low overhead transport protocol. Because, again, the intrinsic nature of TCP, it can't be used, and all these application designers has dumped to UDP as their mean to transports their application packets throughout the Internet.

But UDP has a big problem that attempt against the health of Internet. It does not implement any kind of congestion avoidance control algorithm and for this, its flows are very aggressive, it does not respond lowering its throughput when packet dropping indicate the presence of congestion, and it starves other TCP and TCP-like flows, that being more friendly or good citizen protocols, adjust themselve their throughput in presence of congestion to alleviate the situation and allowing Internet to recover its health state.

Then, the more frequently use of UDP is really a truly "troyan horse" that we have in Internet. Fortunately, up to now at least, UDP presence in Internet is small enough when it is compared with TCP presence, being the problem yet under control. Nevertheless, because real-time applications are being requested everyday more and more, time has arrived to look for a prompt solution to this problem. That's the reason why IETF decided to design a new trasport protocol to replace UDP in the, we hope, near future.

The new protocol is called Datagram Congestion Control Protocol (DCCP) and is in the designing and testing phase at this moment.

Introduction

DCCP will provide the following features:

An unreliable flow of datagrams, with acknowledgements.
A reliable handshake for connection setup and teardown.
Reliable negotiation of options, including negotiation of a suitable congestion control mechanism.
Mechanisms allowing a server to avoid holding any state for unacknowledged connection attempts or already-finished connections.
Optional mechanisms that tell the sender, with high reliability, which packets reached the receiver, and whether those packets were ECN marked, corrupted, or dropped in the receive buffer.
Congestion control incorporating Explicit Congestion Notification (ECN) and the ECN Nonce, as per [RFC 3168] and [ECN NONCE].
Path MTU discovery, as per [RFC 1191].

The purpose of DCCP is to provide a standard way to implement congestion control and congestion control negotiation for real-time applications. One of the motivations for DCCP is to enable the use of ECN, along with conformant end-to-end congestion control, for applications that would otherwise be using UDP. In addition, DCCP implements reliable connection setup, teardown, and feature negotiation.

A DCCP connection contains acknowledgement traffic as well as data traffic. Acknowledgements inform a sender whether its packets arrived, and whether they were ECN marked. Acks are transmitted as reliably as the congestion control mechanism in use requires, possibly completely reliably.

DCCP is intended to be used by applications that currently use UDP without end-to-end congestion control. The desire is for many applications to have little reason not to use DCCP instead of UDP, once DCCP is deployed. Thus, DCCP was designed to have as little overhead as possible, in terms both of the size of the packet header and in terms of the state and CPU overhead required at the end hosts.

A second motivation behind the design of DCCP is to allow applications to choose an alternative to the current TCP-style congestion control that halves the congestion window in response to a congestion indication. DCCP lets applications choose between several forms of congestion control. One choice, TCP-like congestion control, halves the congestion window in response to a packet drop or mark, as in TCP. A second alternative, TFRC (TCP-Friendly Rate Control, a form of equation-based congestion control), minimizes abrupt changes in the sending rate while maintaining longer-term fairness with TCP.

Previous

Content

Next