Datagram Congestion Control Protocol

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found. 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. FreeBSD had an implementation for version 5.1.[1] Linux also had an implementation of DCCP first released in Linux kernel version 2.6.14 (released October 28, 2005).

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."[2]

DCCP implementations

As of June 2008, at least two DCCP implementations are actively maintained. The Linux kernel implementation was first available in Linux release 2.6.14.[3] The dccp-tp implementation is optimized for portability,[4] but has had no changes since June 2008.[5]

Recently, a new user-space implementation of DCCP has been under way. The purpose of this implementation is to provide a standardized, portable NAT-friendly framework for peer-to-peer communications with flexible congestion control, depending on application.

See also

References

External links

Protocol Specifications

  • RFC 4340 - Datagram Congestion Control Protocol
  • RFC 5595 - The Datagram Congestion Control Protocol (DCCP) Service Codes
  • RFC 5596 - DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
  • RFC 5762 - RTP and the DCCP
  • RFC 5238 - Datagram Transport Layer Security (DTLS) over DCCP
  • RFC 5634 - Quick-Start for DCCP

Congestion Control IDs

  • RFC 4341 - Profile for DCCP Congestion Control ID 2: TCP-like Congestion Control
  • RFC 4342 - Profile for DCCP Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
  • RFC 4828 - Profile for DCCP Congestion Control ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP)

Other Information