Hubbry Logo
Datagram Congestion Control ProtocolDatagram Congestion Control ProtocolMain
Open search
Datagram Congestion Control Protocol
Community hub
Datagram Congestion Control Protocol
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Datagram Congestion Control Protocol
Datagram Congestion Control Protocol
Datagram Congestion Control Protocol
View on Wikipedia
from Wikipedia
Datagram Congestion Control Protocol
Communication protocol
AbbreviationDCCP
Introduction ()
OSI layerTransport layer (4)
RFC(s)4340, 4336
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

In computer networking, 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. The IETF published DCCP as RFC 4340, a proposed standard, in March 2006. RFC 4336 provides an introduction.

Operation

[edit]

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. 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 aims to guard against "some blind attacks, such as the injection of DCCP-Resets into the connection".[1]

Applications

[edit]

DCCP is useful for applications with timing constraints on the delivery of data. Such applications include streaming media, multiplayer online games and Internet telephony. In such applications, old messages quickly become useless, so that getting new messages is preferred to resending lost messages. As of 2017 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 serve as a general congestion-control mechanism for UDP-based applications, by adding, as needed, mechanisms for reliable or in-order delivery on top of UDP/DCCP. In this context, DCCP allows the use of different, but generally TCP-friendly, congestion-control mechanisms.

Implementations

[edit]

The following operating systems implement DCCP:

  • FreeBSD, version 5.1 [2] as patch
  • Linux since version 2.6.14,[3] but marked deprecated since version 6.4 due to lack of maintenance and scheduled for removal in 2025.[4] Linux 6.16 drops DCCP.[5]
    • DCCP was removed from Linux 6.16.[6]

Userspace library:

  • DCCP-TP Archived 2008-07-23 at the Wayback Machine implementation is optimized for portability, but has had no changes since June 2008.[7]
  • GoDCCP 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.

Packet structure

[edit]

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 (X = 1)
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source Port Destination Port
4 32 Data Offset CCVal CsCov Checksum
8 64 Res Type X Reserved Sequence Number (high bits)↴
12 96 ↪Sequence Number

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

DCCP generic header (X = 0)
Offset Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Source Port Destination Port
4 32 Data Offset CCVal CsCov Checksum
8 64 Res Type X Sequence Number
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; Res == 0
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.

Current development

[edit]

Similarly to the extension of TCP protocol adding multipath capability (MPTCP), a multipath extension of DCCP is under discussion at the IETF,[8] correspondingly denoted as MP-DCCP. First implementations have already been developed, tested, and presented in a collaborative approach between operators and academia[9] and are available as an open source solution.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Datagram Congestion Control Protocol

View on Grokipedia
from Grokipedia
The Datagram Congestion Control Protocol (DCCP) is a protocol designed to provide a congestion-controlled flow of unreliable datagrams over the , offering bidirectional connections suitable for applications that prioritize low latency and can tolerate some . It fills a gap between UDP, which lacks congestion control and can exacerbate , and TCP, which enforces reliability through retransmissions that introduce delays unsuitable for real-time traffic. Standardized by the (IETF) in March 2006 as a proposed standard, DCCP enables flexible congestion control mechanisms through pluggable Congestion Control Identifiers (CCIDs), allowing adaptation to diverse network conditions without mandating in-order or guaranteed delivery. DCCP establishes connections via a reliable three-way —using DCCP-Request, DCCP-Response, and DCCP-Ack packets—to negotiate features and sequence numbers for loss detection, while data transfer remains unreliable with no automatic retransmissions. It incorporates acknowledgment mechanisms, such as Ack Vectors for detailed reporting of packet losses and (ECN) marks, to provide feedback on congestion without relying solely on packet drops. Path (PMTU) discovery is supported to optimize packet sizing and avoid fragmentation, enhancing efficiency in varied network paths. Optional partial checksums allow applications to trade for faster delivery in loss-tolerant scenarios. Key congestion control options include CCID 2, which employs a TCP-like Additive Increase Multiplicative Decrease (AIMD) algorithm to aggressively pursue maximum bandwidth, and CCID 3 based on TCP-Friendly Rate Control (TFRC), which delivers smoother sending rates ideal for media streaming by minimizing abrupt changes. These mechanisms ensure DCCP remains fair to TCP traffic while supporting applications like online gaming, , and (RTP) streams, where timeliness outweighs perfect reliability. Connection teardown uses reset codes to handle errors gracefully, maintaining network stability. Subsequent updates, such as those in RFC 5595 and RFC 5596, refined DCCP's service codes and added features like simultaneous-open to better accommodate multimedia flows and improve interoperability, though core functionality remains anchored in the original specification. Overall, DCCP addresses the need for congestion-aware datagram transport in bandwidth-constrained environments, promoting equitable resource sharing across the Internet.

