Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
updates
- rfc-3550 — RTP: A Transport Protocol for Real-Time Applications
Extracted elements (31)
RTT estimates and jitter from RTCP RR packets were explicitly rejected as standalone circuit breaker signals because RTCP under RTP/AVP timing is too infrequent and cannot distinguish routing-change delay from congestion queuing delay; only sustained packet loss provides a sufficiently strong signal.
The congestion circuit breaker threshold of 10 * X (ten times estimated TCP throughput) rather than 1 * X reflects the RTP/AVP profile's 'order of magnitude' fairness requirement; this accounts for the imprecision of using loss fraction as a proxy for loss event rate and the coarse RTCP reporting interval.
The minimum sending rate threshold (at least one RTP packet every max(Tdr, Tr) seconds) before the congestion circuit breaker applies is included to avoid spurious triggers when few packets are sent per RTCP interval and loss fraction samples suffer measurement artifacts.
The simplified TCP throughput equation is recommended over the full Padhye equation because measurement data shows the accuracy reduction is small and it is much simpler to calculate; the full equation MAY be used where its extra sensitivity to loss is desired (e.g., LTE networks).
At the time of writing there is no consensus on how ECN feedback impacts the congestion circuit breaker (Section 4.3); ECN does not affect the RTCP timeout or media timeout circuit breakers since these are simple connectivity checks.
Implementations that sometimes need to interwork with endpoints that do not support RTCP need to disable the RTP circuit breakers if they don't receive signaling confirmation that the remote endpoint implements RTCP (e.g., an SDP 'a=rtcp:' attribute in an answer).
RTP media streams with different DSCP values SHOULD NOT be considered as a group when evaluating RTP circuit breaker conditions, since congestion may be experienced differently depending on DSCP marking.
An RTP sender participating in several RTP sessions MUST treat each RTP session independently with regard to the RTP circuit breaker.
An RTP sender that has not received any RTCP SR or RTCP RR packets reporting on the SSRC it is using for a time period of at least three times its deterministic RTCP reporting interval Td SHOULD cease transmission.
If the RTP/AVPF or RTP/SAVPF profile is used and T_rr_interval reduces regular RTCP report frequency, the value of Tdr in the CB_INTERVAL expression MUST be replaced by max(T_rr_interval, Tdr).
Implementations SHOULD NOT configure the RTCP bandwidth such that Td is larger than 5 seconds, and SHOULD NOT configure T_rr_interval to values larger than 4 seconds when using RTP/AVPF or RTP/SAVPF.
Implementations that cannot determine whether a flow restart was user-initiated or automatic MUST rate limit attempts to restart a flow on the same 5-tuple as used by a flow that triggered the circuit breaker, such that the reaction lasts for at least the triggering interval.
Implementations without RTCP that claim to support RTP SHOULD NOT be used on networks that might be subject to congestion unless equivalent non-RTCP feedback mechanisms for congestion reporting and circuit breaker conditions are defined.
Reduced-size RTCP reports sent under RTP/AVPF early feedback rules that do not contain an RTCP SR or RR packet MUST be ignored by the congestion circuit breaker but MUST be counted as received packets for the RTCP timeout circuit breaker.
RTP flows halted by the circuit breaker SHOULD NOT be restarted automatically unless the sender has received information that congestion has dissipated or can reasonably be expected to have dissipated.
RTP senders SHOULD monitor reported packet loss and delay to estimate whether media is usable; if unusable for a significant time, the application SHOULD cease transmission. Receivers SHOULD similarly monitor quality and SHOULD terminate the session if unusable.
When a sender receives an RTCP packet indicating that its media was not received, it MUST calculate a new value for MEDIA_TIMEOUT; if the new value is larger than the previous it replaces the old value, otherwise it keeps the original.
When a sender transmitting at least one RTP packet every max(Tdr, Tr) seconds receives an RTCP SR or RR packet with a report block, it MUST record the fraction lost and time since the last report; if more than CB_INTERVAL reports have been received it MUST calculate average fraction lost and estimate TCP throughput X, triggering the congestion circuit breaker if the actual sending rate exceeds 10 * X.
When generating round-robin RTCP reports (when sources exceed MTU), priority SHOULD be given to reports on sources with high packet loss rates to ensure senders are aware of congestion they are causing; this updates RFC 3550.
When stopping sending an RTP stream, a sender MUST cancel the corresponding media timeout circuit breaker.
When the congestion circuit breaker triggers, the sender SHOULD cease transmission; however the sender MAY first reduce its sending rate by a factor of approximately ten, but if the circuit breaker triggers again after the next CB_INTERVAL the sender MUST cease transmission.
CB_INTERVAL = ceil(3*min(max(10*G*Tf, 10*Tr, 3*Tdr), max(15, 3*Td))/(3*Tdr)) is the number of RTCP reporting intervals over which average fraction lost is calculated for the congestion circuit breaker; it ensures at least three RTCP reports, ten RTTs, and ten frame groups for congestion control to react.
t_RTO, the TCP retransmission timeout used in the full TCP throughput equation, MUST be approximated as t_RTO = 4 * Tr when used in the RTP congestion circuit breaker.
The Congestion circuit breaker (#3) compares the actual RTP sending rate against 10 * X, where X is an estimated TCP throughput using loss fraction p and RTT Tr; it triggers when the sending rate exceeds this threshold over CB_INTERVAL RTCP reporting intervals.
The Media Timeout circuit breaker (#2) triggers when MEDIA_TIMEOUT = ceil(k * max(Tf, Tr, Tdr) / Tdr) consecutive RTCP packets indicate non-increasing extended highest sequence number received; the recommended value of k is 5 reports.
The Media Usability circuit breaker (#4) triggers when packet loss and/or latency renders media unusable for a significant application-defined time period; both sender and receiver may independently trigger this breaker.
The RTCP Timeout circuit breaker (#1) triggers when no RTCP SR or RR packets are received for a period of at least 3 * Td, where Td is the deterministic RTCP reporting interval calculated without randomization and using Tmin=5 seconds.
The simplified TCP throughput equation X = s / (Tr * sqrt(2*b*p/3)) is recommended for the congestion circuit breaker, where s is average RTP packet size, Tr is RTT, b=1, and p is approximated by the average loss fraction. The full Padhye equation MAY be used for extra sensitivity.
If non-authenticated RTCP reports are used, an on-path attacker can trivially generate fake RTCP packets indicating high packet loss rates and cause the circuit breaker to trigger, disrupting an RTP session. This attack is harder for off-path attackers who must guess the RTP SSRC and sequence number. Authentication per RFC 7201 prevents this attack.
Timely circuit breaker operation depends on the RTCP reporting interval; a receiver configured with an overly long reporting interval (e.g., many minutes) can effectively disable the circuit breaker. Implementations MUST impose an upper limit on the RTCP reporting interval they are willing to negotiate.
The circuit breaker state transitions are: (1) Sending — normal operation; (2) Circuit Breaker Triggered — sender SHOULD cease transmission on triggering conditions (RTCP timeout, media timeout, congestion, or media unusability); (3) Restarted — flow may resume only after congestion is confirmed dissipated, with rate limiting on restart attempts.