Datagram Congestion Control Protocol

The Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. DCCP was published as RFC 4340, a proposed standard, by the IETF in March, 2006. RFC 4336 provides an introduction.

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 Transmission Control Protocol (TCP), but does not provide reliable in-order delivery. Sequenced delivery within multiple streams as in the Stream Control Transmission Protocol (SCTP) is not available in DCCP.

DCCP is useful for applications with timing constraints on the delivery of data. Such applications include streaming media, multiplayer online games and Internet telephony. The primary feature of these applications is that old messages quickly become stale so that getting new messages is preferred to resending lost messages. Currently such applications have often either settled for TCP or used User Datagram Protocol (UDP) and implemented their own congestion control mechanisms, or have no congestion control at all.

While being useful for these applications, DCCP can also be positioned as a general congestion control mechanism for UDP-based applications, by adding, as needed, a mechanism for reliable and/or in-order delivery on the top of UDP/DCCP. In this context, DCCP allows the use of different, but generally TCP-friendly congestion control mechanisms.

A DCCP connection contains acknowledgment traffic as well as data traffic. Acknowledgments inform a sender whether its packets have arrived, and whether they were marked by Explicit Congestion Notification (ECN). Acknowledgements are transmitted as reliably as the congestion control mechanism in use requires, possibly completely reliably.

DCCP has the option for 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."[1]

Implementations

The following operating systems implement DCCP:

Userspace library:

Packet Structure

The DCCP generic header takes different forms depending on the value of X, the Extended Sequence Numbers bit. If X is one, the Sequence Number field is 48 bits long, and the generic header takes 16 bytes, as follows.

DCCP generic header
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
0 0 Source port Destination port
4 32 Data Offset CCVal CsCov Checksum
8 64 Res Type X=1 Reserved Sequence Number (high bits)
12 96 Sequence Number (low bits)

If X is zero, only the low 24 bits of the Sequence Number are transmitted, and the generic header is 12 bytes long.

Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031
0 0 Source port Destination port
4 32 Data Offset CCVal CsCov Checksum
8 64 Res Type X=0 Sequence Number (low bits)
Source port (16 bits)
Identifies the sending port
Destination port (16 bits)
Identifies the receiving port
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
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

See also

References

  1. ↑ RFC 4340 section 7.6
  2. ↑ https://www.ietf.org/mail-archive/web/dccp/current/msg00508.html
  3. ↑ Linux gets DCCP
  4. ↑ Change log for the dccp-tp wiki, retrieved June 13, 2011

External links

Protocol Specifications

Congestion Control IDs

Other Information

This article is issued from Wikipedia - version of the 11/12/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.