Overview

Design Goals

The Datagram Congestion Control Protocol (DCCP) was developed to address the limitations of existing transport protocols for applications requiring unreliable datagram delivery with integrated congestion control. provides lightweight, unreliable transport but lacks built-in mechanisms to prevent , which can lead to widespread instability, particularly for real-time applications such as , (VoIP), and online gaming. In contrast, Transmission Control Protocol (TCP) enforces reliability through retransmissions and ordered delivery, introducing delays that are unnecessary and detrimental for these time-sensitive flows. The protocol's design thus fills this gap by enabling datagram-based applications to participate in congestion avoidance without the overhead of reliability guarantees. Central to DCCP's objectives is the provision of minimal mechanisms focused solely on congestion control, avoiding features like retransmissions or in-order delivery to maintain efficiency and scalability. It supports variable-rate flows, such as those in streaming, by incorporating congestion control profiles like TCP-like (CCID 2) for bursty traffic and TCP-Friendly Rate Control (TFRC, CCID 3) for smoother, rate-based transmission. Additionally, DCCP emphasizes flexibility through reliable feature negotiation, allowing endpoints to agree on options like congestion control methods and tolerance during connection setup. These goals ensure that DCCP can adapt to diverse application needs while promoting fair resource sharing on the . The motivations for DCCP arose from persistent Internet congestion problems documented since the 1980s, exacerbated in the 1990s and early 2000s by the growth of bandwidth-intensive traffic. Early incidents, such as those analyzed in Van Jacobson's seminal work on congestion avoidance, highlighted the need for end-to-end controls to prevent router overload and packet drops. This led to IETF efforts to create UDP-like protocols with "TCP-friendly" congestion control, as outlined in specifications like RFC 2581 for TCP congestion and RFC 3168 for (ECN). DCCP's core design principles reinforce these objectives through unreliable delivery, where datagrams are sent without guarantees of arrival or order, prioritizing timely transmission over completeness. It integrates ECN to allow routers to signal incipient congestion via marked packets, enabling proactive rate reduction without packet loss. Furthermore, the protocol handles half-open connections—common in unidirectional or interrupted flows—using synchronization packets and sequence numbers to resynchronize endpoints robustly, ensuring graceful recovery from disruptions. These principles collectively aim to foster a stable, efficient Internet for emerging datagram applications.

Key Features

