draft-ietf-avtcore-rtp-circuit-breakers-13.txt   draft-ietf-avtcore-rtp-circuit-breakers-14.txt 
AVTCORE Working Group C. Perkins AVTCORE Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Updates: 3550 (if approved) V. Singh Updates: 3550 (if approved) V. Singh
Intended status: Standards Track callstats.io Intended status: Standards Track callstats.io
Expires: August 13, 2016 February 10, 2016 Expires: September 18, 2016 March 17, 2016
Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
draft-ietf-avtcore-rtp-circuit-breakers-13 draft-ietf-avtcore-rtp-circuit-breakers-14
Abstract Abstract
The Real-time Transport Protocol (RTP) is widely used in telephony, The Real-time Transport Protocol (RTP) is widely used in telephony,
video conferencing, and telepresence applications. Such applications video conferencing, and telepresence applications. Such applications
are often run on best-effort UDP/IP networks. If congestion control are often run on best-effort UDP/IP networks. If congestion control
is not implemented in the applications, then network congestion will is not implemented in these applications, then network congestion can
deteriorate the user's multimedia experience. This acts as a safety lead to uncontrolled packet loss, and a resulting deterioration of
measure to prevent starvation of network resources denying other the user's multimedia experience. The congestion control algorithm
flows from access to the Internet, such measures are essential for an acts as a safety measure, stopping RTP flows from using excessive
Internet that is heterogeneous and for traffic that is hard to resources, and protecting the network from overload. At the time of
predict in advance. This document does not propose a congestion this writing, however, while there are several proprietary solutions,
control algorithm; instead, it defines a minimal set of RTP circuit- there is no standard algorithm for congestion control of interactive
breakers. Circuit-breakers are conditions under which an RTP sender RTP flows.
needs to stop transmitting media data in order to protect the network
from excessive congestion. It is expected that, in the absence of This document does not propose a congestion control algorithm. It
severe congestion, all RTP applications running on best-effort IP instead defines a minimal set of RTP circuit breakers: conditions
networks will be able to run without triggering these circuit under which an RTP sender needs to stop transmitting media data, to
breakers. Any future RTP congestion control specification will be protect the network from excessive congestion. It is expected that,
expected to operate within the constraints defined by these circuit in the absence of long-lived excessive congestion, RTP applications
breakers. running on best-effort IP networks will be able to operate without
triggering these circuit breakers. Future RTP congestion control
specifications will be expected to operate within the constraints
defined by these circuit breakers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 18, 2016.
This Internet-Draft will expire on August 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 34
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . 7 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . 7
4.1. RTP/AVP Circuit Breaker #1: RTCP Timeout . . . . . . . . 9 4.1. RTP/AVP Circuit Breaker #1: RTCP Timeout . . . . . . . . 9
4.2. RTP/AVP Circuit Breaker #2: Media Timeout . . . . . . . . 10 4.2. RTP/AVP Circuit Breaker #2: Media Timeout . . . . . . . . 10
4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 12 4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 12
4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 15 4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 15
4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 16 4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 16
5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 17 5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 17
6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 18 6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 18
7. Impact of Explicit Congestion Notification (ECN) . . . . . . 18 7. Impact of Explicit Congestion Notification (ECN) . . . . . . 19
8. Impact of Bundled Media and Layered Coding . . . . . . . . . 19 8. Impact of Bundled Media and Layered Coding . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] is widely used in The Real-time Transport Protocol (RTP) [RFC3550] is widely used in
voice-over-IP, video teleconferencing, and telepresence systems. voice-over-IP, video teleconferencing, and telepresence systems.
Many of these systems run over best-effort UDP/IP networks, and can Many of these systems run over best-effort UDP/IP networks, and can
suffer from packet loss and increased latency if network congestion suffer from packet loss and increased latency if network congestion
occurs. Designing effective RTP congestion control algorithms, to occurs. Designing effective RTP congestion control algorithms, to
adapt the transmission of RTP-based media to match the available adapt the transmission of RTP-based media to match the available
network capacity, while also maintaining the user experience, is a network capacity, while also maintaining the user experience, is a
difficult but important problem. Many such congestion control and difficult but important problem. Many such congestion control and
media adaptation algorithms have been proposed, but to date there is media adaptation algorithms have been proposed, but to date there is
no consensus on the correct approach, or even that a single standard no consensus on the correct approach, or even that a single standard
algorithm is desirable. algorithm is desirable.
This memo does not attempt to propose a new RTP congestion control This memo does not attempt to propose a new RTP congestion control
algorithm. Instead, we propose a small set of RTP circuit breakers. algorithm. Instead, we propose a small set of RTP circuit breakers:
These are conditions under which there is general agreement that an mechanisms that terminate RTP flows in conditions under which there
RTP flow is causing serious congestion, and hence ought to cease is general agreement that serious network congestion is occurring.
transmission. The RTP circuit breakers proposed in this memo are a The RTP circuit breakers proposed in this memo are a specific
specific instance of the general class of network transport circuit instance of the general class of network transport circuit breakers
breakers [I-D.ietf-tsvwg-circuit-breaker], designed to act as a [I-D.ietf-tsvwg-circuit-breaker], designed to act as a protection
protection mechanism of last resort to avoid persistent excessive mechanism of last resort to avoid persistent excessive congestion.
congestion. It is expected that future standards-track congestion It is expected that future standards-track congestion control
control algorithms for RTP will operate within the envelope defined algorithms for RTP will operate within the envelope defined by this
by this memo. memo.
2. Background 2. Background
We consider congestion control for unicast RTP traffic flows. This We consider congestion control for unicast RTP traffic flows. This
is the problem of adapting the transmission of an audio/visual data is the problem of adapting the transmission of an audio/visual data
flow, encapsulated within an RTP transport session, from one sender flow, encapsulated within an RTP transport session, from one sender
to one receiver, so that it does not use more capacity than is to one receiver, so that it does not use more capacity than is
available along the network path. Such adaptation needs to be done available along the network path. Such adaptation needs to be done
in a way that limits the disruption to the user experience caused by in a way that limits the disruption to the user experience caused by
both packet loss and excessive rate changes. Congestion control for both packet loss and excessive rate changes. Congestion control for
skipping to change at page 8, line 17 skipping to change at page 8, line 21
some non-RTCP feedback channel to report congestion and signal some non-RTCP feedback channel to report congestion and signal
circuit breaker conditions. circuit breaker conditions.
The RTCP timeout circuit breaker (Section 4.1) will trigger if an The RTCP timeout circuit breaker (Section 4.1) will trigger if an
implementation of this memo attempts to interwork with an endpoint implementation of this memo attempts to interwork with an endpoint
that does not support RTCP. Implementations that sometimes need to that does not support RTCP. Implementations that sometimes need to
interwork with endpoints that do not support RTCP need to disable the interwork with endpoints that do not support RTCP need to disable the
RTP circuit breakers if they don't receive some confirmation via RTP circuit breakers if they don't receive some confirmation via
signalling that the remote endpoint implements RTCP (the presence of signalling that the remote endpoint implements RTCP (the presence of
an SDP "a=rtcp:" attribute in an answer might be such an indication). an SDP "a=rtcp:" attribute in an answer might be such an indication).
This approach SHOULD NOT be used on networks that might be subject to The RTP Circuit Breaker SHOULD NOT be disabled on networks that might
congestion unless equivalent mechanisms are defined using some non- be subject to congestion, unless equivalent mechanisms are defined
RTCP feedback channel to report congestion and signal circuit breaker using some non-RTCP feedback channel to report congestion and signal
conditions [I-D.ietf-tsvwg-circuit-breaker]. circuit breaker conditions [I-D.ietf-tsvwg-circuit-breaker].
Three potential congestion signals are available from the basic RTCP Three potential congestion signals are available from the basic RTCP
SR/RR packets and are reported for each SSRC in the RTP session: 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 1. The sender can estimate the network round-trip time once per RTCP
reporting interval, based on the contents and timing of RTCP SR reporting interval, based on the contents and timing of RTCP SR
and RR packets. and RR packets.
2. Receivers report a jitter estimate (the statistical variance of 2. Receivers report a jitter estimate (the statistical variance of
the RTP data packet inter-arrival time) calculated over the RTCP the RTP data packet inter-arrival time) calculated over the RTCP
skipping to change at page 13, line 5 skipping to change at page 13, line 5
This is the same approach to estimated TCP throughput that is used in This is the same approach to estimated TCP throughput that is used in
[RFC5348]. Under conditions of low packet loss the second term on [RFC5348]. Under conditions of low packet loss the second term on
the denominator is small, so this formula can be approximated with the denominator is small, so this formula can be approximated with
reasonable accuracy as follows [Mathis]: reasonable accuracy as follows [Mathis]:
s s
X = ---------------- X = ----------------
Tr*sqrt(2*b*p/3) Tr*sqrt(2*b*p/3)
It is RECOMMENDED that this simplified throughout equation be used, It is RECOMMENDED that this simplified throughput equation be used,
since the reduction in accuracy is small, and it is much simpler to since the reduction in accuracy is small, and it is much simpler to
calculate than the full equation. Measurements have shown that the calculate than the full equation. Measurements have shown that the
simplified TCP throughput equation is effective as an RTP circuit simplified TCP throughput equation is effective as an RTP circuit
breaker for multimedia flows sent to hosts on residential networks breaker for multimedia flows sent to hosts on residential networks
using ADSL and cable modem links [Singh]. The data shows that the using ADSL and cable modem links [Singh]. The data shows that the
full TCP throughput equation tends to be more sensitive to packet full TCP throughput equation tends to be more sensitive to packet
loss and triggers the RTP circuit breaker earlier than the simplified loss and triggers the RTP circuit breaker earlier than the simplified
equation. Implementations that desire this extra sensitivity MAY use equation. Implementations that desire this extra sensitivity MAY use
the full TCP throughput equation in the RTP circuit breaker. Initial the full TCP throughput equation in the RTP circuit breaker. Initial
measurements in LTE networks have shown that the extra sensitivity is measurements in LTE networks have shown that the extra sensitivity is
skipping to change at page 13, line 44 skipping to change at page 13, line 44
can overestimate the loss. We believe that this overestimate will can overestimate the loss. We believe that this overestimate will
not be significant, given that we are only interested in order of not be significant, given that we are only interested in order of
magnitude comparison ([Floyd] section 3.2.1 shows that the difference magnitude comparison ([Floyd] section 3.2.1 shows that the difference
is small for steady-state conditions and random loss, but using the is small for steady-state conditions and random loss, but using the
loss fraction is more conservative in the case of bursty loss). loss fraction is more conservative in the case of bursty loss).
The congestion circuit breaker is therefore: when a sender that is The congestion circuit breaker is therefore: when a sender that is
transmitting at least one RTP packet every max(Tdr, Tr) seconds 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 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 SSRC it is using, the sender MUST record the value of the fraction
lost field in the report block and the time since the last report 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 block was received, for that SSRC. If more than CB_INTERVAL (see
below) report blocks have been received for that SSRC, the sender below) report blocks have been received for that SSRC, the sender
MUST calculate the average fraction lost over the last CB_INTERVAL MUST calculate the average fraction lost over the last CB_INTERVAL
reporting intervals, and then estimate the TCP throughput that would reporting intervals, and then estimate the TCP throughput that would
be achieved over the path using the chosen TCP throughput equation be achieved over the path using the chosen TCP throughput equation
and the measured values of the round-trip time, Tr, the loss event and the measured values of the round-trip time, Tr, the loss event
rate, p (approximated by the average fraction lost, as is described rate, p (approximated by the average fraction lost, as is described
below), and the packet size, s. The estimate of the TCP throughput, 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. 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, If the actual sending rate of the RTP stream is more than 10 * X,
then the congestion circuit breaker is triggered. then the congestion circuit breaker is triggered.
skipping to change at page 16, line 21 skipping to change at page 16, line 21
As a final circuit breaker, RTP senders SHOULD monitor the reported As a final circuit breaker, RTP senders SHOULD monitor the reported
packet loss and delay to estimate whether the media is likely to be 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 suitable for the intended purpose. If the packet loss rate and/or
latency is such that the media has become unusable, and has remained latency is such that the media has become unusable, and has remained
unusable for a significant time period, then the application SHOULD unusable for a significant time period, then the application SHOULD
cease transmission. Similarly, receivers SHOULD monitor the quality cease transmission. Similarly, receivers SHOULD monitor the quality
of the media they receive, and if the quality is unusable for a of the media they receive, and if the quality is unusable for a
significant time period, they SHOULD terminate the session. This significant time period, they SHOULD terminate the session. This
memo intentionally does not define a bound on the packet loss rate or memo intentionally does not define a bound on the packet loss rate or
latency that will result in unusable media, nor does it specify what latency that will result in unusable media, as these are highly
time period is deemed significant, as these are highly application application dependent. Similarly, the time period that is considered
dependent. 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 Sending media that suffers from such high packet loss or latency that
it is unusable at the receiver is both wasteful of resources, and of it is unusable at the receiver is both wasteful of resources, and of
no benefit to the user of the application. It also is highly likely no benefit to the user of the application. It also is highly likely
to be congesting the network, and disrupting other applications. As to be congesting the network, and disrupting other applications. As
such, the congestion circuit breaker will almost certainly trigger to such, the congestion circuit breaker will almost certainly trigger to
stop flows where the media would be unusable due to high packet loss stop flows where the media would be unusable due to high packet loss
or latency. However, in pathological scenarios where the congestion or latency. However, in pathological scenarios where the congestion
circuit breaker does not stop the flow, it is desirable to prevent circuit breaker does not stop the flow, it is desirable to prevent
the application sending unnecessary traffic that might disrupt other the application sending unnecessary traffic that might disrupt other
skipping to change at page 17, line 19 skipping to change at page 17, line 20
not be able to determine if a call set-up request was initiated by a not be able to determine if a call set-up request was initiated by a
human user, or automatically by some scripted higher-level component human user, or automatically by some scripted higher-level component
of the system. These implementations MUST rate limit attempts to of the system. These implementations MUST rate limit attempts to
restart a call to the same destination 3-tuple as used by a call that restart a call to the same destination 3-tuple as used by a call that
triggered the circuit breaker, so that the reaction to a triggered triggered the circuit breaker, so that the reaction to a triggered
circuit breaker lasts for at least the triggering interval circuit breaker lasts for at least the triggering interval
[I-D.ietf-tsvwg-circuit-breaker]. The chosen rate limit ought to not [I-D.ietf-tsvwg-circuit-breaker]. The chosen rate limit ought to not
exceed the rate at which an annoyed human caller might redial a exceed the rate at which an annoyed human caller might redial a
misbehaving phone. misbehaving phone.
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 Reception 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 5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles
Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)
[RFC4585] allows receivers to send early RTCP reports in some cases, [RFC4585] allows receivers to send early RTCP reports in some cases,
to inform the sender about particular events in the media stream. to inform the sender about particular events in the media stream.
There are several use cases for such early RTCP reports, including There are several use cases for such early RTCP reports, including
providing rapid feedback to a sender about the onset of congestion. providing rapid feedback to a sender about the onset of congestion.
The RTP/SAVPF Profile [RFC5124] is a secure variant of the RTP/AVPF 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 profile, that is treated the same in the context of the RTP circuit
breaker. These feedback profiles are often used with non-compound breaker. These feedback profiles are often used with non-compound
skipping to change at page 19, line 29 skipping to change at page 19, line 41
media coding. By default, each SSRC will be treated independently by media coding. By default, each SSRC will be treated independently by
the RTP circuit breaker. However, the sender MAY choose to treat the 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 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 trigger for one flow applies to the group of flows as a whole, and
either causes the entire group to cease transmission, or the sending either causes the entire group to cease transmission, or the sending
rate of the group to reduce by a factor of ten, depending on the RTP 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 circuit breaker triggered. Grouping flows in this way is expected to
be especially useful for layered flows sent using multiple SSRCs, as be especially useful for layered flows sent using multiple SSRCs, as
it allows the layered flow to react as a whole, ceasing transmission it allows the layered flow to react as a whole, ceasing transmission
on the enhancement layers first to reduce sending rate if necessary, on the enhancement layers first to reduce sending rate if necessary,
rather than treating each layer independently. 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 DSCP values [RFC7657],
[I-D.ietf-tsvwg-rtcweb-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 9. Security Considerations
The security considerations of [RFC3550] apply. The security considerations of [RFC3550] apply.
If the RTP/AVPF profile is used to provide rapid RTCP feedback, the If the RTP/AVPF profile is used to provide rapid RTCP feedback, the
security considerations of [RFC4585] apply. If ECN feedback for RTP security considerations of [RFC4585] apply. If ECN feedback for RTP
over UDP/IP is used, the security considerations of [RFC6679] apply. over UDP/IP is used, the security considerations of [RFC6679] apply.
If non-authenticated RTCP reports are used, an on-path attacker can If non-authenticated RTCP reports are used, an on-path attacker can
skipping to change at page 21, line 16 skipping to change at page 21, line 36
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<http://www.rfc-editor.org/info/rfc4585>. <http://www.rfc-editor.org/info/rfc4585>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008, RFC 5348, DOI 10.17487/RFC5348, September 2008,
<http://www.rfc-editor.org/info/rfc5348>. <http://www.rfc-editor.org/info/rfc5348>.
[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>.
12.2. Informative References 12.2. Informative References
[Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer, [Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer,
"Equation-Based Congestion Control for Unicast "Equation-Based Congestion Control for Unicast
Applications", Proceedings of the ACM SIGCOMM Applications", Proceedings of the ACM SIGCOMM
conference, 2000, DOI 10.1145/347059.347397, August 2000. conference, 2000, DOI 10.1145/347059.347397, August 2000.
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
December 2015. December 2015.
[I-D.ietf-tsvwg-circuit-breaker] [I-D.ietf-tsvwg-circuit-breaker]
Fairhurst, G., "Network Transport Circuit Breakers", Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-11 (work in progress), draft-ietf-tsvwg-circuit-breaker-13 (work in progress),
December 2015. February 2016.
[I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
and other packet markings for WebRTC QoS", draft-ietf-
tsvwg-rtcweb-qos-14 (work in progress), March 2016.
[Mathis] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The [Mathis] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The
macroscopic behavior of the TCP congestion avoidance macroscopic behavior of the TCP congestion avoidance
algorithm", ACM SIGCOMM Computer Communication algorithm", ACM SIGCOMM Computer Communication
Review 27(3), DOI 10.1145/263932.264023, July 1997. Review 27(3), DOI 10.1145/263932.264023, July 1997.
[Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, [Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose,
"Modeling TCP Throughput: A Simple Model and its Empirical "Modeling TCP Throughput: A Simple Model and its Empirical
Validation", Proceedings of the ACM SIGCOMM Validation", Proceedings of the ACM SIGCOMM
conference, 1998, DOI 10.1145/285237.285291, August 1998. conference, 1998, DOI 10.1145/285237.285291, August 1998.
skipping to change at page 22, line 37 skipping to change at page 23, line 18
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <http://www.rfc-editor.org/info/rfc5506>. 2009, <http://www.rfc-editor.org/info/rfc5506>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>. <http://www.rfc-editor.org/info/rfc5681>.
[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>.
[RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended [RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended
Report (XR) Block for Packet Delay Variation Metric Report (XR) Block for Packet Delay Variation Metric
Reporting", RFC 6798, DOI 10.17487/RFC6798, November 2012, Reporting", RFC 6798, DOI 10.17487/RFC6798, November 2012,
<http://www.rfc-editor.org/info/rfc6798>. <http://www.rfc-editor.org/info/rfc6798>.
[RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Delay Metric (RTCP) Extended Report (XR) Block for Delay Metric
Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013,
<http://www.rfc-editor.org/info/rfc6843>. <http://www.rfc-editor.org/info/rfc6843>.
skipping to change at page 23, line 30 skipping to change at page 24, line 5
[RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control [RFC7097] Ott, J., Singh, V., Ed., and I. Curcio, "RTP Control
Protocol (RTCP) Extended Report (XR) for RLE of Discarded Protocol (RTCP) Extended Report (XR) for RLE of Discarded
Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014, Packets", RFC 7097, DOI 10.17487/RFC7097, January 2014,
<http://www.rfc-editor.org/info/rfc7097>. <http://www.rfc-editor.org/info/rfc7097>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>. <http://www.rfc-editor.org/info/rfc7201>.
[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) [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
Concepts, Abstract Mechanism, and Requirements", RFC 7713, Concepts, Abstract Mechanism, and Requirements", RFC 7713,
DOI 10.17487/RFC7713, December 2015, DOI 10.17487/RFC7713, December 2015,
<http://www.rfc-editor.org/info/rfc7713>. <http://www.rfc-editor.org/info/rfc7713>.
[Sarker] Sarker, Z., Singh, V., and C. Perkins, "An Evaluation of [Sarker] Sarker, Z., Singh, V., and C. Perkins, "An Evaluation of
RTP Circuit Breaker Performance on LTE Networks", RTP Circuit Breaker Performance on LTE Networks",
Proceedings of the IEEE Infocom workshop on Communication Proceedings of the IEEE Infocom workshop on Communication
and Networking Techniques for Contemporary Video, 2014, and Networking Techniques for Contemporary Video, 2014,
April 2014. April 2014.
 End of changes. 18 change blocks. 
50 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/