The Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP implements reliable connection setup, teardown, ECN, congestion control, and feature negotiation. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.

DCCP provides a way to gain access to congestion control mechanisms without having to implement them at the application layer. It allows for flow-based semantics like in TCP, but does not provide reliable in-order delivery. Sequenced delivery within multiple streams as in SCTP is not available in DCCP.

DCCP is useful for applications with timing constraints on the delivery of data that may become useless to the receiver if reliable in-order delivery combined with congestion avoidance is used. Such applications might include streaming media and Internet telephony. Such applications have either settled for TCP or used UDP and implemented their own congestion control mechanisms (or no congestion control at all).

A DCCP connection contains acknowledgment traffic as well as data traffic. Acknowledgments 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 has the option to have very long (48-bit) sequence numbers corresponding to a packet ID (rather than a byte ID as in TCP). The long length of the sequence numbers is intended to guard against "some blind attacks, such as the injection of DCCP-Resets into the connection。

Protocol Structure

The header of the Datagram Congestion Control Protocol is:

Source and Destination Ports: 16 bits each. These fields identify the connection, similar to the corresponding fields in TCP and UDP.

Data Offset: 8 bits. The offset from the start of the packet's DCCP header to the start of its application data area, in 32-bit words.

CCVal: 4 bits. Used by the HC-Sender CCID.

Checksum Coverage (CsCov): 4 bits. Checksum Coverage determines the parts of the packet that are covered by the Checksum field.

Checksum: 16 bits. The Internet checksum of the packet's DCCP header (including options), a network-layer pseudoheader, and, depending on Checksum Coverage, all, some, or none of the application data.

Reserved (Res): 3 bits. Senders MUST set this field to all zeroes on generated packets, and receivers MUST ignore its value.

Type: 4 bits. The Type field specifies the type of the packet. The following values are defined:

Extended Sequence Numbers (X): 1 bit. Set to one to indicate the use of an extended generic header with 48-bit Sequence and Acknowledgement Numbers. Sequence Number: 48 or 24 bits. Identifies the packet uniquely in the sequence of all packets the source sent on this connection.

Sequence Number increases by one with every packet sent, including packets such as DCCP-Ack that carry no application data.

Related Protocols: TCP

Sponsor Source: DCCP is defined by IETF (www.ietf.org)

Reference: http://www.javvin.com/protocol/rfc4340.pdf: Datagram Congestion Control Protocol (DCCP)