The Datagram Congestion Control Protocol (DCCP) provides support for unreliable, congestion-controlled datagram delivery over IP networks, enabling bidirectional connections that incorporate congestion avoidance mechanisms while preserving the datagram-oriented nature of UDP. This design fills a gap between UDP, which lacks any congestion control, and TCP, which enforces reliability through byte-stream delivery, by offering a protocol suitable for applications like or that prioritize timeliness over perfect reliability. DCCP mandates the use of congestion control through pluggable profiles known as Congestion Control IDs (CCIDs), allowing endpoints to select mechanisms such as the TCP-like CCID 2 for aggressive throughput or the TCP-friendly rate-based CCID 3 for smoother rate adjustments in variable-bandwidth scenarios. These profiles are negotiated independently for each direction of the connection, ensuring flexibility and adherence to network fairness principles without imposing a one-size-fits-all approach. During connection establishment, DCCP facilitates feature negotiation using Change and Confirm options, which enable reliable agreement on parameters such as (ECN) capability and acknowledgment frequency, with safeguards against reordering through sequence number validation. This mechanism supports half-connection states, where each unidirectional data flow operates semi-independently to accommodate firewalls and (NAT) devices, while providing distinct acknowledgment modes—ranging from per-packet feedback to cumulative summaries—for efficient sender-side loss detection and congestion response. DCCP integrates seamlessly with ECN, allowing routers to signal incipient congestion via marked packets rather than drops, thereby enabling proactive rate adjustments and reducing latency in loss-sensitive applications. Unlike TCP's byte-stream model, DCCP treats packets as self-contained datagrams, each bearing 48-bit sequence numbers that increment per packet for ordering, loss detection, and security against replay attacks, thus maintaining packet boundaries and supporting variable-sized payloads without fragmentation concerns at the .

History and Standardization

Development

The development of the Datagram Congestion Control Protocol (DCCP) originated in the early within the IETF Transport Area, driven by the need to provide congestion control for unreliable datagram flows in multimedia applications such as and , where timeliness is prioritized over delivery guarantees. These applications often relied on UDP, which lacked built-in congestion avoidance, leading to potential collapse as grew. The effort built on prior research into equation-based congestion control mechanisms, aiming to enable UDP-like simplicity while incorporating TCP-friendly rate control to coexist fairly with existing traffic. Key contributors to DCCP's design included Eddie Kohler of UCLA, Mark Handley of , and Sally Floyd of the ICSI for Internet Research, who collaborated under support to produce the initial protocol specification. The first outlining the core protocol, draft-kohler-dcp-00, was published in July 2001, introducing concepts like modular congestion control profiles and explicit connection setup for unreliable transport. This early work addressed limitations in UDP by integrating feedback mechanisms for loss detection and rate adjustment, without the overhead of TCP's reliability features. The IETF formalized the project by chartering the DCCP Working Group in June 2002, tasking it with standardizing a minimal transport protocol for bidirectional, congestion-controlled datagrams suitable for real-time applications. During development, DCCP maintained experimental status through multiple iterations of drafts, allowing for iterative testing and refinement from 2001 to 2006. A primary motivation was mitigating UDP's congestion issues while avoiding the delays inherent in TCP's retransmissions, drawing from earlier explorations of congestion control for non-reliable flows. The protocol's designers emphasized modularity, enabling pluggable congestion control IDs (CCIDs) based on established IETF mechanisms like TCP-like or TFRC profiles. Significant challenges arose in balancing DCCP's minimalist design—limited to essential features like connection management and acknowledgments—with robustness against sequence number attacks, synchronization issues, and varying network conditions. Extensive simulations and implementations were conducted to verify TCP-friendliness, ensuring DCCP flows did not unfairly consume bandwidth relative to TCP under the same conditions, as required by IETF guidelines. For instance, testing focused on representative scenarios like bulk transfers and variable-bitrate streaming to validate low-latency without exacerbating congestion. The DCCP Working Group achieved a major milestone with the publication of RFC 4340 in March 2006, which advanced the protocol to Proposed Standard status and detailed its core operations, including packet types and feature negotiation. Accompanying RFCs, such as 4341 for TCP-like congestion control and 4342 for TFRC, completed the initial suite. Following these releases, the group shifted to maintenance tasks, including errata resolution and minor extensions, with active milestones completed by mid-2008. The WG was formally concluded in November 2012, signifying the protocol's maturity after over a decade of collaborative evolution.

RFCs and Specifications

