draft-ietf-avtcore-rtp-circuit-breakers-11.txt   draft-ietf-avtcore-rtp-circuit-breakers-12.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 Aalto University Intended status: Standards Track callstats.io
Expires: April 18, 2016 October 16, 2015 Expires: August 12, 2016 February 9, 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-11 draft-ietf-avtcore-rtp-circuit-breakers-12
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 the applications, then network congestion will
deteriorate the user's multimedia experience. This document does not deteriorate the user's multimedia experience. This acts as a safety
propose a congestion control algorithm; instead, it defines a minimal measure to prevent starvation of network resources denying other
set of RTP circuit-breakers. Circuit-breakers are conditions under flows from access to the Internet, such measures are essential for an
which an RTP sender needs to stop transmitting media data in order to Internet that is heterogeneous and for traffic that is hard to
protect the network from excessive congestion. It is expected that, predict in advance. This document does not propose a congestion
in the absence of severe congestion, all RTP applications running on control algorithm; instead, it defines a minimal set of RTP circuit-
best-effort IP networks will be able to run without triggering these breakers. Circuit-breakers are conditions under which an RTP sender
circuit breakers. Any future RTP congestion control specification needs to stop transmitting media data in order to protect the network
will be expected to operate within the constraints defined by these from excessive congestion. It is expected that, in the absence of
circuit breakers. severe congestion, all RTP applications running on best-effort IP
networks will be able to run without triggering these circuit
breakers. Any future RTP congestion control specification 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 April 18, 2016. This Internet-Draft will expire on August 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . 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 . . . . . . . . . 11 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) . . . . . . 18
8. Impact of Bundled Media and Layered Coding . . . . . . . . . 18 8. Impact of Bundled Media and Layered Coding . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
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 These are conditions under which there is general agreement that an
RTP flow is causing serious congestion, and hence ought to cease RTP flow is causing serious congestion, and hence ought to cease
transmission. The RTP circuit breakers proposed in this memo are a transmission. The RTP circuit breakers proposed in this memo are a
specific instance of the general class of network transport circuit specific instance of the general class of network transport circuit
breakers [I-D.ietf-tsvwg-circuit-breaker], designed to act as a breakers [I-D.ietf-tsvwg-circuit-breaker], designed to act as a
protection mechanism of last resort to avoid persistent congestion. protection mechanism of last resort to avoid persistent excessive
It is expected that future standards-track congestion control congestion. It is expected that future standards-track congestion
algorithms for RTP will operate within the envelope defined by this control algorithms for RTP will operate within the envelope defined
memo. 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 matches the available network bandwidth. to one receiver, so that it does not use more capacity than is
Such adaptation needs to be done in a way that limits the disruption available along the network path. Such adaptation needs to be done
to the user experience caused by both packet loss and excessive rate in a way that limits the disruption to the user experience caused by
changes. Congestion control for multicast flows is outside the scope both packet loss and excessive rate changes. Congestion control for
of this memo. Multicast traffic needs different solutions, since the multicast flows is outside the scope of this memo. Multicast traffic
available bandwidth estimator for a group of receivers will differ needs different solutions, since the available capacity estimator for
from that for a single receiver, and because multicast congestion a group of receivers will differ from that for a single receiver, and
control has to consider issues of fairness across groups of receivers because multicast congestion control has to consider issues of
that do not apply to unicast flows. fairness across groups of receivers that do not apply to unicast
flows.
Congestion control for unicast RTP traffic can be implemented in one Congestion control for unicast RTP traffic can be implemented in one
of two places in the protocol stack. One approach is to run the RTP of two places in the protocol stack. One approach is to run the RTP
traffic over a congestion controlled transport protocol, for example traffic over a congestion controlled transport protocol, for example
over TCP, and to adapt the media encoding to match the dictates of over TCP, and to adapt the media encoding to match the dictates of
the transport-layer congestion control algorithm. This is safe for the transport-layer congestion control algorithm. This is safe for
the network, but can be suboptimal for the media quality unless the the network, but can be suboptimal for the media quality unless the
transport protocol is designed to support real-time media flows. We transport protocol is designed to support real-time media flows. We
do not consider this class of applications further in this memo, as do not consider this class of applications further in this memo, as
their network safety is guaranteed by the underlying transport. their network safety is guaranteed by the underlying transport.
Alternatively, RTP flows can be run over a non-congestion controlled Alternatively, RTP flows can be run over a non-congestion controlled
transport protocol, for example UDP, performing rate adaptation at transport protocol, for example UDP, performing rate adaptation at
the application layer based on RTP Control Protocol (RTCP) feedback. the application layer based on RTP Control Protocol (RTCP) feedback.
With a well-designed, network-aware, application, this allows highly With a well-designed, network-aware, application, this allows highly
effective media quality adaptation, but there is potential to disrupt effective media quality adaptation, but there is potential to cause
the network's operation if the application does not adapt its sending persistent congestion in the network if the application does not
rate in a timely and effective manner. We consider this class of adapt its sending rate in a timely and effective manner. We consider
applications in this memo. this class of applications in this memo.
Congestion control relies on monitoring the delivery of a media flow, Congestion control relies on monitoring the delivery of a media flow,
and responding to adapt the transmission of that flow when there are and responding to adapt the transmission of that flow when there are
signs that the network path is congested. Network congestion can be signs that the network path is congested. Network congestion can be
detected in one of three ways: 1) a receiver can infer the onset of detected in one of three ways: 1) a receiver can infer the onset of
congestion by observing an increase in one-way delay caused by queue congestion by observing an increase in one-way delay caused by queue
build-up within the network; 2) if Explicit Congestion Notification build-up within the network; 2) if Explicit Congestion Notification
(ECN) [RFC3168] is supported, the network can signal the presence of (ECN) [RFC3168] is supported, the network can signal the presence of
congestion by marking packets using ECN Congestion Experienced (CE) congestion by marking packets using ECN Congestion Experienced (CE)
marks; or 3) in the extreme case, congestion will cause packet loss marks; or 3) in the extreme case, congestion will cause packet loss
skipping to change at page 4, line 41 skipping to change at page 4, line 41
transmission. RTCP SR packets contain data that can be used to transmission. RTCP SR packets contain data that can be used to
reconstruct media timing at a receiver, along with a count of the reconstruct media timing at a receiver, along with a count of the
total number of octets and packets sent. RTCP RR packets report total number of octets and packets sent. RTCP RR packets report
on the fraction of packets lost in the last reporting interval, on the fraction of packets lost in the last reporting interval,
the cumulative number of packets lost, the highest sequence number the cumulative number of packets lost, the highest sequence number
received, and the inter-arrival jitter. The RTCP RR packets also received, and the inter-arrival jitter. The RTCP RR packets also
contain timing information that allows the sender to estimate the contain timing information that allows the sender to estimate the
network round trip time (RTT) to the receivers. RTCP reports are network round trip time (RTT) to the receivers. RTCP reports are
sent periodically, with the reporting interval being determined by sent periodically, with the reporting interval being determined by
the number of SSRCs used in the session and a configured session the number of SSRCs used in the session and a configured session
bandwidth estimate (the number of SSRCs used is usually two in a bandwidth estimate (the number of synchronisation sources (SSRCs)
unicast session, one for each participant, but can be greater if used is usually two in a unicast session, one for each
the participants send multiple media streams). The interval participant, but can be greater if the participants send multiple
between reports sent from each receiver tends to be on the order media streams). The interval between reports sent from each
of a few seconds on average, although it varies with the session receiver tends to be on the order of a few seconds on average,
bandwidth, and sub-second reporting intervals are possible in high although it varies with the session bandwidth, and sub-second
bandwidth sessions, and it is randomised to avoid synchronisation reporting intervals are possible in high bandwidth sessions, and
of reports from multiple receivers. RTCP RR packets allow a it is randomised to avoid synchronisation of reports from multiple
receiver to report ongoing network congestion to the sender. receivers. RTCP RR packets allow a receiver to report ongoing
However, if a receiver detects the onset of congestion part way network congestion to the sender. However, if a receiver detects
through a reporting interval, the base RTP specification contains the onset of congestion part way through a reporting interval, the
no provision for sending the RTCP RR packet early, and the base RTP specification contains no provision for sending the RTCP
receiver has to wait until the next scheduled reporting interval. RR packet early, and the receiver has to wait until the next
scheduled reporting interval.
o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more o The RTCP Extended Reports (XR) [RFC3611] allow reporting of more
complex and sophisticated reception quality metrics, but do not complex and sophisticated reception quality metrics, but do not
change the RTCP timing rules. RTCP extended reports of potential change the RTCP timing rules. RTCP extended reports of potential
interest for congestion control purposes are the extended packet interest for congestion control purposes are the extended packet
loss, discard, and burst metrics [RFC3611], [RFC7002], [RFC7097], loss, discard, and burst metrics [RFC3611], [RFC7002], [RFC7097],
[RFC7003], [RFC6958]; and the extended delay metrics [RFC6843], [RFC7003], [RFC6958]; and the extended delay metrics [RFC6843],
[RFC6798]. Other RTCP Extended Reports that could be helpful for [RFC6798]. Other RTCP Extended Reports that could be helpful for
congestion control purposes might be developed in future. congestion control purposes might be developed in future.
skipping to change at page 7, line 17 skipping to change at page 7, line 17
codec used by the sender can change its rate on each frame, G = 1; codec used by the sender can change its rate on each frame, G = 1;
otherwise G is set to the number of frames before the codec can otherwise G is set to the number of frames before the codec can
adjust to the new rate. For codecs that have the concept of a adjust to the new rate. For codecs that have the concept of a
group-of-pictures (GoP), G is likely the GoP length. group-of-pictures (GoP), G is likely the GoP length.
o T_rr_interval is the minimal interval between RTCP reports, as o T_rr_interval is the minimal interval between RTCP reports, as
defined in Section 3.4 of [RFC4585]; it is only meaningful for defined in Section 3.4 of [RFC4585]; it is only meaningful for
implementations of RTP/AVPF profile [RFC4585] or the RTP/SAVPF implementations of RTP/AVPF profile [RFC4585] or the RTP/SAVPF
profile [RFC5124]. profile [RFC5124].
o X is estimated throughput a TCP connection would achieve over a o X is the estimated throughput a TCP connection would achieve over
path, in bytes per second. a path, in bytes per second.
o s is the size of RTP packets being sent, in bytes. If the RTP o s is the size of RTP packets being sent, in bytes. If the RTP
packets being sent vary in size, then the average size over the packets being sent vary in size, then the average size over the
packet comprising the last 4 * G frames MUST be used (this is packet comprising the last 4 * G frames MUST be used (this is
intended to be comparable to the four loss intervals used in intended to be comparable to the four loss intervals used in
[RFC5348]). [RFC5348]).
o p is the loss event rate, between 0.0 and 1.0, that would be seen o p is the loss event rate, between 0.0 and 1.0, that would be seen
by a TCP connection over a particular path. When used in the RTP by a TCP connection over a particular path. When used in the RTP
congestion circuit breaker, this is approximated as described in congestion circuit breaker, this is approximated as described in
Section 4.3. Section 4.3.
o t_RTO is the retransmission timeout value that would be used by a o t_RTO is the retransmission timeout value that would be used by a
TCP connection over a particular path, in seconds. This MUST be TCP connection over a particular path, in seconds. This MUST be
approximated using t_RTO = 4 * Tr when used as part of the RTP approximated using t_RTO = 4 * Tr when used as part of the RTP
congestion circuit breaker. congestion circuit breaker.
o b is the number of packets that are acknowledged by a single TCP o b is the number of packets that are acknowledged by a single TCP
acknowledgement. Following [RFC3448], it is RECOMMENDED that the acknowledgement. Following [RFC5348], it is RECOMMENDED that the
value b = 1 is used as part of the RTP congestion circuit breaker. value b = 1 is used as part of the RTP congestion circuit breaker.
4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile
The feedback mechanisms defined in [RFC3550] and available under the The feedback mechanisms defined in [RFC3550] and available under the
RTP/AVP profile [RFC3551] are the minimum that can be assumed for a RTP/AVP profile [RFC3551] are the minimum that can be assumed for a
baseline circuit breaker mechanism that is suitable for all unicast baseline circuit breaker mechanism that is suitable for all unicast
applications of RTP. Accordingly, for an RTP circuit breaker to be applications of RTP. Accordingly, for an RTP circuit breaker to be
useful, it needs to be able to detect that an RTP flow is causing useful, it needs to be able to detect that an RTP flow is causing
excessive congestion using only basic RTCP features, without needing excessive congestion using only basic RTCP features, without needing
RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports. RTCP XR feedback or the RTP/AVPF profile for rapid RTCP reports.
RTCP is a fundamental part of the RTP protocol, and the mechanisms RTCP is a fundamental part of the RTP protocol, and the mechanisms
described here rely on the implementation of RTCP. Implementations described here rely on the implementation of RTCP. Implementations
that claim to support RTP, but that do not implement RTCP, cannot use that claim to support RTP, but that do not implement RTCP, will be
the circuit breaker mechanisms described in this memo. Such unable to use the circuit breaker mechanisms described in this memo.
implementations SHOULD NOT be used on networks that might be subject Such implementations SHOULD NOT be used on networks that might be
to congestion unless equivalent mechanisms are defined using some subject to congestion unless equivalent mechanisms are defined using
non-RTCP feedback channel to report congestion and signal circuit some non-RTCP feedback channel to report congestion and signal
breaker conditions. The RTCP timeout circuit breaker (Section 4.1) circuit breaker conditions.
will trigger if an implementation of this memo attempts to interwork
with an endpoint that does not support RTCP. Implementations that The RTCP timeout circuit breaker (Section 4.1) will trigger if an
sometimes need to interwork with endpoints that do not support RTCP implementation of this memo attempts to interwork with an endpoint
need to disable the RTP circuit breakers if they don't receive some that does not support RTCP. Implementations that sometimes need to
confirmation via signalling that the remote endpoint implements RTCP interwork with endpoints that do not support RTCP need to disable the
(the presence of an SDP "a=rtcp:" attribute in an answer might be RTP circuit breakers if they don't receive some confirmation via
such an indication). signalling that the remote endpoint implements RTCP (the presence of
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
congestion unless equivalent mechanisms are defined using some non-
RTCP feedback channel to report congestion and signal 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 synchronisation source (SSRC) SR/RR packets and are reported for each SSRC in the RTP session:
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
reporting interval. Due to the nature of the jitter calculation reporting interval. Due to the nature of the jitter calculation
([RFC3550], section 6.4.4), the jitter is only meaningful for RTP ([RFC3550], section 6.4.4), the jitter is only meaningful for RTP
flows that send a single data packet for each RTP timestamp value flows that send a single data packet for each RTP timestamp value
skipping to change at page 9, line 9 skipping to change at page 9, line 13
RTT estimate alone as an RTP circuit breaker. RTT estimate alone as an RTP circuit breaker.
Increased jitter can be a signal of transient network congestion, but Increased jitter can be a signal of transient network congestion, but
in the highly aggregated form reported in RTCP RR packets, it offers in the highly aggregated form reported in RTCP RR packets, it offers
insufficient information to estimate the extent or persistence of insufficient information to estimate the extent or persistence of
congestion. Jitter reports are a useful early warning of potential congestion. Jitter reports are a useful early warning of potential
network congestion, but provide an insufficiently strong signal to be network congestion, but provide an insufficiently strong signal to be
used as a circuit breaker. used as a circuit breaker.
The remaining congestion signals are the packet loss fraction and the The remaining congestion signals are the packet loss fraction and the
cumulative number of packets lost. If considered carefully, these cumulative number of packets lost. If considered carefully, and over
can be effective indicators that congestion is occurring in networks an appropriate time frame to distinguish transient problems from long
where packet loss is primarily due to queue overflows, although loss term issues [I-D.ietf-tsvwg-circuit-breaker], these can be effective
caused by non-congestive packet corruption can distort the result in indicators that persistent excessive congestion is occurring in
some networks. TCP congestion control [RFC5681] intentionally tries networks where packet loss is primarily due to queue overflows,
to fill the router queues, and uses the resulting packet loss as although loss caused by non-congestive packet corruption can distort
congestion feedback. An RTP flow competing with TCP traffic will the result in some networks. TCP congestion control [RFC5681]
therefore expect to see a non-zero packet loss fraction that has to intentionally tries to fill the router queues, and uses the resulting
be related to TCP dynamics to estimate available capacity. This packet loss as congestion feedback. An RTP flow competing with TCP
behaviour of TCP is reflected in the congestion circuit breaker traffic will therefore expect to see a non-zero packet loss fraction,
below, and will affect the design of any RTP congestion control and some variation in queuing latency, in normal operation when
protocol. sharing a path with other flows, that needs to be accounted for when
determining the circuit breaker threshold
[I-D.ietf-tsvwg-circuit-breaker]. This behaviour of TCP is reflected
in the congestion circuit breaker below, and will affect the design
of any RTP congestion control protocol.
Two packet loss regimes can be observed: 1) RTCP RR packets show a Two packet loss regimes can be observed: 1) RTCP RR packets show a
non-zero packet loss fraction, while the extended highest sequence non-zero packet loss fraction, while the extended highest sequence
number received continues to increment; and 2) RR packets show a loss number received continues to increment; and 2) RR packets show a loss
fraction of zero, but the extended highest sequence number received fraction of zero, but the extended highest sequence number received
does not increment even though the sender has been transmitting RTP does not increment even though the sender has been transmitting RTP
data packets. The former corresponds to the TCP congestion avoidance data packets. The former corresponds to the TCP congestion avoidance
state, and indicates a congested path that is still delivering data; state, and indicates a congested path that is still delivering data;
the latter corresponds to a TCP timeout, and is most likely due to a the latter corresponds to a TCP timeout, and is most likely due to a
path failure. A third condition is that data is being sent but no path failure. A third condition is that data is being sent but no
skipping to change at page 11, line 22 skipping to change at page 11, line 30
data packets arrive at the receiver, also leading to reports where data packets arrive at the receiver, also leading to reports where
the extended highest sequence number received is non-increasing. the extended highest sequence number received is non-increasing.
Both issues require the media timeout interval to be scaled relative Both issues require the media timeout interval to be scaled relative
to the threshold, k. to the threshold, k.
The media timeout RTP circuit breaker is therefore as follows. When The media timeout RTP circuit breaker is therefore as follows. When
starting sending, calculate MEDIA_TIMEOUT using: starting sending, calculate MEDIA_TIMEOUT using:
MEDIA_TIMEOUT = ceil(k * max(Tf, Tr, Tdr) / Tdr) MEDIA_TIMEOUT = ceil(k * max(Tf, Tr, Tdr) / Tdr)
When a sender receives an RTCP packet indicating that the media it's When a sender receives an RTCP packet that indicates reception of the
sending is being received, then it cancels the media timeout circuit media it has been sending, then it cancels the media timeout circuit
breaker. If it is still sending, then it MUST calculate a new value breaker. If it is still sending, then it MUST calculate a new value
for MEDIA_TIMEOUT, and set a new media timeout circuit breaker. for MEDIA_TIMEOUT, and set a new media timeout circuit breaker.
If a sender receives an RTCP packet indicating that its media was not If a sender receives an RTCP packet indicating that its media was not
received, it MUST calculate a new value for MEDIA_TIMEOUT. If the received, it MUST calculate a new value for MEDIA_TIMEOUT. If the
new value is larger than the previous, is replaces MEDIA_TIMEOUT with new value is larger than the previous, it replaces MEDIA_TIMEOUT with
the new value, extending the media timeout circuit breaker; otherwise the new value, extending the media timeout circuit breaker; otherwise
it keeps the original value of MEDIA_TIMEOUT. This process is known it keeps the original value of MEDIA_TIMEOUT. This process is known
as reconsidering the media timeout circuit breaker. as reconsidering the media timeout circuit breaker.
If MEDIA_TIMEOUT consecutive RTCP packets are received indicating If MEDIA_TIMEOUT consecutive RTCP packets are received indicating
that the media being sent was not received, and the media timeout that the media being sent was not received, and the media timeout
circuit breaker has not been cancelled, then the media timeout circuit breaker has not been cancelled, then the media timeout
circuit breaker triggers. When the media timeout circuit breaker circuit breaker triggers. When the media timeout circuit breaker
triggers, the sender SHOULD cease transmission (see Section 4.5). triggers, the sender SHOULD cease transmission (see Section 4.5).
skipping to change at page 12, line 10 skipping to change at page 12, line 18
RR packets show non-zero packet loss fraction and increasing extended RR packets show non-zero packet loss fraction and increasing extended
highest sequence number received, then those RTP data packets are highest sequence number received, then those RTP data packets are
arriving at the receiver, but some degree of congestion is occurring. arriving at the receiver, but some degree of congestion is occurring.
The RTP/AVP profile [RFC3551] states that: The RTP/AVP profile [RFC3551] states that:
If best-effort service is being used, RTP receivers SHOULD monitor If best-effort service is being used, RTP receivers SHOULD monitor
packet loss to ensure that the packet loss rate is within packet loss to ensure that the packet loss rate is within
acceptable parameters. Packet loss is considered acceptable if a acceptable parameters. Packet loss is considered acceptable if a
TCP flow across the same network path and experiencing the same TCP flow across the same network path and experiencing the same
network conditions would achieve an average throughput, measured network conditions would achieve an average throughput, measured
on a reasonable time scale, that is not less than the RTP flow is on a reasonable time scale, that is not less than the throughput
achieving. This condition can be satisfied by implementing the RTP flow is achieving. This condition can be satisfied by
congestion control mechanisms to adapt the transmission rate (or implementing congestion control mechanisms to adapt the
the number of layers subscribed for a layered multicast session), transmission rate (or the number of layers subscribed for a
or by arranging for a receiver to leave the session if the loss layered multicast session), or by arranging for a receiver to
rate is unacceptably high. leave the session if the loss rate is unacceptably high.
The comparison to TCP cannot be specified exactly, but is intended The comparison to TCP cannot be specified exactly, but is intended
as an "order-of-magnitude" comparison in time scale and as an "order-of-magnitude" comparison in time scale and
throughput. The time scale on which TCP throughput is measured is throughput. The time scale on which TCP throughput is measured is
the round-trip time of the connection. In essence, this the round-trip time of the connection. In essence, this
requirement states that it is not acceptable to deploy an requirement states that it is not acceptable to deploy an
application (using RTP or any other transport protocol) on the application (using RTP or any other transport protocol) on the
best-effort Internet which consumes bandwidth arbitrarily and does best-effort Internet which consumes bandwidth arbitrarily and does
not compete fairly with TCP within an order of magnitude. not compete fairly with TCP within an order of magnitude.
The phase "order of magnitude" in the above means within a factor of The phase "order of magnitude" in the above means within a factor of
ten, approximately. In order to implement this, it is necessary to ten, approximately. In order to implement this, it is necessary to
estimate the throughput a TCP connection would achieve over the path. estimate the throughput a bulk TCP connection would achieve over the
For a long-lived TCP Reno connection, it has been shown that the TCP path. For a long-lived TCP Reno connection, it has been shown that
throughput, X, in bytes per second, can be estimated using [Padhye]: the TCP throughput, X, in bytes per second, can be estimated using
[Padhye]:
s s
X = ------------------------------------------------------------- X = -------------------------------------------------------------
Tr*sqrt(2*b*p/3)+(t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p*p))) 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 This is the same approach to estimated TCP throughput that is used in
[RFC3448]. 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 throughout 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
skipping to change at page 15, line 43 skipping to change at page 15, line 51
priority SHOULD be given to reports on sources that have high packet priority SHOULD be given to reports on sources that have high packet
loss rates, to ensure that senders are aware of network congestion loss rates, to ensure that senders are aware of network congestion
they are causing (this is an update to [RFC3550]). they are causing (this is an update to [RFC3550]).
4.4. RTP/AVP Circuit Breaker #4: Media Usability 4.4. RTP/AVP Circuit Breaker #4: Media Usability
Applications that use RTP are generally tolerant to some amount of Applications that use RTP are generally tolerant to some amount of
packet loss. How much packet loss can be tolerated will depend on packet loss. How much packet loss can be tolerated will depend on
the application, media codec, and the amount of error correction and the application, media codec, and the amount of error correction and
packet loss concealment that is applied. There is an upper bound on packet loss concealment that is applied. There is an upper bound on
the amount of loss can be corrected, however, beyond which the media the amount of loss that can be corrected, however, beyond which the
becomes unusable. Similarly, many applications have some upper bound media becomes unusable. Similarly, many applications have some upper
on the media capture to play-out latency that can be tolerated before bound on the media capture to play-out latency that can be tolerated
the application becomes unusable. The latency bound will depend on before the application becomes unusable. The latency bound will
the application, but typical values can range from the order of a few depend on the application, but typical values can range from the
hundred milliseconds for voice telephony and interactive conferencing order of a few hundred milliseconds for voice telephony and
applications, up to several seconds for some video-on-demand systems. interactive conferencing applications, up to several seconds for some
video-on-demand systems.
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
skipping to change at page 16, line 25 skipping to change at page 16, line 32
time period is deemed significant, as these are highly application time period is deemed significant, as these are highly application
dependent. dependent.
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 that the RTP circuit breaker does not stop the flow, it is desirable to prevent
application cease sending useless traffic. The role of the media the application sending unnecessary traffic that might disrupt other
usability circuit breaker is to protect the network in such cases. uses of the network. The role of the media usability circuit breaker
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, but What it means to cease transmission depends on the application. The
the intention is that the application will stop sending RTP data intention is that the application will stop sending RTP data packets
packets to a particular destination 3-tuple (transport protocol, to a particular destination 3-tuple (transport protocol, destination
destination port, IP address), until the user makes an explicit port, IP address), until the user makes an explicit attempt to
attempt to restart the call. It is important that a human user is restart the call. It is important that a human user is involved in
involved in the decision to try to restart the call, since that user the decision to try to restart the call, since that user will
will eventually give up if the calls repeatedly trigger the circuit eventually give up if the calls 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. Accordingly, RTP flows halted by the
circuit breaker SHOULD NOT be restarted automatically unless the circuit breaker SHOULD NOT be restarted automatically unless the
sender has received information that the congestion has dissipated. sender has received information that the congestion has dissipated,
or can reasonably be expected to have dissipated. This is
necessarily application dependent, but could be, for example, an
indication that a competing flow has finished, freeing up some
capacity, or that the device has moved 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 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 SHOULD 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 previous restart a call to the same destination 3-tuple as used by a call that
call that was recently halted by the circuit breaker. The chosen triggered the circuit breaker, so that the reaction to a triggered
rate limit ought to not exceed the rate at which an annoyed human circuit breaker lasts for at least the triggering interval
caller might redial a misbehaving phone. [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
misbehaving phone.
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
skipping to change at page 17, line 44 skipping to change at page 18, line 10
rules that contain RTCP SR or RR packets MUST be processed by the rules that contain RTCP SR or RR packets MUST be processed by the
congestion circuit breaker as if they were sent as regular RTCP congestion circuit breaker as if they were sent as regular RTCP
reports, and counted towards the circuit breaker conditions specified reports, and counted towards the circuit breaker conditions specified
in Section 4 of this memo. This will potentially make the RTP in Section 4 of this memo. This will potentially make the RTP
circuit breaker trigger earlier than it would if the RTP/AVPF profile circuit breaker trigger earlier than it would if the RTP/AVPF profile
was not used. was not used.
When using ECN with RTP (see Section 7), early RTCP feedback packets When using ECN with RTP (see Section 7), early RTCP feedback packets
can contain ECN feedback reports. The count of ECN-CE marked packets can contain ECN feedback reports. The count of ECN-CE marked packets
contained in those ECN feedback reports is counted towards the number contained in those ECN feedback reports is counted towards the number
of lost packets reported if the ECN Feedback Report report is sent in of lost packets reported if the ECN Feedback Report is sent in a
an compound RTCP packet along with an RTCP SR/RR report packet. compound RTCP packet along with an RTCP SR/RR report packet. Reports
Reports of ECN-CE packets sent as reduced-size RTCP ECN feedback of ECN-CE packets sent as reduced-size RTCP ECN feedback packets
packets without an RTCP SR/RR packet MUST be ignored. without an RTCP SR/RR packet MUST be ignored.
These rules are intended to allow the use of low-overhead RTP/AVPF These rules are intended to allow the use of low-overhead RTP/AVPF
feedback for generic NACK messages without triggering the RTP circuit feedback for generic NACK messages without triggering the RTP circuit
breaker. This is expected to make such feedback suitable for RTP breaker. This is expected to make such feedback suitable for RTP
congestion control algorithms that need to quickly report loss events congestion control algorithms that need to quickly report loss events
in between regular RTCP reports. The reaction to reduced-size RTCP in between regular RTCP reports. The reaction to reduced-size RTCP
SR/RR packets is to allow such algorithms to send feedback that can SR/RR packets is to allow such algorithms to send feedback that can
trigger the circuit breaker, when desired. trigger the circuit breaker, when desired.
The RTP/AVPF and RTP/SAVPF profiles include the T_rr_interval The RTP/AVPF and RTP/SAVPF profiles include the T_rr_interval
parameter that can be used to adjust the regular RTCP reporting parameter that can be used to adjust the regular RTCP reporting
interval. The use of the T_rr_interval parameter changes the interval. The use of the T_rr_interval parameter changes the
behaviour of the RTP circuit breaker, as described in Section 4. behaviour of the RTP circuit breaker, as described in Section 4.
6. Impact of RTCP Extended Reports (XR) 6. Impact of RTCP Extended Reports (XR)
RTCP Extended Report (XR) blocks provide additional reception quality RTCP Extended Report (XR) blocks provide additional reception quality
metrics, but do not change the RTCP timing rules. Some of the RTCP metrics, but do not change the RTCP timing rules. Some of the RTCP
XR blocks provide information that might be useful for congestion XR blocks provide information that might be useful for congestion
control purposes, others provided 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 media timeout RTP
skipping to change at page 19, line 26 skipping to change at page 19, line 41
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
trivially generate fake RTCP packets that indicate high packet loss trivially generate fake RTCP packets that indicate high packet loss
rates, causing the circuit breaker to trigger and disrupting an RTP rates, causing the circuit breaker to trigger and disrupt an RTP
session. This is somewhat more difficult for an off-path attacker, 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 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 RTP sequence number. This attack can be avoided if RTCP packets are
authenticated; authentication options are discussed in [RFC7201]. authenticated; authentication options are discussed in [RFC7201].
Timely operation of the RTP circuit breaker depends on the choice of Timely operation of the RTP circuit breaker depends on the choice of
RTCP reporting interval. If the receiver has a reporting interval RTCP reporting interval. If the receiver has a reporting interval
that is overly long, then the responsiveness of the circuit breaker that is overly long, then the responsiveness of the circuit breaker
decreases. In the limit, the RTP circuit breaker can be disabled for decreases. In the limit, the RTP circuit breaker can be disabled for
all practical purposes by configuring an RTCP reporting interval that all practical purposes by configuring an RTCP reporting interval that
skipping to change at page 20, line 10 skipping to change at page 20, line 21
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,
Gorry Fairhurst, Nazila Fough, Kevin Gross, Cullen Jennings, Randell Gorry Fairhurst, Nazila Fough, Kevin Gross, Cullen Jennings, Randell
Jesup, Jonathan Lennox, Matt Mathis, Stephen McQuistin, Simon Jesup, Jonathan Lennox, Matt Mathis, Stephen McQuistin, Simon
Perreault, Eric Rescorla, Abheek Saha, Fabio Verdicchio, and Magnus Perreault, Eric Rescorla, Abheek Saha, Meral Shirazipour, Fabio
Westerlund for their 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>.
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, DOI 10.17487/RFC3448, January 2003,
<http://www.rfc-editor.org/info/rfc3448>.
[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,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>. <http://www.rfc-editor.org/info/rfc3551>.
skipping to change at page 20, line 48 skipping to change at page 21, line 11
"RTP Control Protocol Extended Reports (RTCP XR)", "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, DOI 10.17487/RFC3611, November 2003, RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>. <http://www.rfc-editor.org/info/rfc3611>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"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
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<http://www.rfc-editor.org/info/rfc5348>.
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, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-09 (work in progress), draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
September 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-05 (work in progress), draft-ietf-tsvwg-circuit-breaker-11 (work in progress),
October 2015. December 2015.
[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 5 skipping to change at page 22, line 19
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
February 2008, <http://www.rfc-editor.org/info/rfc5104>. February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>. 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<http://www.rfc-editor.org/info/rfc5348>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405, for Application Designers", BCP 145, RFC 5405,
DOI 10.17487/RFC5405, November 2008, DOI 10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>. <http://www.rfc-editor.org/info/rfc5405>.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009,
<http://www.rfc-editor.org/info/rfc5450>. <http://www.rfc-editor.org/info/rfc5450>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
skipping to change at page 23, line 40 skipping to change at page 24, line 4
Authors' Addresses Authors' Addresses
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Varun Singh Varun Singh
Aalto University Nemu Dialogue Systems Oy
School of Electrical Engineering Runeberginkatu 4c A 4
Otakaari 5 A Helsinki 00100
Espoo, FIN 02150
Finland Finland
Email: varun@comnet.tkk.fi Email: varun.singh@iki.fi
URI: http://www.netlab.tkk.fi/~varun/ URI: http://www.callstats.io/
 End of changes. 42 change blocks. 
145 lines changed or deleted 162 lines changed or added

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