RTP Control Protocol (RTCP) Feedback for Congestion Control
Extracted elements (29)
Stacking multiple RTCP XR blocks to convey per-packet loss, timing, and ECN data was rejected due to high bandwidth and complexity overhead. A single dedicated feedback format is more efficient.
Standard RTCP SR/RR packets were intended to support congestion control but in practice provide insufficient granularity—only aggregated jitter, fractional loss, and cumulative loss—whereas effective algorithms require per-packet reception timing, loss, and ECN marks.
The ATO field uses units of 1/1024 seconds (not milliseconds or microseconds) so that offset values from the Report Timestamp can be computed exactly without rounding, since the RTS field itself uses the same NTP-derived clock base.
TMMBR (Temporary Maximum Media Stream Bit Rate Request) was rejected as a congestion control mechanism because it requires the receiver to determine congestion level and recommend a bitrate—a receiver-based approach—whereas the design goal is sender-based congestion control where the sender interprets raw reception metrics.
Transport-wide congestion control (a single transport-wide sequence number per RTP packet) was considered but rejected as the primary design because it increases each RTP packet by 8 octets, makes per-SSRC rate adaptation and repair more difficult, and is a less natural fit with the per-SSRC RTP framework.
The RTCP ECN Feedback Packet defined in RFC 6679 is redundant when the RTP Congestion Control Feedback Packet (this memo) is used, since ECN marks are already carried in the ATO metric blocks. To avoid duplicate feedback, an answering party SHOULD NOT signal both "ack ccfb" and "nack ecn" in its SDP answer.
All RTP congestion control algorithms MUST specify how they respond to loss of feedback packets, since RTCP packets carry no sequence number and loss must be inferred from elapsed time since the last feedback packet.
Each report block MUST NOT include more than 16384 packet metric blocks, i.e., it MUST NOT report on more than one quarter of the RTP sequence number space in a single report.
If a Congestion Control Feedback Packet is too large to fit within the path MTU, its sender SHOULD split it into multiple feedback packets. The RTCP reporting interval SHOULD be chosen so that feedback packets fit within the path MTU.
If duplicate copies of an RTP packet are received, the arrival time of the first copy MUST be reported. If any duplicate is ECN-CE marked, an ECN-CE mark MUST be reported for that packet; otherwise, the ECN mark of the first copy is reported.
If multiple consecutive congestion control feedback packets are lost, the media sender SHOULD rapidly reduce its sending rate, as this likely indicates a path failure. The RTP circuit breaker specification (RFC 8083) provides further guidance.
If the number of 16-bit packet metric blocks in a report block is not a multiple of two, 16 bits of zero padding MUST be added after the last block to align to a 32-bit boundary.
RTCP Congestion Control Feedback Packets SHOULD include a report block for every active SSRC. If a packet was reported as received in one report, it MUST also be reported as received in any overlapping reports that cover its sequence number range.
The payload type used with "ccfb" feedback MUST be the wildcard type ("*"), implying that congestion control feedback is sent for all payload types in use in the session, including FEC and retransmission payload types.
When an SDP offer indicates support for multiple congestion control feedback mechanisms with substantially the same semantics, the answering party SHOULD include only one in its answer, and SHOULD choose the same mechanism in subsequent answers where possible.
When congestion control feedback is used with ECN, the SDP offer MUST include an "a=ecn-capable-rtp:" attribute and an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb". The answering party SHOULD signal support for only one ECN feedback format to avoid duplicate feedback.
When the R bit is 0 (packet not received), the subsequent 15 bits (ECN and ATO) MUST be ignored. When ATO is over-range (> 8189/1024 s), the value 0x1FFE MUST be reported; when unavailable or arrival is after RTS, 0x1FFF MUST be reported.
When using ECN with RTP, the guidelines in RFC 6679 Sections 7.2, 7.3, and 7.4 MUST be followed, except that feedback is carried in RTCP Congestion Control Feedback Packets rather than RTCP ECN Feedback Packets.
SDP signaling for the congestion control feedback mechanism uses a new "ack" parameter "ccfb" for the "a=rtcp-fb:" attribute. The canonical SDP attribute is "a=rtcp-fb:* ack ccfb". When used with SDP BUNDLE, the attribute has multiplexing category IDENTICAL-PER-PT.
The RTCP Congestion Control Feedback Packet is a Transport-Layer Feedback Message using RTCP packet type 205 (PT=205) and FMT=11. It carries per-packet reception quality information grouped by SSRC, enabling sender-based congestion control for RTP flows.
IANA registered "ccfb" as a new SDP "rtcp-fb" attribute "ack" parameter in the SDP '"ack" and "nack" Attribute Values' registry, usable with "ack" and with BUNDLE mux category IDENTICAL-PER-PT.
IANA registered CCFB (RTP Congestion Control Feedback) with FMT value 11 in the "FMT Values for RTPFB Payload Types" table under RFC 4585.
A receiver that intentionally generates inaccurate RTCP congestion control feedback can trick the sender into transmitting at a rate exceeding path capacity, causing congestion, denial of service to other flows, and excessive resource use at the sender. A sender may intentionally drop packets to verify that losses are correctly reported.
An off-path attacker that can spoof RTCP Congestion Control Feedback Packets can similarly force incorrect sending rates. The attack is difficult because the attacker must guess the SSRC, sequence number, and destination transport address; SRTP authentication (RFC 3711) mitigates this.
An on-path attacker that can modify RTCP Congestion Control Feedback Packets can manipulate reports to drive the sender to an excessively high or low rate, causing denial of service. SRTP (RFC 3711) SHOULD be used to authenticate RTCP packets and mitigate this attack.
Each per-SSRC report block contains a 32-bit SSRC field, a 16-bit begin_seq, a 16-bit num_reports, and one 16-bit packet metric block per reported RTP packet. The packet metric block encodes: R (1 bit received flag), ECN (2 bits echoed ECN mark), and ATO (13 bits arrival time offset).
The Arrival Time Offset (ATO) field is 13 bits wide and expressed in units of 1/1024 seconds, representing how far before the Report Timestamp the corresponding RTP packet arrived. The value 0x1FFE signals over-range (> 8189/1024 seconds); 0x1FFF signals unavailable or arrival after the RTS.
The feedback packet begins with a standard 8-octet RTCP header (V=2, P, FMT=11, PT=205, length, SSRC of sender), followed by one or more per-SSRC report blocks, and concludes with a 32-bit Report Timestamp field.
The Report Timestamp (RTS) field is 32 bits wide, derived from the same clock used for RTCP Sender Report NTP timestamps, and formatted as the middle 32 bits of an NTP format timestamp as described in RFC 3550 Section 4.