The primary specification for the Datagram Congestion Control Protocol (DCCP) is RFC 4340, published in March 2006, which defines the core protocol including connection management, packet types, feature negotiation, and the framework for congestion control via pluggable Congestion Control IDs (CCIDs). This document establishes DCCP as a transport-layer protocol offering unreliable, congestion-controlled delivery for applications like . Supporting RFCs detail specific aspects and profiles. RFC 4341, also from March 2006, specifies CCID 2 for TCP-like congestion control, emulating TCP's congestion window and loss-based adjustments to provide familiarity for developers while adapting to datagram semantics. RFC 4342, published concurrently, defines CCID 3 using TCP-Friendly Rate Control (TFRC), a rate-based mechanism that aims for smooth throughput and fairness with TCP over varying loss rates, particularly beneficial for real-time applications. Error detection in DCCP, including partial coverage to allow discarding only corrupted portions of packets, is integrated into the core specification in RFC 4340. Subsequent RFCs extend the protocol's capabilities. RFC 5622, issued in August 2009, introduces CCID 4 as a small-packet variant of TFRC (TFRC-SP), optimized for scenarios with frequent small s like voice-over-IP by adjusting loss event detection for shorter feedback intervals. RFC 4336 from March 2006 outlines the problem statement motivating DCCP's design, highlighting needs for congestion control in unreliable datagram flows without TCP's reliability overhead. Ack Vectors, which enable efficient acknowledgment of non-contiguous packet reception using , are specified in RFC 4340. RFC 5595 (September 2009) and RFC 5596 (September 2009) specify DCCP service codes and handling of slow receivers, respectively, to improve flow support and interoperability. RFC 6335 (August 2011) updates IANA procedures for managing service names and transport protocol port numbers, including for DCCP. RFC 6773 (November 2012) defines a UDP encapsulation (DCCP-UDP) to facilitate . The DCCP specifications have remained stable since , with no major overhauls but ongoing minor clarifications through errata; for instance, RFC 4342 was updated by RFC 5348 in 2008 for CCID 3 parameter refinements. These documents emerged from the IETF DCCP efforts in the mid-2000s to address gaps in UDP and TCP for multimedia transport.

Protocol Operation

Connection Setup and Teardown

The Datagram Congestion Control Protocol (DCCP) establishes connections through a multi-packet that ensures and without requiring full state allocation on the server until confirmation. The process begins with the client sending a DCCP-Request packet, which includes a 32-bit Service Code identifying the application-level service and a random 48-bit initial (with the header X bit set to 1 indicating full 48-bit length) to initiate ordering and provide through unpredictability. The server responds with a DCCP-Response packet acknowledging the client's sequence number via the Global Sequence Number (GSR) and echoing the Service Code, thereby partially confirming the request while optionally including an Init Cookie for added . To complete the handshake, the client sends a DCCP-Ack packet acknowledging the server's sequence number and, if present, echoing the Init Cookie back to the server. This step transitions the connection from unconfirmed states—such as REQUEST on the client side after sending DCCP-Request or RESPOND on the server after DCCP-Response—to active states like OPEN or ESTABLISHED, often via a transitional PARTOPEN state. The Init Cookie mechanism serves as a feature against denial-of-service attacks like SYN floods by delaying server resource allocation until the client demonstrates commitment through this , without significantly impacting legitimate connections. Sequence numbers play a critical role throughout, incrementing per packet to detect losses, prevent replay attacks, and verify endpoint validity during these initial exchanges. Half-open connections arise during setup if the server sends a DCCP-Response without allocating full connection state, awaiting the client's DCCP-Ack for final ; this design minimizes vulnerability to resource exhaustion. Feature negotiation, including selection of congestion control profiles, occurs reliably within these packets using Change and Confirm options. Connection teardown in DCCP follows a structured to ensure graceful closure or abrupt termination as needed. Due to the client-server asymmetry, normal closure differs based on which endpoint initiates. If the server initiates, it sends a DCCP-CloseReq packet to request closure, prompting the client to respond with a DCCP-Close packet; the server then sends a DCCP-Reset packet with Reset Code 1 ("Closed") to finalize the teardown. If the client initiates, it sends a DCCP-Close packet directly, and the server responds with a DCCP-Reset packet with Code 1 ("Closed"). In both cases, the receiver of the Reset enters the TIMEWAIT state for 2*MSL (typically ) to handle stray packets, while the sender transitions to CLOSED. For abrupt termination, such as in conditions, a DCCP-Reset with codes like 2 ("") or 3 ("No Connection") can be sent unilaterally without prior exchanges. The overall state machine governs these transitions, starting from unconfirmed initiation states and progressing to active data-ready states upon completion, then to closure upon teardown signals, ensuring reliable endpoint synchronization throughout.

