Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8083


Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions

Part 2 of 2, p. 12 to 25
Prev Section


prevText      Top      ToC       Page 12 
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      Up      ToC       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]:

      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]:

      X = ----------------

   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      Up      ToC       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

   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

   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:

         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      Up      ToC       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,

   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

   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      Up      ToC       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      Up      ToC       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      Up      ToC       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

   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      Up      ToC       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      Up      ToC       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

Top      Up      ToC       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,

   [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, <>.

   [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,

   [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,

   [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,

   [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,

Top      Up      ToC       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, <>.

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,

   [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,

   [RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
              Conversation", RFC 4103, DOI 10.17487/RFC4103, June 2005,

   [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, <>.

   [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, <>.

Top      Up      ToC       Page 23 
   [RFC5450]  Singer, D. and H. Desineni, "Transmission Time Offsets in
              RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009,

   [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, <>.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,

   [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,

   [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,

   [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,

   [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, <>.

   [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, <>.

   [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,

   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,

Top      Up      ToC       Page 24 
   [RFC7657]  Black, D., Ed. and P. Jones, "Differentiated Services
              (Diffserv) and Real-Time Communication", RFC 7657,
              DOI 10.17487/RFC7657, November 2015,

   [RFC7713]  Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
              Concepts, Abstract Mechanism, and Requirements", RFC 7713,
              DOI 10.17487/RFC7713, December 2015,

   [RFC8084]  Fairhurst, G., "Network Transport Circuit Breakers",
              BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <>.

   [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,

   [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.

              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      Up      ToC       Page 25 

   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


   Varun Singh
   Runeberginkatu 4c A 4
   Helsinki  00100