diff options
Diffstat (limited to 'doc/rfc/rfc8083.txt')
| -rw-r--r-- | doc/rfc/rfc8083.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc8083.txt b/doc/rfc/rfc8083.txt new file mode 100644 index 0000000..2a97f16 --- /dev/null +++ b/doc/rfc/rfc8083.txt @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Perkins +Request for Comments: 8083 University of Glasgow +Updates: 3550 V. Singh +Category: Standards Track callstats.io +ISSN: 2070-1721 March 2017 + + +Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions + +Abstract + + The Real-time Transport Protocol (RTP) is widely used in telephony, + video conferencing, and telepresence applications. Such applications + are often run on best-effort UDP/IP networks. If congestion control + is not implemented in these applications, then network congestion can + lead to uncontrolled packet loss and a resulting deterioration of the + user's multimedia experience. The congestion control algorithm acts + as a safety measure by stopping RTP flows from using excessive + resources and protecting the network from overload. At the time of + this writing, however, while there are several proprietary solutions, + there is no standard algorithm for congestion control of interactive + RTP flows. + + This document does not propose a congestion control algorithm. It + instead defines a minimal set of RTP circuit breakers: conditions + under which an RTP sender needs to stop transmitting media data to + protect the network from excessive congestion. It is expected that, + in the absence of long-lived excessive congestion, RTP applications + running on best-effort IP networks will be able to operate without + triggering these circuit breakers. To avoid triggering the RTP + circuit breaker, any Standards Track congestion control algorithms + defined for RTP will need to operate within the envelope set by these + RTP circuit breaker algorithms. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8083. + + + + +Perkins & Singh Standards Track [Page 1] + +RFC 8083 RTP Circuit Breakers March 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . 8 + 4.1. RTP/AVP Circuit Breaker #1: RTCP Timeout . . . . . . . . 10 + 4.2. RTP/AVP Circuit Breaker #2: Media Timeout . . . . . . . . 11 + 4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 12 + 4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 16 + 4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 17 + 5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 18 + 6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 19 + 7. Impact of Explicit Congestion Notification (ECN) . . . . . . 19 + 8. Impact of Bundled Media and Layered Coding . . . . . . . . . 20 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 10.2. Informative References . . . . . . . . . . . . . . . . . 22 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + + + + + + + + + + + + + + + +Perkins & Singh Standards Track [Page 2] + +RFC 8083 RTP Circuit Breakers March 2017 + + +1. Introduction + + The Real-time Transport Protocol (RTP) [RFC3550] is widely used in + voice-over-IP, video teleconferencing, and telepresence systems. + Many of these systems run over best-effort UDP/IP networks and can + suffer from packet loss and increased latency if network congestion + occurs. Designing effective RTP congestion control algorithms to + adapt the transmission of RTP-based media to match the available + network capacity while also maintaining the user experience is a + difficult but important problem. Many such congestion control and + media adaptation algorithms have been proposed, but to date there is + no consensus on the correct approach or even that a single standard + algorithm is desirable. + + This memo does not attempt to propose a new RTP congestion control + algorithm. Instead, we propose a small set of RTP circuit breakers: + mechanisms that terminate RTP flows in conditions under which there + is general agreement that serious network congestion is occurring. + The RTP circuit breakers proposed in this memo are a specific + instance of the general class of network transport circuit breakers + [RFC8084] designed to act as a protection mechanism of last resort to + avoid persistent excessive congestion. To avoid triggering the RTP + circuit breaker, any Standards Track congestion control algorithms + defined for RTP will need to operate within the envelope set by the + RTP circuit breaker algorithms defined by this memo. + +2. Background + + We consider congestion control for unicast RTP traffic flows. This + is the problem of adapting the transmission of an audio/visual data + flow, encapsulated within an RTP transport session, from one sender + to one receiver so that it does not use more capacity than is + available along the network path. Such adaptation needs to be done + in a way that limits the disruption to the user experience caused by + both packet loss and excessive rate changes. Congestion control for + multicast flows is outside the scope of this memo. Multicast traffic + needs different solutions since the available capacity estimator for + a group of receivers will differ from that for a single receiver, and + because multicast congestion control has to consider issues of + fairness across groups of receivers that do not apply to unicast + flows. + + Congestion control for unicast RTP traffic can be implemented in one + of two places in the protocol stack. One approach is to run the RTP + traffic over a congestion-controlled transport protocol (for example, + over TCP), and to adapt the media encoding to match the dictates of + the transport-layer congestion control algorithm. This is safe for + the network but can be suboptimal for the media quality unless the + + + +Perkins & Singh Standards Track [Page 3] + +RFC 8083 RTP Circuit Breakers March 2017 + + + transport protocol is designed to support real-time media flows. We + do not consider this class of applications further in this memo, as + their network safety is guaranteed by the underlying transport. + + Alternatively, RTP flows can be run over a non-congestion-controlled + transport protocol (for example, UDP) performing rate adaptation at + the application layer based on RTP Control Protocol (RTCP) feedback. + With a well-designed, network-aware application, this allows highly + effective media quality adaptation, but there is potential to cause + persistent congestion in the network if the application does not + adapt its sending rate in a timely and effective manner. We consider + this class of applications in this memo. + + Congestion control relies on monitoring the delivery of a media flow + and responding to adapt the transmission of that flow when there are + signs that the network path is congested. Network congestion can be + detected in one of three ways: + + 1) a receiver can infer the onset of congestion by observing an + increase in one-way delay caused by queue build-up within the + network; + + 2) if Explicit Congestion Notification (ECN) [RFC3168] is supported, + the network can signal the presence of congestion by marking + packets using ECN Congestion Experienced (CE) marks (this could + potentially be augmented by mechanisms such as Congestion + Exposure (ConEx) [RFC7713] or other future protocol extensions + for network signaling of congestion); or + + 3) in the extreme case, congestion will cause packet loss that can + be detected by observing a gap in the received RTP sequence + numbers. + + Once the onset of congestion is observed, the receiver has to send + feedback to the sender to indicate that the transmission rate needs + to be reduced. How the sender reduces the transmission rate is + highly dependent on the media codec being used and is outside the + scope of this memo. + + There are several ways in which a receiver can send feedback to a + media sender within the RTP framework: + + o The base RTP specification [RFC3550] defines RTCP Receiver Report + (RR) packets to convey reception quality feedback information and + Sender Report (SR) packets to convey information about the media + transmission. RTCP SR packets contain data that can be used to + reconstruct media timing at a receiver along with a count of the + total number of octets and packets sent. RTCP RR packets report + + + +Perkins & Singh Standards Track [Page 4] + +RFC 8083 RTP Circuit Breakers March 2017 + + + on the fraction of packets lost in the last reporting interval, + the cumulative number of packets lost, the highest sequence number + received, and the inter-arrival jitter. The RTCP RR packets also + contain timing information that allows the sender to estimate the + network Round-Trip Time (RTT) to the receivers. RTCP reports are + sent periodically, with the reporting interval being determined by + the number of Synchronization Sources (SSRCs) used in the session + and a configured session bandwidth estimate (the number of SSRCs) + used is usually two in a unicast session, one for each + participant, but can be greater if the participants send multiple + media streams). The interval between reports sent from each + receiver is on the order of a few seconds on average; although it + varies with the session bandwidth, it is randomized to avoid + synchronization of reports from multiple receivers. The interval + can be less than a second in a high-bandwidth session. RTCP RR + packets allow a receiver to report ongoing network congestion to + the sender. However, if a receiver detects the onset of + congestion part way through a reporting interval, the base RTP + specification contains no provision for sending the RTCP RR packet + early, and the receiver has to wait until the next scheduled + reporting interval. + + o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more + complex and sophisticated reception quality metrics but do not + change the RTCP timing rules. RTCP extended reports of potential + interest for congestion control purposes are the extended packet + loss, discard, and burst metrics [RFC3611] [RFC7002] [RFC7097] + [RFC7003] [RFC6958] as well as the extended delay metrics + [RFC6843] [RFC6798]. Other RTCP Extended Reports that could be + helpful for congestion control purposes might be developed in + future. + + o Rapid feedback about the occurrence of congestion events can be + achieved using the Extended RTP Profile for RTCP-Based Feedback + (RTP/AVPF) [RFC4585] (or its secure variant, RTP/SAVPF [RFC5124]) + in place of the RTP/AVP profile [RFC3551]. This modifies the RTCP + timing rules to allow RTCP reports to be sent early, in some cases + immediately, provided the RTCP transmission rate keeps within its + bandwidth allocation. It also defines transport-layer feedback + messages, including Negative Acknowledgements (NACKs), that can be + used to report on specific congestion events. RTP Codec Control + Messages [RFC5104] extend the RTP/AVPF profile with additional + feedback messages that can be used to influence the way in which + rate adaptation occurs but do not further change the dynamics of + how rapidly feedback can be sent. Use of the RTP/AVPF profile is + dependent on signaling. + + + + + +Perkins & Singh Standards Track [Page 5] + +RFC 8083 RTP Circuit Breakers March 2017 + + + o Finally, ECN for RTP over UDP [RFC6679] can be used to provide + feedback on the number of packets that received an ECN-CE mark. + This RTCP extension builds on the RTP/AVPF profile to allow rapid + congestion feedback when ECN is supported. + + In addition to these mechanisms for providing feedback, the sender + can include an RTP header extension in each packet to record packet + transmission times [RFC5450]. Accurate transmission timestamps can + be helpful for estimating queuing delays to get an early indication + of the onset of congestion. + + Taken together, these various mechanisms allow receivers to provide + feedback on the senders when congestion events occur, with varying + degrees of timeliness and accuracy. The key distinction is between + systems that use only the basic RTCP mechanisms, without RTP/AVPF + rapid feedback, and those that use the RTP/AVPF extensions to respond + to congestion more rapidly. + +3. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + This interpretation of these key words applies only when written in + ALL CAPS. Mixed- or lower-case uses of these key words are not to be + interpreted as carrying special significance in this memo. + + The definition of the RTP circuit breaker is specified in terms of + the following variables: + + o Td is the deterministic RTCP reporting interval, as defined in + Section 6.3.1 of [RFC3550]. + + o Tdr is the sender's estimate of the deterministic RTCP reporting + interval, Td, calculated by a receiver of the data it is sending. + Tdr is not known at the sender but can be estimated by executing + the algorithm in Section 6.2 of [RFC3550] using the average RTCP + packet size seen at the sender, the number of members reported in + the receiver's SR/RR report blocks, and whether the receiver is + sending SR or RR packets. Tdr is recalculated when each new RTCP + SR/RR report is received, but the media timeout circuit breaker + (see Section 4.2) is only reconsidered when Tdr increases. + + + + + + + + + +Perkins & Singh Standards Track [Page 6] + +RFC 8083 RTP Circuit Breakers March 2017 + + + o Tr is the network round-trip time, which is calculated by the + sender using the algorithm in Section 6.4.1 of [RFC3550] and is + smoothed using an exponentially weighted moving average as + Tr = (0.8 * Tr) + (0.2 * Tr_new) where Tr_new is the latest RTT + estimate obtained from an RTCP report. The weight is chosen so + old estimates decay over k intervals. + + o k is the non-reporting threshold (see Section 4.2). + + o Tf is the media framing interval at the sender. For applications + sending at a constant frame rate, Tf is the inter-frame interval. + For applications that switch between a small set of possible frame + rates (for example, when sending speech with comfort noise, such + that comfort noise frames are sent less often than speech frames), + Tf is set to the longest of the inter-frame intervals of the + different frame rates. For applications that send periodic frames + but dynamically vary their frame rate, Tf is set to the largest + inter-frame interval used in the last 10 seconds. For + applications that send less than one frame every 10 seconds, or + that have no concept of periodic frames (e.g., text conversation + [RFC4103], or pointer events [RFC2862]), when each frame is sent, + Tf is set to the time interval since the previous frame. + + o G is the frame group size. That is, the number of frames that are + coded together based on a particular sending rate setting. If the + codec used by the sender can change its rate on each frame, then G + = 1; otherwise, G is set to the number of frames before the codec + can adjust to the new rate. For codecs that have the concept of a + Group of Pictures (GOP), G is likely the GOP length. + + o T_rr_interval is the minimal interval between RTCP reports, as + defined in Section 3.4 of [RFC4585]; it is only meaningful for + implementations of RTP/AVPF profile [RFC4585] or the RTP/SAVPF + profile [RFC5124]. + + o X is the estimated throughput a TCP connection would achieve over + a path, in bytes per second. + + o s is the size of RTP packets being sent, in bytes. If the RTP + packets being sent vary in size, then the average size over the + packet comprising the last 4 * G frames MUST be used (this is + intended to be comparable to the four loss intervals used in + [RFC5348]). + + o p is the loss event rate, between 0.0 and 1.0, that would be seen + by a TCP connection over a particular path. When used in the RTP + congestion circuit breaker, this is approximated as described in + Section 4.3. + + + +Perkins & Singh Standards Track [Page 7] + +RFC 8083 RTP Circuit Breakers March 2017 + + + o t_RTO is the retransmission timeout value that would be used by a + TCP connection over a particular path, in seconds. This MUST be + approximated using t_RTO = 4 * Tr when used as part of the RTP + congestion circuit breaker. + + o b is the number of packets that are acknowledged by a single TCP + acknowledgement. Following [RFC5348], it is RECOMMENDED that the + value b = 1 is used as part of the RTP congestion circuit breaker. + +4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile + + The feedback mechanisms defined in [RFC3550] and available under the + RTP/AVP profile [RFC3551] are the minimum that can be assumed for a + baseline circuit breaker mechanism that is suitable for all unicast + applications of RTP. Accordingly, for an RTP circuit breaker to be + useful, it needs to be able to detect that an RTP flow is causing + excessive congestion using only basic RTCP features without needing + RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports. + + RTCP is a fundamental part of the RTP protocol, and the mechanisms + described here rely on the implementation of RTCP. Implementations + that claim to support RTP, but that do not implement RTCP, will be + unable to use the circuit breaker mechanisms described in this memo. + Such implementations SHOULD NOT be used on networks that might be + subject to congestion unless equivalent mechanisms are defined using + some non-RTCP feedback channel to report congestion and signal + circuit breaker conditions. + + The RTCP timeout circuit breaker (Section 4.1) will trigger if an + implementation of this memo attempts to interwork with an endpoint + that does not support RTCP. 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 some confirmation via + signaling that the remote endpoint implements RTCP (the presence of a + Session Description Protocol (SDP) "a=rtcp:" attribute in an answer + might be such an indication). The RTP circuit breaker SHOULD NOT be + disabled on networks that might be subject to congestion unless + equivalent mechanisms are defined using some non-RTCP feedback + channel to report congestion and signal circuit breaker conditions + [RFC8084]. + + Three potential congestion signals are available from the basic RTCP + SR/RR packets and are reported for each SSRC in the RTP session: + + 1. The sender can estimate the network round-trip time once per RTCP + reporting interval based on the contents and timing of RTCP SR + and RR packets. + + + + +Perkins & Singh Standards Track [Page 8] + +RFC 8083 RTP Circuit Breakers March 2017 + + + 2. Receivers report a jitter estimate (the statistical variance of + the RTP data packet inter-arrival time) calculated over the RTCP + reporting interval. Due to the nature of the jitter calculation + (Section 6.4.4. of [RFC3550]), the jitter is only meaningful for + RTP flows that send a single data packet for each RTP timestamp + value (i.e., audio flows, or video flows where each packet + comprises one video frame). + + 3. Receivers report the fraction of RTP data packets lost during the + RTCP reporting interval and the cumulative number of RTP packets + lost over the entire RTP session. + + These congestion signals limit the possible circuit breakers since + they give only limited visibility into the behavior of the network. + + RTT estimates are widely used in congestion control algorithms as a + proxy for queuing delay measures in delay-based congestion control or + to determine connection timeouts. RTT estimates derived from RTCP SR + and RR packets sent according to the RTP/AVP timing rules are too + infrequent to be useful for congestion control and don't give enough + information to distinguish a delay change due to routing updates from + queuing delay caused by congestion. Accordingly, we cannot use the + RTT estimate alone as an RTP circuit breaker. + + Increased jitter can be a signal of transient network congestion, but + in the highly aggregated form reported in RTCP RR packets, it offers + insufficient information to estimate the extent or persistence of + congestion. Jitter reports are a useful early warning of potential + network congestion but provide an insufficiently strong signal to be + used as a circuit breaker. + + The remaining congestion signals are the packet loss fraction and the + cumulative number of packets lost. If considered carefully, and over + an appropriate time frame to distinguish transient problems from long + term issues [RFC8084], these can be effective indicators that + persistent excessive congestion is occurring in networks where packet + loss is primarily due to queue overflows, although loss caused by + non-congestive packet corruption can distort the result in some + networks. TCP congestion control [RFC5681] intentionally tries to + fill the router queues and uses the resulting packet loss as + congestion feedback. An RTP flow competing with TCP traffic will + therefore expect to see a non-zero packet loss fraction, and some + variation in queuing latency, in normal operation when sharing a path + with other flows, which needs to be accounted for when determining + the circuit breaker threshold [RFC8084]. This behavior of TCP is + reflected in the congestion circuit breaker below and will affect the + design of any RTP congestion control protocol. + + + + +Perkins & Singh Standards Track [Page 9] + +RFC 8083 RTP Circuit Breakers March 2017 + + + Two packet loss regimes can be observed: 1) RTCP RR packets show a + non-zero packet loss fraction while the extended highest sequence + number received continues to increment; and 2) RR packets show a loss + fraction of zero, but the extended highest sequence number received + does not increment even though the sender has been transmitting RTP + data packets. The former corresponds to the TCP congestion avoidance + state and indicates a congested path that is still delivering data; + the latter corresponds to a TCP timeout and is most likely due to a + path failure. A third condition is that data is being sent but no + RTCP feedback is received at all, corresponding to a failure of the + reverse path. We derive circuit breaker conditions for these loss + regimes in the following. + +4.1. RTP/AVP Circuit Breaker #1: RTCP Timeout + + An RTCP timeout can occur when RTP data packets are being sent, but + there are no RTCP reports returned from the receiver. This is either + due to a failure of the receiver to send RTCP reports or a failure of + the return path that is preventing those RTCP reporting from being + delivered. In either case, it is not safe to continue transmission + since the sender has no way of knowing if it is causing congestion. + + 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 (where Td + is calculated without the randomization factor and using the fixed + minimum interval of Tmin=5 seconds), SHOULD cease transmission (see + Section 4.5). The rationale for this choice of timeout is as + described in Section 6.2 of [RFC3550] ("so that implementations which + do not use the reduced value for transmitting RTCP packets are not + timed out by other participants prematurely") and has been updated by + Section 6.1.4 of [RFC8108] to account for the use of the RTP/AVPF + profile [RFC4585] or the RTP/SAVPF profile [RFC5124]. + + To reduce the risk of premature timeout, implementations SHOULD NOT + configure the RTCP bandwidth such that Td is larger than 5 seconds. + Similarly, implementations that use the RTP/AVPF profile [RFC4585] or + the RTP/SAVPF profile [RFC5124] SHOULD NOT configure T_rr_interval to + values larger than 4 seconds (the reduced limit for T_rr_interval + follows Section 6.1.3 of [RFC8108]). + + The choice of three RTCP reporting intervals as the timeout is made + following Section 6.3.5 of RFC 3550 [RFC3550]. This specifies that + participants in an RTP session will timeout and remove an RTP sender + from the list of active RTP senders if no RTP data packets have been + received from that RTP sender within the last two RTCP reporting + intervals. Using a timeout of three RTCP reporting intervals is + therefore large enough that the other participants will have timed + + + +Perkins & Singh Standards Track [Page 10] + +RFC 8083 RTP Circuit Breakers March 2017 + + + out the sender if a network problem stops the data packets it is + sending from reaching the receivers, even allowing for loss of some + RTCP packets. + + If a sender is transmitting a large number of RTP media streams, such + that the corresponding RTCP SR or RR packets are too large to fit + into the network MTU, the receiver will generate RTCP SR or RR + packets in a round-robin manner. In this case, the sender SHOULD + treat receipt of an RTCP SR or RR packet corresponding to any SSRC it + sent on the same 5-tuple of source and destination IP address, port, + and protocol as an indication that the receiver and return path are + working and thus preventing the RTCP timeout circuit breaker from + triggering. + +4.2. RTP/AVP Circuit Breaker #2: Media Timeout + + If RTP data packets are being sent but the RTCP SR or RR packets + reporting on that SSRC indicate a non-increasing extended highest + sequence number received, this is an indication that those RTP data + packets are not reaching the receiver. This could be a short-term + issue affecting only a few RTP packets, perhaps caused by a slow-to- + open firewall or a transient connectivity problem, but if the issue + persists, it is a sign of a more ongoing and significant problem (a + "media timeout"). + + The time needed to declare a media timeout depends on the parameters + Tdr, Tr, Tf, and on the non-reporting threshold k. The value of k is + chosen so that when Tdr is large compared to Tr and Tf, receipt of at + least k RTCP reports with non-increasing extended highest sequence + number received gives reasonable assurance that the forward path has + failed and that the RTP data packets have not been lost by chance. + The RECOMMENDED value for k is 5 reports. + + When Tdr < Tf, then RTP data packets are being sent at a rate less + than one per RTCP reporting interval of the receiver, so the extended + highest sequence number received can be expected to be non-increasing + for some receiver RTCP reporting intervals. Similarly, when + Tdr < Tr, some receiver RTCP reporting intervals might pass before + the RTP data packets arrive at the receiver, also leading to reports + where the extended highest sequence number received is non- + increasing. Both issues require the media timeout interval to be + scaled relative to the threshold, k. + + The media timeout RTP circuit breaker is therefore as follows. When + starting sending, calculate MEDIA_TIMEOUT using: + + MEDIA_TIMEOUT = ceil(k * max(Tf, Tr, Tdr) / Tdr) + + + + +Perkins & Singh Standards Track [Page 11] + +RFC 8083 RTP Circuit Breakers March 2017 + + + When a sender receives an RTCP packet that indicates reception of the + media it has been sending, then it cancels the media timeout circuit + breaker. If it is still sending, then it MUST calculate a new value + for MEDIA_TIMEOUT and set a new media timeout circuit breaker. + + If 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 MEDIA_TIMEOUT with + the new value, extending the media timeout circuit breaker; + otherwise, it keeps the original value of MEDIA_TIMEOUT. This + process is known as reconsidering the media timeout circuit breaker. + + If MEDIA_TIMEOUT consecutive RTCP packets are received indicating + that the media being sent was not received, and the media timeout + circuit breaker has not been canceled, then the media timeout circuit + breaker triggers. When the media timeout circuit breaker triggers, + the sender SHOULD cease transmission (see Section 4.5). + + When stopping sending an RTP stream, a sender MUST cancel the + corresponding media timeout circuit breaker. + +4.3. RTP/AVP Circuit Breaker #3: Congestion + + If RTP data packets are being sent and the corresponding RTCP SR or + RR packets show non-zero packet loss fraction and increasing extended + highest sequence number received, then those RTP data packets are + arriving at the receiver, but some degree of congestion is occurring. + The RTP/AVP profile [RFC3551] states that: + + If best-effort service is being used, RTP receivers SHOULD monitor + packet loss to ensure that the packet loss rate is within + acceptable parameters. Packet loss is considered acceptable if a + TCP flow across the same network path and experiencing the same + network conditions would achieve an average throughput, measured + on a reasonable timescale, that is not less than [the throughput] + the RTP flow is achieving. This condition can be satisfied by + implementing congestion control mechanisms to adapt the + transmission rate (or the number of layers subscribed for a + layered multicast session), or by arranging for a receiver to + leave the session if the loss rate is unacceptably high. + + The comparison to TCP cannot be specified exactly, but is intended + as an "order-of-magnitude" comparison in timescale and throughput. + The timescale on which TCP throughput is measured is the round- + trip time of the connection. In essence, this requirement states + that it is not acceptable to deploy an application (using RTP or + + + + + +Perkins & Singh Standards Track [Page 12] + +RFC 8083 RTP Circuit Breakers March 2017 + + + any other transport protocol) on the best-effort Internet which + consumes bandwidth arbitrarily and does not compete fairly with + TCP within an order of magnitude. + + The phase "order of magnitude" in the above means within a factor of + ten, approximately. In order to implement this, it is necessary to + estimate the throughput a bulk TCP connection would achieve over the + path. For a long-lived TCP Reno connection, it has been shown that + the TCP throughput, X, in bytes per second, can be estimated as + follows [Padhye]: + + s + X = ------------------------------------------------------------- + Tr*sqrt(2*b*p/3)+(t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p*p))) + + This is the same approach to estimated TCP throughput that is used in + [RFC5348]. Under conditions of low packet loss, the second term on + the denominator is small, so this formula can be approximated with + reasonable accuracy as follows [Mathis]: + + s + X = ---------------- + Tr*sqrt(2*b*p/3) + + It is RECOMMENDED that this simplified throughput equation be used + since the reduction in accuracy is small, and it is much simpler to + calculate than the full equation. Measurements have shown that the + simplified TCP throughput equation is effective as an RTP circuit + breaker for multimedia flows sent to hosts on residential networks + using Asymmetric Digital Subscriber Line (ADSL) and cable modem links + [Singh]. The data shows that the full TCP throughput equation tends + to be more sensitive to packet loss and triggers the RTP circuit + breaker earlier than the simplified equation. Implementations that + desire this extra sensitivity MAY use the full TCP throughput + equation in the RTP circuit breaker. Initial measurements in LTE + networks have shown that the extra sensitivity is helpful in that + environment, with the full TCP throughput equation giving a more + balanced circuit breaker response than the simplified TCP equation + [Sarker]; other networks might see similar behavior. + + No matter what TCP throughput equation is chosen, two parameters need + to be estimated and reported to the sender in order to calculate the + throughput: the round-trip time, Tr, and the loss event rate, p (the + packet size, s, is known to the sender). The round-trip time can be + estimated from RTCP SR and RR packets. This is done too infrequently + for accurate statistics but is the best that can be done with the + standard RTCP mechanisms. + + + + +Perkins & Singh Standards Track [Page 13] + +RFC 8083 RTP Circuit Breakers March 2017 + + + Report blocks in RTCP SR or RR packets contain the packet loss + fraction, rather than the loss event rate, so p cannot be reported + (TCP typically treats the loss of multiple packets within a single + RTT as one loss event, but RTCP RR packets report the overall + fraction of packets lost and do not report when the packet losses + occurred). Using the loss fraction in place of the loss event rate + can overestimate the loss. We believe that this overestimate will + not be significant given that we are only interested in order of + magnitude comparison (Section 3.2.1 of [Floyd] shows that the + difference is small for steady-state conditions and random loss, but + using the loss fraction is more conservative in the case of bursty + loss). + + The congestion circuit breaker is therefore as follows. When a + sender that is transmitting at least one RTP packet every max(Tdr, + Tr) seconds receives an RTCP SR or RR packet that contains a report + block for an SSRC it is using, the sender MUST record the value of + the fraction lost field from the report block, and the time since the + last report block was received, for that SSRC. If more than + CB_INTERVAL (see below) report blocks have been received for that + SSRC, the sender MUST calculate the average fraction lost over the + last CB_INTERVAL reporting intervals and then estimate the TCP + throughput that would be achieved over the path using the chosen TCP + throughput equation and the measured values of the round-trip time, + Tr, the loss event rate, p (approximated by the average fraction + lost, as is described below), and the packet size, s. The estimate + of the TCP throughput, X, is then compared with the actual sending + rate of the RTP stream. If the actual sending rate of the RTP stream + is more than 10 * X, then the congestion circuit breaker is + triggered. + + The average fraction lost is calculated based on the sum (over the + last CB_INTERVAL reporting intervals) of the fraction lost in each + reporting interval that is then multiplied by the duration of the + corresponding reporting interval and then divided by the total + duration of the last CB_INTERVAL reporting intervals. The + CB_INTERVAL parameter is set to: + + CB_INTERVAL = + ceil(3*min(max(10*G*Tf, 10*Tr, 3*Tdr), max(15, 3*Td))/(3*Tdr)) + + The parameters that feed into CB_INTERVAL are chosen to give the + congestion control algorithm time to react to congestion. They give + at least three RTCP reports, ten round trip times, and ten groups of + frames to adjust the rate to reduce the congestion to a reasonable + level. It is expected that a responsive congestion control algorithm + + + + + +Perkins & Singh Standards Track [Page 14] + +RFC 8083 RTP Circuit Breakers March 2017 + + + will begin to respond with the next group of frames after it receives + indication of congestion, so CB_INTERVAL ought to be a much longer + interval than the congestion response. + + If the RTP/AVPF profile [RFC4585] or the RTP/SAVPF [RFC5124] is used, + and the T_rr_interval parameter is used to reduce the frequency of + regular RTCP reports, then the value of Tdr in the above expression + for the CB_INTERVAL parameter MUST be replaced by max(T_rr_interval, + Tdr). + + The CB_INTERVAL parameter is calculated on joining the session, and + recalculated on receipt of each RTCP packet, after checking whether + the media timeout circuit breaker or the congestion circuit breaker + has been triggered. + + To ensure a timely response to persistent congestion, implementations + SHOULD NOT configure the RTCP bandwidth such that Tdr is larger than + 5 seconds. Similarly, implementations that use the RTP/AVPF profile + [RFC4585] or the RTP/SAVPF profile [RFC5124] SHOULD NOT configure + T_rr_interval to values larger than 4 seconds (the reduced limit for + T_rr_interval follows Section 6.1.3 of [RFC8108]). + + The rationale for enforcing a minimum sending rate below which the + congestion circuit breaker will not trigger is to avoid spurious + circuit breaker triggers when the number of packets sent per RTCP + reporting interval is small, and hence, the fraction lost samples are + subject to measurement artifacts. The bound of at least one packet + every max(Tdr, Tr) seconds is derived from the one packet per RTT + minimum sending rate of TCP [RFC8085], which is adapted for use with + RTP where the RTCP reporting interval is decoupled from the network + RTT. + + When the congestion circuit breaker is triggered, the sender SHOULD + cease transmission (see Section 4.5). However, if the sender is able + to reduce its sending rate by a factor of (approximately) ten, then + it MAY first reduce its sending rate by this factor (or some larger + amount) to see if that resolves the congestion. If the sending rate + is reduced in this way and the congestion circuit breaker triggers + again after the next CB_INTERVAL RTCP reporting intervals, the sender + MUST then cease transmission. An example of such a rate reduction + might be a video conferencing system that backs off to sending audio + only before completely dropping the call. If such a reduction in + sending rate resolves the congestion problem, the sender MAY + gradually increase the rate at which it sends data after a reasonable + amount of time has passed, provided it takes care not to cause the + problem to recur ("reasonable" is intentionally not defined here + since it depends on the application, media codec, and congestion + control algorithm). + + + +Perkins & Singh Standards Track [Page 15] + +RFC 8083 RTP Circuit Breakers March 2017 + + + The RTCP reporting interval of the media sender does not affect how + quickly the congestion circuit breaker can trigger. The timing is + based on the RTCP reporting interval of the receiver that generates + the SR/RR packets from which the loss rate and RTT estimate are + derived (note that RTCP requires all participants in a session to + have similar reporting intervals, else the participant timeout rules + in [RFC3550] will not work, so this interval is likely similar to + that of the sender). If the incoming RTCP SR or RR packets are using + a reduced minimum RTCP reporting interval (as specified in + Section 6.2 of RFC 3550 [RFC3550] or the RTP/AVPF profile [RFC4585]), + then that reduced RTCP reporting interval is used when determining if + the circuit breaker is triggered. + + If there are more media streams that can be reported in a single RTCP + SR or RR packet, or if the size of a complete RTCP SR or RR packet + exceeds the network MTU, then the receiver will report on a subset of + sources in each reporting interval with the subsets selected round- + robin across multiple intervals so that all sources are eventually + reported [RFC3550]. When generating such round-robin RTCP reports, + priority SHOULD be given to reports on sources that have high packet + loss rates to ensure that senders are aware of network congestion + they are causing (this is an update to [RFC3550]). + +4.4. RTP/AVP Circuit Breaker #4: Media Usability + + Applications that use RTP are generally tolerant to some amount of + packet loss. How much packet loss can be tolerated will depend on + the application, media codec, and the amount of error correction and + packet loss concealment that is applied. There is an upper bound on + the amount of loss that can be corrected, however, beyond which the + media becomes unusable. Similarly, many applications have some upper + bound on the media capture to play-out latency that can be tolerated + before the application becomes unusable. The latency bound will + depend on the application, but typical values can range from the + order of a few hundred milliseconds for voice telephony and + interactive conferencing applications up to several seconds for some + video-on-demand systems. + + As a final circuit breaker, RTP senders SHOULD monitor the reported + packet loss and delay to estimate whether the media is likely to be + suitable for the intended purpose. If the packet loss rate and/or + latency is such that the media has become unusable and has remained + unusable for a significant time period, then the application SHOULD + cease transmission. Similarly, receivers SHOULD monitor the quality + of the media they receive, and if the quality is unusable for a + significant time period, they SHOULD terminate the session. This + memo intentionally does not define a bound on the packet loss rate or + latency that will result in unusable media, as these are highly + + + +Perkins & Singh Standards Track [Page 16] + +RFC 8083 RTP Circuit Breakers March 2017 + + + application dependent. Similarly, the time period that is considered + significant is application dependent but is likely on the order of + seconds, or tens of seconds. + + Sending media that suffers from such high packet loss or latency that + it is unusable at the receiver is both wasteful of resources and is + of no benefit to the user of the application. It also is highly + likely to be congesting the network and disrupting other + applications. As such, the congestion circuit breaker will almost + certainly trigger to stop flows where the media would be unusable due + to high packet loss or latency. However, in pathological scenarios + where the congestion circuit breaker does not stop the flow, it is + desirable to prevent the application sending unnecessary traffic that + might disrupt other uses of the network. The role of the media + usability circuit breaker is to protect the network in such cases. + +4.5. Ceasing Transmission + + What it means to cease transmission depends on the application. This + could mean stopping a single RTP flow or it could mean that multiple + bundled RTP flows are stopped. The intention is that the application + will stop sending RTP data packets on a particular 5-tuple (transport + protocol, source and destination ports, source and destination IP + addresses) until whatever network problem that triggered the RTP + circuit breaker has dissipated. RTP flows halted by the circuit + breaker SHOULD NOT be restarted automatically unless the sender has + received information that the congestion has dissipated or can + reasonably be expected to have dissipated. What could trigger this + expectation is necessarily application dependent, but could be, for + example, an indication that a competing flow has finished and freed + up some capacity, or for an application running on a mobile device it + could indicate that the device moved to a new location so the flow + would traverse a different path if it were restarted. Ideally, a + human user will be involved in the decision to try to restart the + flow since that user will eventually give up if the flows repeatedly + trigger the circuit breaker. This will help avoid problems with + automatic redial systems from congesting the network. + + It is recognized that the RTP implementation in some systems might + not be able to determine if a flow setup request was initiated by a + human user or automatically by some scripted higher-level component + of the system. These implementations MUST rate limit attempts to + restart a flow on the same 5-tuple as used by a flow that triggered + the circuit breaker so that the reaction to a triggered circuit + breaker lasts for at least the triggering interval [RFC8084]. + + + + + + +Perkins & Singh Standards Track [Page 17] + +RFC 8083 RTP Circuit Breakers March 2017 + + + The RTP circuit breaker will only trigger, and cease transmission, + for media flows subject to long-term persistent congestion. Such + flows are likely to have poor quality and usability for some time + before the circuit breaker triggers. Implementations can monitor + RTCP Receiver Report blocks being returned for their media flows and + might find it beneficial to use this information to provide a user + interface cue that problems are occurring in advance of the circuit + breaker triggering. + +5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles + + Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) + [RFC4585] allows receivers to send early RTCP reports, in some cases, + to inform the sender about particular events in the media stream. + There are several use cases for such early RTCP reports, including + providing rapid feedback to a sender about the onset of congestion. + The RTP/SAVPF Profile [RFC5124] is a secure variant of the RTP/AVPF + profile that is treated the same in the context of the RTP circuit + breaker. These feedback profiles are often used with non-compound + RTCP reports [RFC5506] to reduce the reporting overhead. + + Receiving rapid feedback about congestion events potentially allows + congestion control algorithms to be more responsive and to better + adapt the media transmission to the limitations of the network. It + is expected that many RTP congestion control algorithms will adopt + the RTP/AVPF profile or the RTP/SAVPF profile for this reason and + thus define new transport-layer feedback reports that suit their + requirements. Since these reports are not yet defined, and likely + very specific to the details of the congestion control algorithm + chosen, they cannot be used as part of the generic RTP circuit + breaker. + + Reduced-size RTCP reports sent under the RTP/AVPF early feedback + rules that do not contain an RTCP SR or RR packet MUST be ignored by + the congestion circuit breaker (they do not contain the information + needed by the congestion circuit breaker algorithm) but MUST be + counted as received packets for the RTCP timeout circuit breaker. + Reduced-size RTCP reports sent under the RTP/AVPF early feedback + rules that contain RTCP SR or RR packets MUST be processed by the + congestion circuit breaker as if they were sent as regular RTCP + reports and counted towards the circuit breaker conditions specified + in Section 4 of this memo. This will potentially make the RTP + circuit breaker trigger earlier than it would if the RTP/AVPF profile + was not used. + + When using ECN with RTP (see Section 7), early RTCP feedback packets + can contain ECN feedback reports. The count of ECN-CE-marked packets + contained in those ECN feedback reports is counted towards the number + + + +Perkins & Singh Standards Track [Page 18] + +RFC 8083 RTP Circuit Breakers March 2017 + + + of lost packets reported if the ECN Feedback Report is sent in a + compound RTCP packet along with an RTCP SR/RR report packet. Reports + of ECN-CE packets sent as reduced-size RTCP ECN feedback packets + without an RTCP SR/RR packet MUST be ignored. + + These rules are intended to allow the use of low-overhead RTP/AVPF + feedback for generic NACK messages without triggering the RTP circuit + breaker. This is expected to make such feedback suitable for RTP + congestion control algorithms that need to quickly report loss events + in between regular RTCP reports. The reaction to reduced-size RTCP + SR/RR packets is to allow such algorithms to send feedback that can + trigger the circuit breaker when desired. + + The RTP/AVPF and RTP/SAVPF profiles include the T_rr_interval + parameter that can be used to adjust the regular RTCP reporting + interval. The use of the T_rr_interval parameter changes the + behavior of the RTP circuit breaker, as described in Section 4. + +6. Impact of RTCP Extended Reports (XR) + + RTCP Extended Report (XR) blocks provide additional reception quality + metrics, but do not change the RTCP timing rules. Some of the RTCP + XR blocks provide information that might be useful for congestion + control purposes, others provide non-congestion-related metrics. + With the exception of RTCP XR ECN Summary Reports (see Section 7), + the presence of RTCP XR blocks in a compound RTCP packet does not + affect the RTP circuit breaker algorithm. For consistency and ease + of implementation, only the receiver report blocks contained in RTCP + SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets + are used by the RTP circuit breaker algorithm. + +7. Impact of Explicit Congestion Notification (ECN) + + The use of ECN for RTP flows does not affect the RTCP timeout circuit + breaker (Section 4.1) or the media timeout circuit breaker + (Section 4.2) since these are both connectivity checks that simply + determinate if any packets are being received. + + At the time of this writing, there's no consensus on how the receipt + of ECN feedback will impact the congestion circuit breaker + (Section 4.3) or indeed whether the congestion circuit breaker ought + to take ECN feedback into account. A future replacement of this memo + is expected to provide guidance for implementers. + + For the media usability circuit breaker (Section 4.4), ECN-CE-marked + packets arrive at the receiver, and if they arrive in time, they will + be decoded and rendered as normal. Accordingly, receipt of such + packets ought not affect the usability of the media, and the arrival + + + +Perkins & Singh Standards Track [Page 19] + +RFC 8083 RTP Circuit Breakers March 2017 + + + of RTCP feedback indicating their receipt is not expected to impact + the operation of the media usability circuit breaker. + +8. Impact of Bundled Media and Layered Coding + + The RTP circuit breaker operates on a per-RTP session basis. An RTP + sender that participates in several RTP sessions MUST treat each RTP + session independently with regards to the RTP circuit breaker. + + An RTP sender can generate several media streams within a single RTP + session, with each stream using a different SSRC. This can happen if + bundled media are in use when using simulcast or when using layered + media coding. By default, each SSRC will be treated independently by + the RTP circuit breaker. However, the sender MAY choose to treat the + flows (or a subset thereof) as a group such that a circuit breaker + trigger for one flow applies to the group of flows as a whole and + either causes the entire group to cease transmission or causes the + sending rate of the group to reduce by a factor of ten, depending on + the RTP circuit breaker triggered. Grouping flows in this way is + expected to be especially useful for layered flows sent using + multiple SSRCs as it allows the layered flow to react as a whole, + thus ceasing transmission on the enhancement layers first to reduce + sending rate, if necessary, rather than treating each layer + independently. Care needs to be taken if the different media streams + sent on a single transport-layer flow use different Differentiated + Services Code Point (DSCP) values [RFC7657] [WebRTC-QoS] since + congestion could be experienced differently depending on the DSCP + marking. Accordingly, RTP media streams with different DSCP values + SHOULD NOT be considered as a group when evaluating the RTP circuit + breaker conditions. + +9. Security Considerations + + The security considerations of [RFC3550] apply. + + If the RTP/AVPF profile is used to provide rapid RTCP feedback, the + security considerations of [RFC4585] apply. If ECN feedback for RTP + over UDP/IP is used, the security considerations of [RFC6679] apply. + + If non-authenticated RTCP reports are used, an on-path attacker can + trivially generate fake RTCP packets that indicate high packet loss + rates and thus cause the circuit breaker to trigger and disrupt an + RTP session. This is somewhat more difficult for an off-path + attacker due to the need to guess the randomly chosen RTP SSRC value + and the RTP sequence number. This attack can be avoided if RTCP + packets are authenticated; authentication options are discussed in + [RFC7201]. + + + + +Perkins & Singh Standards Track [Page 20] + +RFC 8083 RTP Circuit Breakers March 2017 + + + Timely operation of the RTP circuit breaker depends on the choice of + RTCP reporting interval. If the receiver has a reporting interval + that is overly long, then the responsiveness of the circuit breaker + decreases. In the limit, the RTP circuit breaker can be disabled for + all practical purposes by configuring an RTCP reporting interval that + has a duration of many minutes. This issue is not specific to the + circuit breaker: long RTCP reporting intervals also prevent reception + quality reports, feedback messages, codec control messages, etc., + from being used. Implementations are expected to impose an upper + limit on the RTCP reporting interval they are willing to negotiate + (based on the session bandwidth and RTCP bandwidth fraction) when + using the RTP circuit breaker, as discussed in Section 4.3. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, <http://www.rfc-editor.org/info/rfc3550>. + + [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and + Video Conferences with Minimal Control", STD 65, RFC 3551, + DOI 10.17487/RFC3551, July 2003, + <http://www.rfc-editor.org/info/rfc3551>. + + [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., + "RTP Control Protocol Extended Reports (RTCP XR)", + RFC 3611, DOI 10.17487/RFC3611, November 2003, + <http://www.rfc-editor.org/info/rfc3611>. + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, + DOI 10.17487/RFC4585, July 2006, + <http://www.rfc-editor.org/info/rfc4585>. + + [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP + Friendly Rate Control (TFRC): Protocol Specification", + RFC 5348, DOI 10.17487/RFC5348, September 2008, + <http://www.rfc-editor.org/info/rfc5348>. + + + + +Perkins & Singh Standards Track [Page 21] + +RFC 8083 RTP Circuit Breakers March 2017 + + + [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., + and K. Carlberg, "Explicit Congestion Notification (ECN) + for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August + 2012, <http://www.rfc-editor.org/info/rfc6679>. + +10.2. Informative References + + [Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer, + "Equation-Based Congestion Control for Unicast + Applications", ACM SIGCOMM Computer Communication + Review, Volume 30, Issue 4, pages 43-56, + DOI 10.1145/347059.347397, August 2000. + + [Mathis] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The + Macroscopic Behavior of the TCP Congestion Avoidance + Algorithm", ACM SIGCOMM Computer Communication + Review, Volume 27, Issue 3, pages 67-82, + DOI 10.1145/263932.264023, July 1997. + + [Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, + "Modeling TCP Throughput: A Simple Model and its Empirical + Validation", ACM SIGCOMM Computer Communication + Review Volume 30, Issue 4, pages 303-314, + DOI 10.1145/285237.285291, August 1998. + + [RFC2862] Civanlar, M. and G. Cash, "RTP Payload Format for Real- + Time Pointers", RFC 2862, DOI 10.17487/RFC2862, June 2000, + <http://www.rfc-editor.org/info/rfc2862>. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, + <http://www.rfc-editor.org/info/rfc3168>. + + [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text + Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005, + <http://www.rfc-editor.org/info/rfc4103>. + + [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, + "Codec Control Messages in the RTP Audio-Visual Profile + with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, + February 2008, <http://www.rfc-editor.org/info/rfc5104>. + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for + Real-time Transport Control Protocol (RTCP)-Based Feedback + (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February + 2008, <http://www.rfc-editor.org/info/rfc5124>. + + + + +Perkins & Singh Standards Track [Page 22] + +RFC 8083 RTP Circuit Breakers March 2017 + + + [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in + RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, + <http://www.rfc-editor.org/info/rfc5450>. + + [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size + Real-Time Transport Control Protocol (RTCP): Opportunities + and Consequences", RFC 5506, DOI 10.17487/RFC5506, April + 2009, <http://www.rfc-editor.org/info/rfc5506>. + + [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion + Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, + <http://www.rfc-editor.org/info/rfc5681>. + + [RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended + Report (XR) Block for Packet Delay Variation Metric + Reporting", RFC 6798, DOI 10.17487/RFC6798, November 2012, + <http://www.rfc-editor.org/info/rfc6798>. + + [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol + (RTCP) Extended Report (XR) Block for Delay Metric + Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, + <http://www.rfc-editor.org/info/rfc6843>. + + [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, Ed., "RTP + Control Protocol (RTCP) Extended Report (XR) Block for + Burst/Gap Loss Metric Reporting", RFC 6958, + DOI 10.17487/RFC6958, May 2013, + <http://www.rfc-editor.org/info/rfc6958>. + + [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol + (RTCP) Extended Report (XR) Block for Discard Count Metric + Reporting", RFC 7002, DOI 10.17487/RFC7002, September + 2013, <http://www.rfc-editor.org/info/rfc7002>. + + [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control + Protocol (RTCP) Extended Report (XR) Block for Burst/Gap + Discard Metric Reporting", RFC 7003, DOI 10.17487/RFC7003, + September 2013, <http://www.rfc-editor.org/info/rfc7003>. + + [RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control + Protocol (RTCP) Extended Report (XR) for RLE of Discarded + Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014, + <http://www.rfc-editor.org/info/rfc7097>. + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + <http://www.rfc-editor.org/info/rfc7201>. + + + + +Perkins & Singh Standards Track [Page 23] + +RFC 8083 RTP Circuit Breakers March 2017 + + + [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services + (Diffserv) and Real-Time Communication", RFC 7657, + DOI 10.17487/RFC7657, November 2015, + <http://www.rfc-editor.org/info/rfc7657>. + + [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) + Concepts, Abstract Mechanism, and Requirements", RFC 7713, + DOI 10.17487/RFC7713, December 2015, + <http://www.rfc-editor.org/info/rfc7713>. + + [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", + BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, + <http://www.rfc-editor.org/info/rfc8084>. + + [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage + Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, + March 2017, <http://www.rfc-editor.org/info/rfc8085>. + + [RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, + "Sending Multiple RTP Streams in a Single RTP Session", + RFC 8108, DOI 10.17487/RFC8108, March 2017, + <http://www.rfc-editor.org/info/rfc8108>. + + [Sarker] Sarker, Z., Singh, V., and C. Perkins, "An Evaluation of + RTP Circuit Breaker Performance on LTE Networks", + Proceedings of the IEEE INFOCOM Workshop on Communication + and Networking Techniques for Contemporary Video, + DOI 10.1109/INFCOMW.2014.6849240, April 2014. + + [Singh] Singh, V., McQuistin, S., Ellis, M., and C. Perkins, + "Circuit Breakers for Multimedia Congestion Control", + Proceedings of the 2013 20th International Packet Video + Workshop (PV), DOI 10.1109/PV.2013.6691439, December 2013. + + [WebRTC-QoS] + Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP + Packet Markings for WebRTC QoS", Work in Progress, + draft-ietf-tsvwg-rtcweb-qos-18, August 2016. + + + + + + + + + + + + + +Perkins & Singh Standards Track [Page 24] + +RFC 8083 RTP Circuit Breakers March 2017 + + +Acknowledgements + + The authors would like to thank Bernard Aboba, Harald Alvestrand, Ben + Campbell, Alissa Cooper, Spencer Dawkins, Gorry Fairhurst, Stephen + Farrell, Nazila Fough, Kevin Gross, Cullen Jennings, Randell Jesup, + Mirja Kuehlewind, Jonathan Lennox, Matt Mathis, Stephen McQuistin, + Simon Perreault, Eric Rescorla, Abheek Saha, Meral Shirazipour, Fabio + Verdicchio, and Magnus Westerlund for their valuable feedback. + +Authors' Addresses + + Colin Perkins + University of Glasgow + School of Computing Science + Glasgow G12 8QQ + United Kingdom + + Email: csp@csperkins.org + + + Varun Singh + CALLSTATS I/O Oy + Runeberginkatu 4c A 4 + Helsinki 00100 + Finland + + Email: varun@callstats.io + URI: https://www.callstats.io/about + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Singh Standards Track [Page 25] + |