Data Transfer

In DCCP, data transfer occurs once a connection is established, relying on specific packet types to exchange application without the reliability guarantees of TCP. The primary packets used are DCCP-Data for transmitting application data without acknowledgment, DCCP-DataAck for combining data with piggybacked acknowledgments, and DCCP-Ack for standalone acknowledgments when no data is sent. DCCP-Sync packets assist in resynchronizing sequence numbers after potential losses, ensuring alignment for ongoing data flow. These packets enable unreliable, congestion-controlled delivery suitable for applications like or . Sequence numbers in DCCP increment by one for each sent packet, rather than per byte, facilitating loss detection within defined windows without requiring retransmissions. A sequence validity window, bounded by Sequence Window Low (SWL) and Sequence Window High (SWH) values, determines whether incoming packets are valid; the default window size is 100, with a minimum of 32 and a maximum of 2^46 - 1. Receivers use an Ack Vector—a run-length encoded structure—to report loss history based on these windows, allowing senders to detect gaps in sequence numbers indicative of dropped packets. This approach prioritizes forward progress over recovery, distinguishing DCCP from retransmission-based protocols. Out-of-order or duplicate packets are handled through sequence validity checks: valid duplicates are typically ignored unless explicitly marked as lost in prior acknowledgments, while invalid packets (outside the SWL-SWH window) trigger a Sync exchange to realign sequences. Acknowledgment modes in DCCP provide flexibility to balance feedback overhead and reverse-path congestion. In Send Ack mode, the receiver acknowledges every valid packet immediately upon processing its header, using DCCP-SyncAck or full Ack Vectors for cumulative feedback, which is negotiated via feature options. Alternatively, Ack Ratio mode allows the sender to control acknowledgment frequency—defaulting to 1 acknowledgment per 2 data packets—to reduce load on the return path, mimicking TCP-like behavior while adapting to congestion signals. The Ack Vector enhances both modes by encoding detailed loss intervals, such as runs of received or lost packets, enabling precise feedback without excessive bandwidth use. Application payloads integrate directly into DCCP without segmentation or reassembly at the ; datagrams are passed as-is from the application to the protocol, encapsulated in or DataAck packets for transmission. This preserves the datagram-oriented nature of UDP while adding congestion control, ensuring payloads arrive intact or are discarded entirely based on network conditions. During transfer, rate limiting is imposed through congestion signals, such as ECN markings or Data Dropped options conveyed via acknowledgments, which adjust sending rates in coordination with the selected congestion control profile.

Packet Format

Header Structure

