Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8083

Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions

Pages: 25
Proposed Standard
Updates:  3550
Part 2 of 2 – Pages 12 to 25
First   Prev   None

Top   ToC   RFC8083 - Page 12   prevText

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
Top   ToC   RFC8083 - Page 13
      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.
Top   ToC   RFC8083 - Page 14
   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
Top   ToC   RFC8083 - Page 15
   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).
Top   ToC   RFC8083 - Page 16
   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
Top   ToC   RFC8083 - Page 17
   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].
Top   ToC   RFC8083 - Page 18
   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
Top   ToC   RFC8083 - Page 19
   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
Top   ToC   RFC8083 - Page 20
   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].
Top   ToC   RFC8083 - Page 21
   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>.
Top   ToC   RFC8083 - Page 22
   [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>.
Top   ToC   RFC8083 - Page 23
   [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>.
Top   ToC   RFC8083 - Page 24
   [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.
Top   ToC   RFC8083 - Page 25

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