Datagram Congestion Control Protocol (DCCP)
updated by
- rfc-5595 — The Datagram Congestion Control Protocol (DCCP) Service Codes
- rfc-5596 — Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
- rfc-6335 — Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
- rfc-6773 — DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal
Extracted elements (28)
DCCP chose not to mandate the Congestion Manager (RFC 3124) because it requires applications to have their own end-to-end loss feedback, does not easily support multiple congestion control mechanisms, and would make DCCP deployment contingent on CM deployment.
DCCP's Acknowledgement Number equals GSR (greatest sequence number received) rather than TCP's smallest-not-yet-received cumulative ACK, because DCCP is unreliable and separate options such as Ack Vector provide precise loss information.
DCCP supports pluggable congestion control via one-byte CCIDs because different applications have different needs: online games may want quick bandwidth use while streaming media prefers steady, less bursty rates. CCIDs 2 (TCP-like) and 3 (TFRC) are initially standardized.
DCCP was designed to give streaming UDP applications little reason not to switch by minimizing header and state overhead. Only minimal functionality is included in the protocol; features like FEC, semi-reliability, and multiple streams are left to layers above DCCP.
RTP applications may run over DCCP to gain built-in congestion control. The selected DCCP CCID should be consistent with the media codec's rate-adaptation properties; TFRC (CCID 3) is generally appropriate for streaming media due to its smoother rate behavior.
After connection teardown, one endpoint holds TIMEWAIT state for 2MSL (4 minutes) to prevent mistakes from late-arriving old packets. The server may use DCCP-CloseReq to pass TIMEWAIT responsibility to the client.
All DCCP sequence number operations use circular arithmetic modulo 2^48. Sequence numbers increment by one per packet including pure acknowledgements (DCCP-Ack), enabling detection of all packet loss including acknowledgement loss.
DCCP-Request, DCCP-Response, DCCP-CloseReq, DCCP-Close, DCCP-Reset, DCCP-Sync, and DCCP-SyncAck packets MUST set X to one (48-bit sequence numbers); endpoints MUST ignore any such packets received with X set to zero.
DCCP-Sync and DCCP-SyncAck packets MUST use 48-bit sequence numbers (X=1) and are used to resynchronize endpoints after large bursts of packet loss and to recover from half-open connections. Each valid DCCP-Sync immediately elicits a DCCP-SyncAck.
Feature negotiation options (Change L/R, Confirm L/R) MUST NOT be sent on DCCP-Data packets, and any feature negotiation options received on DCCP-Data packets MUST be ignored.
Options MUST be processed sequentially from the first option in the header. Options with unknown types MUST be ignored. Options with nonsensical lengths (less than 2 or beyond the options area) MUST be ignored, and any option space following them MUST likewise be ignored.
Reserved bitfields in DCCP packet headers MUST be set to zero by senders and MUST be ignored by receivers. DCCP processors MUST NOT reset a connection simply because a Reserved field has a non-zero value, per RFC 3360.
The Mandatory option marks the immediately following option O as mandatory: if the receiver does not understand or process O, it MUST reset the connection with Reset Code 6, 'Mandatory Failure'. Mandatory MUST NOT be sent on DCCP-Data packets and any received there MUST be ignored.
The receiver MUST ignore packets whose Data Offset is smaller than the minimum-sized header for the given packet Type or larger than the DCCP packet itself.
DCCP defines 10 packet types (0–9): Request, Response, Data, Ack, DataAck, CloseReq, Close, Reset, Sync, SyncAck. Types 10–15 are reserved; receivers MUST ignore packets with reserved type and MUST NOT acknowledge them.
Feature negotiation uses four options: Change L and Change R initiate negotiation; Confirm L and Confirm R complete it. 'L' options are sent by the feature location; 'R' options by the feature remote. Change options are retransmitted until a response is received; Confirm options need not be retransmitted.
Partial checksum coverage is controlled by CsCov: CsCov=0 means the full packet is covered; CsCov=1–15 means the header plus the first (CsCov−1)×4 bytes of application data are covered. This can improve performance on noisy links for applications that tolerate data corruption.
This document creates the DCCP Congestion Control Identifiers (CCIDs) registry; CCIDs 2 and 3 are defined, 0–1 and 4–255 are reserved. New CCIDs require an approved CCID Profile document. It also creates the Service Codes registry with First Come First Served assignment policy.
This document creates the DCCP Option Types registry (types 0–44 defined, 45–127 reserved, 128–255 CCID-specific) and the DCCP Feature Numbers registry (numbers 0–9 defined, 10–127 reserved, 128–255 CCID-specific), requiring IETF Consensus.
This document creates the DCCP Packet Types registry (types 0–9 defined, 10–15 reserved) and the DCCP Reset Codes registry (codes 0–11 defined, 12–127 reserved, 128–255 CCID-specific), both requiring IETF Consensus for new assignments.
An endpoint detecting congestion-control misbehavior (e.g., receiving ECN Nonce Echoes inconsistent with reported losses) sends DCCP-Reset with Reset Code 11, 'Aggression Penalty', to penalize peers attempting to exploit congestion control.
DCCP provides no protection against attackers who can snoop on a connection in progress or guess valid sequence numbers. Applications requiring stronger security should use IPsec; application-level cryptography may also suffice.
Partial checksums (CsCov less than full coverage) allow corrupted application data to reach applications undetected. Implementations honoring partial checksums MUST allow applications to detect corruption; the header itself is always fully checksummed.
DCCP has 9 ordered connection states: CLOSED, LISTEN, REQUEST, RESPOND, PARTOPEN, OPEN, CLOSEREQ, CLOSING, TIMEWAIT. Client progresses CLOSED→REQUEST→PARTOPEN→OPEN→CLOSING→TIMEWAIT; server progresses LISTEN→RESPOND→OPEN→CLOSEREQ→CLOSED. States are listed in increasing order so that 'state >= CLOSEREQ' comparisons are valid.
DCCP-Request packets carry a 32-bit Service Code field after the generic header, identifying the application-level service. DCCP-Response packets MUST echo the same Service Code. Service Codes aid middleboxes and reduce reliance on globally well-known port numbers.
DCCP-Reset packets carry an 8-bit Reset Code, three 8-bit Data fields (Data 1–3 whose meaning depends on the code), and an optional UTF-8 Error Text in the application data area. Reset Code 1 = Closed (normal); codes 12–127 are reserved; codes 128–255 are CCID-specific.
The Acknowledgement Number Subheader follows the generic header on all packet types except DCCP-Request and DCCP-Data. When X=1 it is 8 bytes (16-bit Reserved + 48-bit Ack Number); when X=0 it is 4 bytes (8-bit Reserved + 24-bit Ack Number).
The DCCP generic header is 16 bytes when X=1 (48-bit Sequence Number) and 12 bytes when X=0 (24-bit Sequence Number). Fields: Source Port (16 bits), Dest Port (16 bits), Data Offset (8 bits), CCVal (4 bits), CsCov (4 bits), Checksum (16 bits), Res (3 bits), Type (4 bits), X (1 bit), Sequence Number (48 or 24 bits).