The Datagram Congestion Control Protocol (DCCP) employs a generic packet header that forms the core of every DCCP packet, consisting of a fixed 12-byte when using 24-bit sequence numbers or an extended 16-byte when using 48-bit sequence numbers. This header includes essential fields for addressing, integrity, and basic protocol control, but excludes congestion control identifiers (CCIDs) and negotiable options, which are handled separately. The header begins with 16-bit source and destination ports to identify endpoints, followed by an 8-bit data offset field indicating the header length in 32-bit words (typically 3 for the basic header, up to 15 including options). Next are a 4-bit CCVal field for congestion control-specific values and a 4-bit CsCov field specifying checksum coverage (0 for full coverage of header, options, and data; 1-15 for partial coverage excluding some data bytes). A 16-bit follows, computed over the covered portions using the TCP/IP checksum algorithm. The header then includes 3 reserved bits (set to 0), a 4-bit Type field defining the packet type (values 0-15), and a 1-bit X flag indicating extended sequence numbers. The sequence number field occupies 24 bits when X=0 or 48 bits when X=1, with the latter split into low 24 bits in the basic header and high 24 bits in an additional 32-bit word (padded if needed). DCCP defines 16 packet types via the Type field, enabling distinct functions such as connection initiation and data acknowledgment; for example, type 0 (DCCP-Request) starts a connection, type 2 (DCCP-Data) carries application data, type 3 (DCCP-Ack) provides acknowledgments, and types 10-15 are reserved. These types determine additional variable-length fields immediately following the generic header; notably, a 32-bit service code appears in DCCP-Request and DCCP-Response packets to identify the requested application service. The CsCov field further influences variable coverage for the , allowing senders to exclude trailing data bytes for performance in lossy networks. Sequence numbers are 48-bit values when extended mode is used, generated by incrementing a counter by 1 for each outgoing packet and applying circular arithmetic 2^48 to ensure long-term uniqueness across connections. The initial sequence number is chosen randomly or based on a to avoid predictability, supporting loss detection without byte-stream semantics. No options are part of the generic header itself; instead, they are appended after type-specific fields in a variable-length section for extensibility. The layout of the basic 12-byte generic header (X=0) can be represented as follows:

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Offset | CCVal | CsCov | [Checksum](/page/Checksum) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (3) | Type (4) |X| Sequence Number (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Offset | CCVal | CsCov | [Checksum](/page/Checksum) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved (3) | Type (4) |X| Sequence Number (24) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For the extended 16-byte header (X=1), an additional 32-bit word follows, containing the high 24 bits of the number in the upper bits, with the lower 8 bits . Packet types like DCCP-Ack include an additional 48-bit acknowledgment number after the generic header to report the greatest number received.

Options and Features

DCCP employs a flexible options mechanism to negotiate and extend protocol behavior, allowing endpoints to customize aspects of the connection such as congestion notification and acknowledgment frequency. Each option follows a standardized format: an 8-bit Kind field identifies the option type (ranging from 0 to 255), followed by an optional 8-bit Length field (present if Kind > 31) that specifies the total option size in bytes (minimum 2), and a variable-length Value field containing the specific . Options are placed in the variable-length Options section following the fixed header in DCCP packets. Negotiation distinguishes between mandatory and changeable options; mandatory options, prefixed with the Mandatory option (Kind 1), require compliance, while changeable options support dynamic adjustment. The process uses Offer/Change options to propose values during connection handshakes or ongoing communication, with Confirm options in responses to acknowledge agreements. For changeable features, endpoints initiate changes via Change L (left-to-right, Kind 32) or Change R (right-to-left, Kind 34) options, which are retransmitted until confirmed, and responses use Confirm L (Kind 33) or Confirm R (Kind 35). Conflicts in are resolved through reconciliation rules for changeable options, but unnegotiable mandatory options trigger a connection reset with Reset Code 6 (Unnegotiable Mandatory). Invalid options, such as those with incorrect lengths, may result in an empty Confirm or a reset with Reset Code 5 (Option Error). Key features negotiated via options include Explicit Congestion Notification (ECN) capability, which enables receivers to report congestion using the Ack Vector option (Kinds 38 or 39) without relying on packet loss; the initial value is 0 (not capable), but it can be set to 1 (capable) during negotiation. The ACK Ratio feature (feature number 5) controls how often acknowledgments are sent, defaulting to 2 (one ACK per two data packets), and supports values from 1 to 65535 to balance feedback overhead. The Sequence Window (feature number 3) defines the range for packet ordering and duplicate detection, initialized to 100 and adjustable from 32 to 2^46-1. Loss tolerance is addressed through the Data Dropped option (Kind 40), which reports dropped packets with codes indicating reasons like protocol constraints (code 0) or buffer overflow (code 1). Specific options enhance reliability and security; the Slow Receiver option (Kind 2) signals receiver overload, prompting the sender to maintain its current rate for approximately one round-trip time to avoid overwhelming slow starts. The Init Cookie option (Kind 36) provides denial-of-service by including a server-generated in the DCCP-Response packet, verifying the client's legitimacy during connection setup. Standard options defined in RFC 4340 are categorized by Kind values, with global options (0-127) applicable universally, feature-specific options (128-191) for negotiation like ECN or ACK Ratio, and receiver options (192-255) for endpoint-specific extensions. The following table lists key standard options:
KindNameLength (Bytes)Description
0VariablePads packets for alignment.
1MandatoryVariablePrefixes mandatory options.
2Slow Receiver1Indicates receiver pacing needs.
32Change LVariableProposes left-to-right feature change.
33Confirm LVariableAcknowledges left-to-right change.
34Change RVariableProposes right-to-left feature change.
35Confirm RVariableAcknowledges right-to-left change.
36Init CookieVariableCookie for setup validation.
37NDP Count3-8Counts non-data packets for diversity.
38/39Ack VectorVariableEncodes acknowledgments and ECN feedback.
40Data DroppedVariableReports dropped data with codes.
128-191FeatureVariableNegotiates protocol features (e.g., ECN=4).
Experimental options occupy 120-126.

Congestion Control

Mechanisms

The Datagram Congestion Control Protocol (DCCP) employs several core mechanisms to detect and avoid congestion in unreliable datagram flows, ensuring fair sharing of network resources without relying on packet drops as the primary signal. Central to these is the integration of (ECN), which allows routers to mark packets indicating incipient congestion rather than discarding them, thereby preserving bandwidth and providing timely feedback to endpoints. ECN support is negotiated during connection setup via the ECN Incapable feature, and receivers report marked packets through acknowledgment options to enable senders to react appropriately. Loss detection in DCCP relies on acknowledgment feedback from receivers, which use Ack Vectors to convey the state of recently received packets, including indications of losses or ECN marks. An Ack Vector consists of a sequence of bits representing packet states—such as received (state 0), received and ECN marked (state 1), or not received (state 3)—covering the Acknowledgement Window, which has a default width of 100 sequence numbers back from the Greatest Sequence Number Received (GSR). This granular feedback allows senders to identify loss events accurately, with receivers encouraged to include the full buffer state in each acknowledgment to support precise congestion estimation. DCCP supports both rate-based and window-based congestion control, with senders limiting their transmission rates based on reports from receivers embedded in acknowledgments. In window-based approaches, the sender maintains a congestion window that is adjusted dynamically, similar to TCP's (AIMD) mechanism, halving the window upon detecting loss or ECN marks. Rate-based control, conversely, computes an allowable sending rate directly from estimated loss rates and round-trip times (RTTs), offering smoother adjustments suitable for applications. The choice between these is determined by the Congestion Control ID (CCID) negotiated per half-connection, and sender limits are enforced to prevent bursts, often incorporating an Ack Ratio to control acknowledgment frequency and reduce reverse-path congestion. Half-connection congestion control extends these principles to unconfirmed states, such as during initial handshakes or after partial losses, where one direction of the connection lacks full acknowledgment. Each half-connection operates independently with its own CCID, ensuring that even in states like PARTOPEN, the sender applies congestion limits based on available feedback, including provisional acknowledgments with sequence numbers. This prevents aggressive transmission in asymmetric or recovering flows, maintaining overall network stability. To recover sequence validity without transmitting data, DCCP uses synchronization packets: DCCP-Sync and DCCP-SyncAck. A DCCP-Sync packet, identifiable by its type and 48-bit number, prompts the peer to acknowledge a specific sequence point, while DCCP-SyncAck confirms receipt and resynchronizes the acknowledgment number to match the Sync's sequence. These packets are crucial for clearing loss bursts or reordering without advancing the , allowing quick recovery while adhering to congestion limits. Throughput estimation in DCCP draws from TCP-friendly models to bound sending rates, particularly in rate-based profiles. An approximate for the achievable throughput XX (in bytes per second) under loss is adapted from TCP's steady-state for datagram flows: X≈sRTT2p3X \approx \frac{s}{RTT \sqrt{\frac{2p}{3}}}
Add your contribution
Related Hubs
User Avatar
No comments yet.