Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control
updated by
- rfc-8311 — Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation
Extracted elements (30)
CCID 2 applies congestion control to acknowledgements via the Ack Ratio feature, a mechanism not currently standardized for TCP, to avoid congestion collapse on the reverse path and perform somewhat better than TCP under high reverse-path loss rates.
CCID 2 is recommended over CCID 3 (TFRC) for applications that buffer data before playback (tolerating rate swings) or that want TCP-like, well-understood congestion dynamics rather than the smoother but less-studied TFRC behavior.
CCID 2 parameters (cwnd, ssthresh, pipe) are measured in packets rather than bytes because DCCP is a datagram protocol. This is a deliberate deviation from TCP where these parameters are byte-based.
ECN Nonce is not used for CCID 2 acknowledgements because it would be difficult to protect against concealment of marked ack packets by the sender, and the sender has little motivation to lie about the ack mark rate.
For Ack Ratio calculation, the sender assumes all lost packets were non-data packets because DCCP-Ack packets impose less load on congested links; Appendix B quantifies that even worst-case misclassification reduces the ack rate by only a factor of ~0.62.
CCID 2 implementations should NOT track TCP congestion control evolution directly but wait for explicit CCID 2 updates, since TCP's mechanisms are specified for TCP's retransmission-based reliability model and may not translate directly to DCCP's unreliable datagram context.
An active sender DCCP A MUST occasionally acknowledge its peer DCCP B's acknowledgements so that DCCP B can free up Ack Vector state, and SHOULD do so at least once per congestion window.
CCID 2 implementations SHOULD wait for explicit updates to CCID 2 rather than tracking TCP's congestion control evolution directly.
Each required acknowledgement MUST contain Ack Vector options that declare exactly which packets arrived and whether those packets were ECN-marked. Ack Vector coverage SHOULD generally span the receiver's entire Acknowledgement Window.
The sender MAY send a data packet when pipe < cwnd but MUST NOT send a data packet when pipe >= cwnd. Every data packet sent increases pipe by 1.
The sender MUST exit slow start whenever it receives a relevant Data Dropped or Slow Receiver option.
The sender MUST NOT decrement pipe for non-data packets such as DCCP-Acks, even though the Ack Vector will contain information about them.
The sender MUST NOT decrement pipe more than once per data packet; true duplicate acknowledgements MUST NOT affect pipe, and the sender MUST NOT decrement pipe again upon receiving acknowledgement of a packet previously inferred as lost.
The sender SHOULD check ECN Nonce Echoes returned in Ack Vector options against the expected values, protecting against accidental or malicious concealment of marked packets.
The sender SHOULD NOT attempt to renegotiate the Ack Ratio more than once per round-trip time. It MAY rate-limit Ack Ratio renegotiations to once every four or five RTTs or once every second or two.
The sender SHOULD NOT send data until it has received the corresponding 'Confirm L(Send Ack Vector, 1)' from the receiver, except that it MAY send data on DCCP-Request packets.
Unless the sender has better information (e.g., via NDP Count), it SHOULD assume for Ack Ratio calculation that every lost packet was a non-data packet.
Use of the Ack Vector is MANDATORY on CCID 2 half-connections; the sender MUST send a 'Change R(Send Ack Vector, 1)' option to the receiver as part of connection establishment.
Ack Ratio feature controls the receiver's DCCP-Ack sending rate: when Ack Ratio is R, the receiver sends one DCCP-Ack per R data packets. For each RTT with a DCCP-Ack congestion event, Ack Ratio is doubled; for each cwnd/(R^2 - R) consecutive congestion-free windows, Ack Ratio is decreased by 1.
Ack Ratio must satisfy three constraints: (1) it is an integer; (2) it does not exceed ceil(cwnd/2), except Ack Ratio 2 is always acceptable; (3) it is two or more for a congestion window of four or more packets.
CCID 2 maintains three integer parameters measured in packets: cwnd (maximum data packets allowed in network), ssthresh (slow-start threshold), and pipe (sender's estimate of data packets outstanding in network). These are manipulated per SACK-based TCP behavior but in packet units rather than bytes.
Congestion window increase rules: in slow-start (cwnd < ssthresh), cwnd increases by one packet per two newly acknowledged State-0 packets, up to Ack Ratio/2 per ack; in congestion avoidance (cwnd >= ssthresh), cwnd increases by one packet per window of data acknowledged without loss or marks. cwnd is initialized to at most four packets per RFC 3390.
For the Data Dropped option with Drop Code 2 (receive buffer drop), cwnd is reduced by one for each packet newly acknowledged as Drop Code 2, but is never reduced below one packet.
On a congestion event (lost or ECN-marked packet), cwnd is halved and ssthresh is set to the new cwnd, never reducing cwnd below one packet. After a transmit timeout, ssthresh is set to cwnd/2 and cwnd is reset to one packet; the transmit timeout uses exponential backoff identical to TCP.
Quiescence detection: a CCID 2 receiver infers the sender has gone quiescent when at least T = max(0.2 s, 2 RTTs) have passed without receiving data and the sender has acknowledged Ack Vectors covering all received data packets.
The NUMDUPACK parameter is set to three (matching TCP): a data packet P is inferred lost rather than delayed when at least NUMDUPACK packets transmitted after P have been acknowledged as received (Ack Vector State 0 or 1) by the receiver.
IANA manages the DCCP CCID 2 Feature Number registry; values are numbers 128-255, with 184-190 and 248-254 reserved for experimental/testing use and the remainder allocated via Standards Action policy. This document also defines value 2 in the DCCP CCID namespace.
IANA manages the DCCP CCID 2 Option Type registry; values are numbers 128-255, with 184-190 and 248-254 reserved for experimental/testing use and the remainder allocated via Standards Action policy.
IANA manages the DCCP CCID 2 Reset Code registry; values are numbers 128-255, with 184-190 and 248-254 reserved for experimental/testing use and the remainder allocated via Standards Action policy.
An attacker could impair CCID 2 connection performance by dropping packets or forging duplicate acknowledgements or acknowledgements for new data, as in TCP. The document states no new security considerations are introduced beyond those already discussed for TCP (RFC 2581) and DCCP (RFC 4340).