draft-ietf-avtcore-rtp-circuit-breakers-15.txt   draft-ietf-avtcore-rtp-circuit-breakers-16.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: November 1, 2016 April 30, 2016 Expires: December 13, 2016 June 11, 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-15 draft-ietf-avtcore-rtp-circuit-breakers-16
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 these applications, then network congestion can is not implemented in these applications, then network congestion can
lead to uncontrolled packet loss, and a resulting deterioration of lead to uncontrolled packet loss, and a resulting deterioration of
the user's multimedia experience. The congestion control algorithm the user's multimedia experience. The congestion control algorithm
acts as a safety measure, stopping RTP flows from using excessive acts as a safety measure, stopping RTP flows from using excessive
skipping to change at page 1, line 32 skipping to change at page 1, line 32
this writing, however, while there are several proprietary solutions, this writing, however, while there are several proprietary solutions,
there is no standard algorithm for congestion control of interactive there is no standard algorithm for congestion control of interactive
RTP flows. RTP flows.
This document does not propose a congestion control algorithm. It This document does not propose a congestion control algorithm. It
instead defines a minimal set of RTP circuit breakers: conditions instead defines a minimal set of RTP circuit breakers: conditions
under which an RTP sender needs to stop transmitting media data, to under which an RTP sender needs to stop transmitting media data, to
protect the network from excessive congestion. It is expected that, protect the network from excessive congestion. It is expected that,
in the absence of long-lived excessive congestion, RTP applications in the absence of long-lived excessive congestion, RTP applications
running on best-effort IP networks will be able to operate without running on best-effort IP networks will be able to operate without
triggering these circuit breakers. Future RTP congestion control triggering these circuit breakers. To avoid triggering the RTP
specifications will be expected to operate within the constraints circuit breaker, any standards-track congestion control algorithms
defined by these circuit breakers. defined for RTP will need to operate within the envelope set by these
RTP circuit breaker algorithms.
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 November 1, 2016.
This Internet-Draft will expire on December 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 27 skipping to change at page 2, line 30
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . 10
4.2. RTP/AVP Circuit Breaker #2: Media Timeout . . . . . . . . 10 4.2. RTP/AVP Circuit Breaker #2: Media Timeout . . . . . . . . 11
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 . . . . . . . 16
4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 16 4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 17
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) . . . . . . . . . . . . 19
7. Impact of Explicit Congestion Notification (ECN) . . . . . . 19 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 . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 3, line 18 skipping to change at page 3, line 21
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:
mechanisms that terminate RTP flows in conditions under which there mechanisms that terminate RTP flows in conditions under which there
is general agreement that serious network congestion is occurring. is general agreement that serious network congestion is occurring.
The RTP circuit breakers proposed in this memo are a specific The RTP circuit breakers proposed in this memo are a specific
instance of the general class of network transport circuit breakers instance of the general class of network transport circuit breakers
[I-D.ietf-tsvwg-circuit-breaker], designed to act as a protection [I-D.ietf-tsvwg-circuit-breaker], designed to act as a protection
mechanism of last resort to avoid persistent excessive congestion. mechanism of last resort to avoid persistent excessive congestion.
It is expected that future standards-track congestion control To avoid triggering the RTP circuit breaker, any standards-track
algorithms for RTP will operate within the envelope defined by this congestion control algorithms defined for RTP will need to operate
memo. within the envelope set by the RTP circuit breaker algorithms defined
by this 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 15, line 20 skipping to change at page 15, line 29
it MAY first reduce its sending rate by this factor (or some larger 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 amount) to see if that resolves the congestion. If the sending rate
is reduced in this way and the congestion circuit breaker triggers is reduced in this way and the congestion circuit breaker triggers
again after the next CB_INTERVAL RTCP reporting intervals, the sender again after the next CB_INTERVAL RTCP reporting intervals, the sender
MUST then cease transmission. An example of such a rate reduction MUST then cease transmission. An example of such a rate reduction
might be a video conferencing system that backs off to sending audio might be a video conferencing system that backs off to sending audio
only, before completely dropping the call. If such a reduction in only, before completely dropping the call. If such a reduction in
sending rate resolves the congestion problem, the sender MAY sending rate resolves the congestion problem, the sender MAY
gradually increase the rate at which it sends data after a reasonable 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 amount of time has passed, provided it takes care not to cause the
problem to recur ("reasonable" is intentionally not defined here). problem to recur ("reasonable" is intentionally not defined here,
since it depends on the application, media codec, and congestion
control algorithm).
The RTCP reporting interval of the media sender does not affect how The RTCP reporting interval of the media sender does not affect how
quickly congestion circuit breaker can trigger. The timing is based quickly congestion circuit breaker can trigger. The timing is based
on the RTCP reporting interval of the receiver that generates the SR/ on the RTCP reporting interval of the receiver that generates the SR/
RR packets from which the loss rate and RTT estimate are derived RR packets from which the loss rate and RTT estimate are derived
(note that RTCP requires all participants in a session to have (note that RTCP requires all participants in a session to have
similar reporting intervals, else the participant timeout rules in similar reporting intervals, else the participant timeout rules in
[RFC3550] will not work, so this interval is likely similar to that [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 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 reduced minimum RTCP reporting interval (as specified in Section 6.2
skipping to change at page 16, line 42 skipping to change at page 17, line 9
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
uses of the network. The role of the media usability circuit breaker uses of the network. The role of the media usability circuit breaker
is to protect the network in such cases. is to protect the network in such cases.
4.5. Ceasing Transmission 4.5. Ceasing Transmission
What it means to cease transmission depends on the application. The What it means to cease transmission depends on the application. The
intention is that the application will stop sending RTP data packets intention is that the application will stop sending RTP data packets
to a particular destination 3-tuple (transport protocol, destination on a particular 5-tuple (transport protocol, source and destination
port, IP address), until the user makes an explicit attempt to ports, source and destination IP addresses), until whatever network
restart the call. It is important that a human user is involved in problem that triggered the RTP circuit breaker has dissipated. This
the decision to try to restart the call, since that user will could mean stopping a single RTP flow, or it could mean that multiple
eventually give up if the calls repeatedly trigger the circuit bundled RTP flows are stopped. 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,
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 breaker. This will help avoid problems with automatic redial systems
from congesting the network. Accordingly, RTP flows halted by the from congesting the network.
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 that is running on a
mobile device -- that the device moved to a new location so the flow
would traverse a different path if restarted.
It is recognised that the RTP implementation in some systems might It is recognised that the RTP implementation in some systems might
not be able to determine if a call set-up request was initiated by a not be able to determine if a flow 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 flow on the same 5-tuple as used by a flow that triggered
triggered the circuit breaker, so that the reaction to a triggered the circuit breaker, so that the reaction to a triggered circuit
circuit breaker lasts for at least the triggering interval 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].
exceed the rate at which an annoyed human caller might redial a
misbehaving phone.
The RTP circuit breaker will only trigger, and cease transmission, The RTP circuit breaker will only trigger, and cease transmission,
for media flows subject to long-term persistent congestion. Such for media flows subject to long-term persistent congestion. Such
flows are likely to have poor quality and usability for some time flows are likely to have poor quality and usability for some time
before the circuit breaker triggers. Implementations can monitor before the circuit breaker triggers. Implementations can monitor
RTCP Reception Report blocks being returned for their media flows, RTCP Reception Report blocks being returned for their media flows,
and might find it beneficial to use this information to provide a and might find it beneficial to use this information to provide a
user interface cue that problems are occurring, in advance of the user interface cue that problems are occurring, in advance of the
circuit breaker triggering. circuit breaker triggering.
skipping to change at page 19, line 7 skipping to change at page 19, line 20
control purposes, others provide non-congestion-related metrics. control purposes, others provide non-congestion-related metrics.
With the exception of RTCP XR ECN Summary Reports (see Section 7), 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 the presence of RTCP XR blocks in a compound RTCP packet does not
affect the RTP circuit breaker algorithm. For consistency and ease affect the RTP circuit breaker algorithm. For consistency and ease
of implementation, only the reception report blocks contained in RTCP of implementation, only the reception report blocks contained in RTCP
SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets, SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets,
are used by the RTP circuit breaker algorithm. are used by the RTP circuit breaker algorithm.
7. Impact of Explicit Congestion Notification (ECN) 7. Impact of Explicit Congestion Notification (ECN)
The use of ECN for RTP flows does not affect the media timeout RTP The use of ECN for RTP flows does not affect the RTCP timeout circuit
circuit breaker (Section 4.2) or the RTCP timeout circuit breaker breaker (Section 4.1) or the media timeout circuit breaker
(Section 4.1), since these are both connectivity checks that simply (Section 4.2), since these are both connectivity checks that simply
determinate if any packets are being received. determinate if any packets are being received.
ECN-CE marked packets SHOULD be treated as if they were lost for the There is no consensus on what would be the correct response of the
purposes of congestion control, when determining the optimal media congestion circuit breaker (Section 4.3) to ECN-CE marked packets.
sending rate for an RTP flow. If an RTP sender has negotiated ECN The guidelines in [RFC3168] and [RFC6679] are that the response to
support for an RTP session, and has successfully initiated ECN use on receipt of an ECN-CE marked packet needs to be essentially the same
the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD as the response to a lost packet for congestion control purposes.
be treated as if they were lost when calculating if the congestion- Since the RTP congestion circuit breaker responds to the same
based RTP circuit breaker (Section 4.3) has been met, unless the RTP congestion signals, this suggests that it ought to consider ECN-CE
implementation can determine that the ECN-CE marking on this path is marked packets as lost packets when calculating the TCP throughput
not reliable. The count of ECN-CE marked RTP packets is returned in estimate to determine if the congestion circuit breaker triggers.
RTCP XR ECN summary report packets if support for ECN has been
initiated for an RTP session. More recent work, however, has suggested that the response to an ECN-
CE mark ought to be less severe than the response to packet loss.
For example, the TCP ABE proposal
[I-D.khademi-tcpm-alternativebackoff-ecn] makes the argument that TCP
congestion control ought to back-off less in response to an ECN-CE
mark than to packet loss, because networks that generate ECN-CE marks
tend to use AQM schemes with much smaller buffers. For RTP
congestion control, both NADA [I-D.ietf-rmcat-nada] and SCREAM
[I-D.ietf-rmcat-scream-cc] suggest responding differently to ECN-CE
marked packets than to lost packets, for quality of experience
reasons, but make different proposals for how the response ought to
change. Such proposals would imply that a different circuit breaker
threshold be used for congestion signalled by ECN-CE marks than for
congestion signalled by packet loss, but unfortunately they offer no
clear guidance on how the threshold ought to be changed.
Finally, there are suggestions that forthcoming AQM proposals
[I-D.briscoe-aqm-dualq-coupled] might mark packets with ECN-CE in a
significantly more aggressive manner that at present. Any such
deployment would likely be incompatible with deployed TCP
implementations, so is not a short-term issue, but would require
significant changes to the congestion circuit breaker response.
Given the above issues, implementations MAY ignore ECN-CE marks when
determining if the congestion circuit breaker triggers, since
excessive persistent congestion will eventually lead to packet loss
that will trigger the circuit breaker. Doing this will protect the
network from congestion collapse, but might result in sub-optimal
user experience for competing flows that share the bottleneck queue,
since that queue will be driven to overflow, inducing high latency.
If this is a concern, the only current guidance is for
implementations to treat ECN-CE marked packets as equivalent to lost
packets, whilst being aware that this might trigger the circuit
breaker prematurely in future, depending on how AQM and ECN
deployment evolves. Developers that implement a circuit breaker
based on ECN-CE marks will need to track future developments in AQM
standards and deployed ECN marking behaviour, and ensure their
implementations are updated to match.
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
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 8. Impact of Bundled Media and Layered Coding
The RTP circuit breaker operates on a per-RTP session basis. An RTP The RTP circuit breaker operates on a per-RTP session basis. An RTP
sender that participates in several RTP sessions MUST treat each RTP sender that participates in several RTP sessions MUST treat each RTP
session independently with regards to the RTP circuit breaker. session independently with regards to the RTP circuit breaker.
An RTP sender can generate several media streams within a single RTP An RTP sender can generate several media streams within a single RTP
session, with each stream using a different SSRC. This can happen if session, with each stream using a different SSRC. This can happen if
bundled media are in use, when using simulcast, or when using layered bundled media are in use, when using simulcast, or when using layered
skipping to change at page 20, line 40 skipping to change at page 21, line 46
RTCP reporting interval they are willing to negotiate (based on the RTCP reporting interval they are willing to negotiate (based on the
session bandwidth and RTCP bandwidth fraction) when using the RTP session bandwidth and RTCP bandwidth fraction) when using the RTP
circuit breaker, as discussed in Section 4.3. circuit breaker, as discussed in Section 4.3.
10. IANA Considerations 10. IANA Considerations
There are no actions for IANA. There are no actions for IANA.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Bernard Aboba, Harald Alvestrand, The authors would like to thank Bernard Aboba, Harald Alvestrand, Ben
Spencer Dawkins, Gorry Fairhurst, Nazila Fough, Kevin Gross, Cullen Campbell, Alissa Cooper, Spencer Dawkins, Gorry Fairhurst, Stephen
Jennings, Randell Jesup, Jonathan Lennox, Matt Mathis, Stephen Farrell, Nazila Fough, Kevin Gross, Cullen Jennings, Randell Jesup,
McQuistin, Simon Perreault, Eric Rescorla, Abheek Saha, Meral Mirja Kuehlewind, Jonathan Lennox, Matt Mathis, Stephen McQuistin,
Shirazipour, Fabio Verdicchio, and Magnus Westerlund for their Simon Perreault, Eric Rescorla, Abheek Saha, Meral Shirazipour, Fabio
valuable feedback. Verdicchio, and Magnus Westerlund for their valuable feedback.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
skipping to change at page 22, line 5 skipping to change at page 23, line 5
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>. 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.briscoe-aqm-dualq-coupled]
Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang,
"DualQ Coupled AQM for Low Latency, Low Loss and Scalable
Throughput", draft-briscoe-aqm-dualq-coupled-01 (work in
progress), March 2016.
[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-rmcat-nada]
Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu,
J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified
Congestion Control Scheme for Real-Time Media", draft-
ietf-rmcat-nada-02 (work in progress), March 2016.
[I-D.ietf-rmcat-scream-cc]
Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation
for Multimedia", draft-ietf-rmcat-scream-cc-04 (work in
progress), June 2016.
[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-15 (work in progress), draft-ietf-tsvwg-circuit-breaker-15 (work in progress),
April 2016. April 2016.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
and other packet markings for WebRTC QoS", draft-ietf- Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
tsvwg-rtcweb-qos-15 (work in progress), March 2016. qos-17 (work in progress), May 2016.
[I-D.khademi-tcpm-alternativebackoff-ecn]
Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", draft-khademi-
tcpm-alternativebackoff-ecn-00 (work in progress), May
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.
 End of changes. 21 change blocks. 
66 lines changed or deleted 139 lines changed or added

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