draft-ietf-avtcore-rtp-circuit-breakers-00.txt | draft-ietf-avtcore-rtp-circuit-breakers-01.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Standards Track V. Singh | Intended status: Standards Track V. Singh | |||
Expires: April 15, 2013 Aalto University | Expires: April 25, 2013 Aalto University | |||
October 12, 2012 | October 22, 2012 | |||
RTP Congestion Control: Circuit Breakers for Unicast Sessions | RTP Congestion Control: Circuit Breakers for Unicast Sessions | |||
draft-ietf-avtcore-rtp-circuit-breakers-00 | draft-ietf-avtcore-rtp-circuit-breakers-01 | |||
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 document does not | |||
propose a congestion control algorithm; rather, it defines a minimal | propose a congestion control algorithm; rather, it defines a minimal | |||
set of "circuit-breakers". Circuit-breakers are conditions under | set of "circuit-breakers". Circuit-breakers are conditions under | |||
which an RTP flow is expected to stop transmiting media to protect | which an RTP flow is expected to stop transmitting media to protect | |||
the network from excessive congestion. It is expected that all RTP | the network from excessive congestion. It is expected that all RTP | |||
applications running on best-effort networks will be able to run | applications running on best-effort networks will be able to run | |||
without triggering these circuit breakers in normal operation. Any | without triggering these circuit breakers in normal operation. Any | |||
future RTP congestion control specification is expected to operate | future RTP congestion control specification is expected to operate | |||
within the envelope defined by these circuit breakers. | within the envelope 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. | |||
skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
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 15, 2013. | This Internet-Draft will expire on April 25, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 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 21 ¶ | skipping to change at page 2, line 21 ¶ | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . . 6 | 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . . 6 | |||
4.1. RTP/AVP Circuit Breaker #1: Timeout . . . . . . . . . . . 7 | 4.1. RTP/AVP Circuit Breaker #1: Media Timeout . . . . . . . . 7 | |||
4.2. RTP/AVP Circuit Breaker #2: Congestion . . . . . . . . . . 8 | 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout . . . . . . . . . 8 | |||
5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 10 | 4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . . 9 | |||
6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 11 | 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 11 | |||
7. Impact of Explicit Congestion Notification (ECN) . . . . . . . 11 | 6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. Session Timeout . . . . . . . . . . . . . . . . . . . . . . . 11 | 7. Impact of Explicit Congestion Notification (ECN) . . . . . . . 12 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
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 43 ¶ | skipping to change at page 3, line 43 ¶ | |||
interpreted as carrying special significance in this memo. | interpreted as carrying special significance in this memo. | |||
3. Background | 3. 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 matches the available network bandwidth. | |||
Such adaptation needs to be done in a way that limits the disruption | Such adaptation needs to be done in a way that limits the disruption | |||
to the user experience caused by both packet loss and excessive rate | to the user experience caused by both packet loss and excessive rate | |||
changes. | changes. Congestion control for multicast flows is outside the scope | |||
of this memo. | ||||
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. | |||
skipping to change at page 5, line 15 ¶ | skipping to change at page 5, line 16 ¶ | |||
network congestion to the sender. However, if a receiver detects | network congestion to the sender. However, if a receiver detects | |||
the onset of congestion partway through a reporting interval, the | the onset of congestion partway through a reporting interval, the | |||
base RTP specification contains no provision for sending the RTCP | base RTP specification contains no provision for sending the RTCP | |||
RR packet early, and the receiver has to wait until the next | RR packet early, and the receiver has to wait until the next | |||
scheduled reporting interval. | 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], and | loss, discard, and burst metrics [RFC3611], | |||
[I-D.ietf-xrblock-rtcp-xr-discard], | [I-D.ietf-xrblock-rtcp-xr-discard], | |||
[I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics], | [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics], | |||
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], | [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard], | |||
[I-D.ietf-xrblock-rtcp-xr-burst-gap-loss]; and the extended delay | [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss]; and the extended delay | |||
metrics [I-D.ietf-xrblock-rtcp-xr-delay], | metrics [I-D.ietf-xrblock-rtcp-xr-delay], | |||
[I-D.ietf-xrblock-rtcp-xr-pdv]. Other RTCP Extended Reports that | [I-D.ietf-xrblock-rtcp-xr-pdv]. Other RTCP Extended Reports that | |||
could be helpful for congestion control purposes might be | could be helpful for congestion control purposes might be | |||
developed in future. | developed in future. | |||
o Rapid feedback about the occurrence of congestion events can be | o Rapid feedback about the occurrence of congestion events can be | |||
skipping to change at page 5, line 41 ¶ | skipping to change at page 5, line 42 ¶ | |||
defines new transport-layer feedback messages, including negative | defines new transport-layer feedback messages, including negative | |||
acknowledgements (NACKs), that can be used to report on specific | acknowledgements (NACKs), that can be used to report on specific | |||
congestion events. The use of the RTP/AVPF profile is dependent | congestion events. The use of the RTP/AVPF profile is dependent | |||
on signalling, but is otherwise generally backwards compatible, as | on signalling, but is otherwise generally backwards compatible, as | |||
it keeps the same average RTCP reporting interval as the base RTP | it keeps the same average RTCP reporting interval as the base RTP | |||
specification. The RTP Codec Control Messages [RFC5104] extend | specification. The RTP Codec Control Messages [RFC5104] extend | |||
the RTP/AVPF profile with additional feedback messages that can be | the RTP/AVPF profile with additional feedback messages that can be | |||
used to influence that way in which rate adaptation occurs. The | used to influence that way in which rate adaptation occurs. The | |||
dynamics of how rapidly feedback can be sent are unchanged. | dynamics of how rapidly feedback can be sent are unchanged. | |||
o Finally, the RTP and RTCP extensions for Explicit Congestion | o Finally, Explicit Congestion Notification (ECN) for RTP over UDP | |||
Notification (ECN) [I-D.ietf-avtcore-ecn-for-rtp] can be used to | [RFC6679] can be used to provide feedback on the number of packets | |||
provide feedback on the number of packets that received an ECN | that received an ECN Congestion Experienced (CE) mark. This RTCP | |||
Congestion Experienced (CE) mark. This extension builds on the | extension builds on the RTP/AVPF profile to allow rapid congestion | |||
RTP/AVPF profile to allow rapid congestion feedback when ECN is | feedback when ECN is supported. | |||
supported. | ||||
In addition to these mechanisms for providing feedback, the sender | In addition to these mechanisms for providing feedback, the sender | |||
can include an RTP header extension in each packet to record packet | can include an RTP header extension in each packet to record packet | |||
transmission times. There are two methods: [RFC5450] represents the | transmission times. There are two methods: [RFC5450] represents the | |||
transmission time in terms of a time-offset from the RTP timestamp of | transmission time in terms of a time-offset from the RTP timestamp of | |||
the packet, while [RFC6051] includes an explicit NTP-format sending | the packet, while [RFC6051] includes an explicit NTP-format sending | |||
timestamp (potentially more accurate, but a higher header overhead). | timestamp (potentially more accurate, but a higher header overhead). | |||
Accurate sending timestamps can be helpful for estimating queuing | Accurate sending timestamps can be helpful for estimating queuing | |||
delays, to get an early indication of the onset of congestion. | delays, to get an early indication of the onset of congestion. | |||
Taken together, these various mechanisms allow receivers to provide | Taken together, these various mechanisms allow receivers to provide | |||
feedback on the senders when congestion events occur, with varying | feedback on the senders when congestion events occur, with varying | |||
degrees of timeliness and accuracy. The key distinction is between | degrees of timeliness and accuracy. The key distinction is between | |||
systems that use only the basic RTCP mechanisms, without RTP/AVPF | systems that use only the basic RTCP mechanisms, without RTP/AVPF | |||
rapid feedback, and those that use the RTP/AVPF extensions and so can | rapid feedback, and those that use the RTP/AVPF extensions to respond | |||
respond to congestion more rapidly. | to congestion more rapidly. | |||
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. | |||
skipping to change at page 7, line 8 ¶ | skipping to change at page 7, line 8 ¶ | |||
These congestion signals limit the possible circuit breakers, since | These congestion signals limit the possible circuit breakers, since | |||
they give only limited visibility into the behaviour of the network. | they give only limited visibility into the behaviour of the network. | |||
RTT estimates are widely used in congestion control algorithms, as a | RTT estimates are widely used in congestion control algorithms, as a | |||
proxy for queuing delay measures in delay-based congestion control or | proxy for queuing delay measures in delay-based congestion control or | |||
to determine connection timeouts. RTT estimates derived from RTCP SR | to determine connection timeouts. RTT estimates derived from RTCP SR | |||
and RR packets sent according to the RTP/AVP timing rules are far too | and RR packets sent according to the RTP/AVP timing rules are far too | |||
infrequent to be useful though, and don't give enough information to | infrequent to be useful though, and don't give enough information to | |||
distinguish a delay change due to routing updates from queuing delay | distinguish a delay change due to routing updates from queuing delay | |||
caused by congestion. Accordingly, we do not use the RTT estimate | caused by congestion. Accordingly, we cannot use the RTT estimate | |||
alone as an RTP circuit breaker. | 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 | |||
skipping to change at page 7, line 34 ¶ | skipping to change at page 7, line 34 ¶ | |||
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. We derive circuit breaker conditions for these two | path failure. We derive circuit breaker conditions for these two | |||
loss regimes. | loss regimes in the following. | |||
4.1. RTP/AVP Circuit Breaker #1: Timeout | 4.1. RTP/AVP Circuit Breaker #1: Media Timeout | |||
If RTP data packets are being sent while the corresponding RTCP RR | If RTP data packets are being sent while the corresponding RTCP RR | |||
packets report a non-increasing extended highest sequence number | packets report a non-increasing extended highest sequence number | |||
received, this is an indication that those RTP data packets are not | received, this is an indication that those RTP data packets are not | |||
reaching the receiver. This could be a short-term issue affecting | reaching the receiver. This could be a short-term issue affecting | |||
only a few packets, perhaps caused by a slow-to-open firewall or a | only a few packets, perhaps caused by a slow-to-open firewall or a | |||
transient connectivity problem, but if the issue persists, it is a | transient connectivity problem, but if the issue persists, it is a | |||
sign of a more ongoing and significant problem. Accordingly, if a | sign of a more ongoing and significant problem. Accordingly, if a | |||
sender of RTP data packets receives two or more consecutive RTCP RR | sender of RTP data packets receives two or more consecutive RTCP RR | |||
packets from the same receiver that correspond to its transmission, | packets from the same receiver that correspond to its transmission, | |||
and have a non-increasing extended highest sequence number received | and have a non-increasing extended highest sequence number received | |||
field (i.e., at least three RTCP RR packets that report the same | field (i.e., at least three RTCP RR packets that report the same | |||
value in the extended highest sequence number received field, when | value in the extended highest sequence number received field, when | |||
the sender has sent data packets that would have caused an increase | the sender has sent data packets that would have caused an increase | |||
in the reported value of the extended highest sequence number | in the reported value of the extended highest sequence number | |||
received if they had reached the receiver), then that sender SHOULD | received if they had reached the receiver), then that sender SHOULD | |||
cease transmission. | cease transmission. What it means to cease transmission depends on | |||
the application, but the intention is that the application will stop | ||||
sending RTP data packets until the user makes an explicit attempt to | ||||
restart the call (RTP flows halted by the circuit breaker SHOULD NOT | ||||
be restarted automatically unless the sender has received information | ||||
that the congestion has dissipated). | ||||
Systems that usually send at a high data rate, but which can reduce | Systems that usually send at a high data rate, but that can reduce | |||
their data rate significantly (i.e., by at least a factor of ten), | their data rate significantly (i.e., by at least a factor of ten), | |||
MAY first reduce their sending rate to this lower value to see if | MAY first reduce their sending rate to this lower value to see if | |||
this resolves the congestion, but MUST then cease transmission if the | this resolves the congestion, but MUST then cease transmission if the | |||
problem does not resolve itself within a further two RTCP reporting | problem does not resolve itself within a further two RTCP reporting | |||
intervals. An example of this might be a video conferencing system | intervals. An example of this might be a video conferencing system | |||
that backs off to sending audio only, before completely dropping the | that backs off to sending audio only, before completely dropping the | |||
call. If such a reduction in sending rate resolves the congestion | call. If such a reduction in sending rate resolves the congestion | |||
problem, the sender MAY gradually increase the rate at which it sends | problem, the sender MAY gradually increase the rate at which it sends | |||
data after a reasonable amount of time has passed, provided it takes | data after a reasonable amount of time has passed, provided it takes | |||
care not to cause the problem to recur ("reasonable" is intentionally | care not to cause the problem to recur ("reasonable" is intentionally | |||
skipping to change at page 8, line 29 ¶ | skipping to change at page 8, line 34 ¶ | |||
The choice of two RTCP reporting intervals is to give enough time for | The choice of two RTCP reporting intervals is to give enough time for | |||
transient problems to resolve themselves, but to stop problem flows | transient problems to resolve themselves, but to stop problem flows | |||
quickly enough to avoid causing serious ongoing network congestion. | quickly enough to avoid causing serious ongoing network congestion. | |||
A single RTCP report showing no reception could be caused by numerous | A single RTCP report showing no reception could be caused by numerous | |||
transient faults, and so will not cease transmission. Waiting for | transient faults, and so will not cease transmission. Waiting for | |||
more than two RTCP reports before stopping a flow might avoid some | more than two RTCP reports before stopping a flow might avoid some | |||
false positives, but would lead to problematic flows running for a | false positives, but would lead to problematic flows running for a | |||
long time before being cut off. | long time before being cut off. | |||
4.2. RTP/AVP Circuit Breaker #2: Congestion | 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout | |||
In addition to media timeouts, as were discussed in Section 4.1, an | ||||
RTP session has the possibility of an RTCP timeout. This can occur | ||||
when RTP data packets are being sent, but there are no RTCP reports | ||||
returned from the receiver. This is either due to a failure of the | ||||
receiver to send RTCP reports, or a failure of the return path that | ||||
is preventing those RTCP reporting from being delivered. | ||||
According to RFC 3550 [RFC3550], any participant that has not sent an | ||||
RTCP packet within the last two RTCP intervals is removed from the | ||||
sender list. Therefore, an RTP sender SHOULD cease transmission if | ||||
it does not receive a single RTCP RR packet and during this period | ||||
has sent 3 RTCP SR packets to the RTP receiver. Similarly, the same | ||||
circuit breaker rule applies to an RTCP receiver which has not | ||||
received a single SR packet, and in the corresponding period it has | ||||
sent 3 RTCP RR packets. What it means to cease transmission depends | ||||
on the application, but the intention is that the application will | ||||
stop sending RTP data packets until the user makes an explicit | ||||
attempt to restart the call (RTP flows halted by the circuit breaker | ||||
SHOULD NOT be restarted automatically unless the sender has received | ||||
information that the congestion has dissipated). | ||||
4.3. RTP/AVP Circuit Breaker #3: Congestion | ||||
If RTP data packets are being sent, and the corresponding RTCP RR | If RTP data packets are being sent, and the corresponding RTCP RR | |||
packets show non-zero packet loss fraction and increasing extended | packets show non-zero packet loss fraction and increasing extended | |||
highest sequence number received, then the 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 timescale, that is not less than the RTP flow is | on a reasonable time scale, that is not less than the RTP flow is | |||
achieving. This condition can be satisfied by implementing | achieving. This condition can be satisfied by implementing | |||
congestion control mechanisms to adapt the transmission rate (or | congestion control mechanisms to adapt the transmission rate (or | |||
the number of layers subscribed for a layered multicast session), | the number of layers subscribed for a layered multicast session), | |||
or by arranging for a receiver to leave the session if the loss | or by arranging for a receiver to leave the session if the loss | |||
rate is unacceptably high. | 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 timescale and throughput. | as an "order-of-magnitude" comparison in time scale and | |||
The timescale on which TCP throughput is measured is the round- | throughput. The time scale on which TCP throughput is measured is | |||
trip time of the connection. In essence, this requirement states | the round-trip time of the connection. In essence, this | |||
that it is not acceptable to deploy an application (using RTP or | requirement states that it is not acceptable to deploy an | |||
any other transport protocol) on the best-effort Internet which | application (using RTP or any other transport protocol) on the | |||
consumes bandwidth arbitrarily and does not compete fairly with | best-effort Internet which consumes bandwidth arbitrarily and does | |||
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 a factor of ten). | ||||
The throughput of a long-lived TCP connection can be estimated using | The phase "order of magnitude" in the above means within a factor of | |||
the TCP throughput equation: | ten, approximately. In order to implement this, it is necessary to | |||
estimate the throughput a TCP connection would achieve over the path. | ||||
For a long-lived TCP Reno connection, Padhye et al. [Padhye] showed | ||||
that the throughput can be estimated using the following equation: | ||||
s | s | |||
X = -------------------------------------------------------------- | X = -------------------------------------------------------------- | |||
R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) | R*sqrt(2*b*p/3) + (t_RTO * (3*sqrt(3*b*p/8) * p * (1+32*p^2))) | |||
Where: | where: | |||
X is the transmit rate in bytes/second. | X is the transmit rate in bytes/second. | |||
s is the packet size in bytes. If the RTP data packets vary in | s is the packet size in bytes. If data packets vary in size, then | |||
size, then the average size is to be used. | the average size is to be used. | |||
R is the round trip time in seconds. | R is the round trip time in seconds. | |||
p is the loss event rate, between 0 and 1.0, of the number of loss | p is the loss event rate, between 0 and 1.0, of the number of loss | |||
events as a fraction of the number of packets transmitted. | events as a fraction of the number of packets transmitted. | |||
t_RTO is the TCP retransmission timeout value in seconds, | t_RTO is the TCP retransmission timeout value in seconds, | |||
approximated by setting t_RTO = 4*R. | approximated by setting t_RTO = 4*R. | |||
b is the number of packets acknowledged by a single TCP | b is the number of packets acknowledged by a single TCP | |||
skipping to change at page 9, line 50 ¶ | skipping to change at page 10, line 34 ¶ | |||
approximated as follows with reasonable accuracy: | approximated as follows with reasonable accuracy: | |||
s | s | |||
X = --------------- | X = --------------- | |||
R * sqrt(p*2/3) | R * sqrt(p*2/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. | calculate than the full equation. | |||
Given this TCP equation, two parameters need to be estimated in order | Given this TCP equation, two parameters need to be estimated and | |||
to calculate the throughput: the round trip time, R, and the loss | reported to the sender in order to calculate the throughput: the | |||
event rate, p (the packet size, s, is known to the sender). The | round trip time, R, and the loss event rate, p (the packet size, s, | |||
round trip time can be estimated from RTCP SR and RR packets. This | is known to the sender). The round trip time can be estimated from | |||
is done too infrequently for accurate statistics, but is the best | RTCP SR and RR packets. This is done too infrequently for accurate | |||
that can be done with the standard RTCP mechanisms. | statistics, but is the best that can be done with the standard RTCP | |||
mechanisms. | ||||
RTCP RR packets contain the packet loss fraction, rather than the | RTCP RR packets contain the packet loss fraction, rather than the | |||
loss event rate, so p cannot be reported (TCP typically treats the | loss event rate, so p cannot be reported (TCP typically treats the | |||
loss of multiple packets within a single RTT as one loss event, but | loss of multiple packets within a single RTT as one loss event, but | |||
RTCP RR packets report the overall fraction of packets lost, not | RTCP RR packets report the overall fraction of packets lost, not | |||
caring about when the losses occurred). Using the loss fraction in | caring about when the losses occurred). Using the loss fraction in | |||
place of the loss event rate can overestimate the loss. We believe | place of the loss event rate can overestimate the loss. We believe | |||
that this overestimate will not be significant, given that we are | that this overestimate will not be significant, given that we are | |||
only interested in order of magnitude comparison (Floyd et al, | only interested in order of magnitude comparison ([Floyd] section | |||
"Equation-Based Congestion Control for Unicast Applications", Proc. | 3.2.1 shows that the difference is small for steady-state conditions | |||
SIGCOMM 2000, section 3.2.1, show that the difference is small for | and random loss, but using the loss fraction is more conservative in | |||
steady-state conditions and random loss, but using the loss fraction | the case of bursty loss). | |||
is more conservative in the case of bursty loss). | ||||
The congestion circuit breaker is therefore: when RTCP RR packets are | The congestion circuit breaker is therefore: when RTCP RR packets are | |||
received, estimate the TCP throughput using the simplified equation | received, estimate the TCP throughput using the simplified equation | |||
above, and the measured R, p (approximated by the loss fraction), and | above, and the measured R, p (approximated by the loss fraction), and | |||
s. Compare this with the actual sending rate. If the actual sending | s. Compare this with the actual sending rate. If the actual sending | |||
rate has been more than a factor of ten greater than the throughput | rate is more than ten times the estimated sending rate derived from | |||
equation estimate for two or more RTCP reporting intervals, stop | the TCP throughput equation for two consecutive RTCP reporting | |||
transmitting. | intervals, the sender SHOULD cease transmission. What it means to | |||
cease transmission depends on the application, but the intention is | ||||
Again, we use two reporting intervals to avoid triggering the circuit | that the application will stop sending RTP data packets until the | |||
breaker on transient failures. This circuit breaker is a worst-case | user makes an explicit attempt to restart the call (RTP flows halted | |||
condition, and congestion control needs to be performed to keep well | by the circuit breaker SHOULD NOT be restarted automatically unless | |||
within this bound. It is expected that the circuit breaker will only | the sender has received information that the congestion has | |||
be triggered if the usual congestion control fails for some reason. | dissipated). | |||
5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile | ||||
More rapid feedback allows more responsiveness. The receiver SHOULD | ||||
provide feedback more often during, or at onset of, congestion, and | ||||
provide feedback less often when there is no congestion. | ||||
(tbd -- mechanisms probably need to be designed in conjunction with | Systems that usually send at a high data rate, but that can reduce | |||
the different classes of congestion control that can leverage RTP/ | their data rate significantly (i.e., by at least a factor of ten), | |||
AVPF; e.g., we might need to specify limits for TFRC-like or delay- | MAY first reduce their sending rate to this lower value to see if | |||
based algorithms using RTP/AVPF feedback.) | this resolves the congestion, but MUST then cease transmission if the | |||
problem does not resolve itself within a further two RTCP reporting | ||||
intervals. An example of this might be a video conferencing system | ||||
that backs off to sending audio only, before completely dropping the | ||||
call. If such a reduction in sending rate resolves the congestion | ||||
problem, the sender MAY gradually increase the rate at which it sends | ||||
data after a reasonable amount of time has passed, provided it takes | ||||
care not to cause the problem to recur ("reasonable" is intentionally | ||||
not defined here). | ||||
(tbd -- a high-level question to be answered is whether we need to | As in Section 4.1, we use two reporting intervals to avoid triggering | |||
specify anything different for the circuit breaker for AVPF, or if we | the circuit breaker on transient failures. This circuit breaker is a | |||
leave that unchanged, and focus solely on the dynamics, to ensure the | worst-case condition, and congestion control needs to be performed to | |||
circuit breaker is never triggered.) | keep well within this bound. It is expected that the circuit breaker | |||
will only be triggered if the usual congestion control fails for some | ||||
reason. | ||||
6. Impact of RTCP XR | 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile | |||
(tbd) | Use of the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) | |||
[RFC4585] allows receivers to send early RTCP reports in some cases, | ||||
to inform the sender about particular events in the media stream. | ||||
There are several use cases for such early RTCP reports, including | ||||
providing rapid feedback to a sender about the onset of congestion. | ||||
This improves the information, but doesn't change the dynamics of the | Receiving rapid feedback about congestion events potentially allows | |||
congestion control loop. Suspect the impact will actually be quite | congestion control algorithms to be more responsive, and to better | |||
small. | adapt the media transmission to the limitations of the network. It | |||
is expected that many RTP congestion control algorithms will adopt | ||||
the RTP/AVPF profile for this reason, defining new transport layer | ||||
feedback reports that suit their requirements. Since these reports | ||||
are not yet defined, and likely very specific to the details of the | ||||
congestion control algorithm chosen, they cannot be used as part of | ||||
the generic RTP circuit breaker. | ||||
Packets discarded [I-D.ietf-xrblock-rtcp-xr-discard] or bytes | If the extension for Reduced-Size RTCP [RFC5506] is not used, early | |||
discarded [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] due to late | RTCP feedback packets sent according to the RTP/AVPF profile will be | |||
arrival by the receiver might indicate congestion. Congestion | compound RTCP packets that include an RTCP SR/RR packet. That RTCP | |||
control needs to consider the discarded packets as if they were lost | SR/RR packet MUST be processed as if it were sent as a regular RTCP | |||
packets. | report and counted towards the circuit breaker conditions specified | |||
in Section 4.1 and Section 4.3 of this memo. This will potentially | ||||
make the RTP circuit breaker fire earlier than it would if the RTP/ | ||||
AVPF profile was not used. | ||||
The RTCP RR reports the loss fraction over an RTCP interval which is | Reduced-size RTCP reports sent under to the RTP/AVPF early feedback | |||
insufficient to distinguish between solitary or bursty losses. To | rules that do not contain an RTCP SR or RR packet MUST be ignored by | |||
provide rough sense of duration of losses or discards, an endpoint | the RTP circuit breaker (they do not contain the information used by | |||
can use burst/gap reporting for loss | the circuit breaker algorithm). In this case, the circuit breaker | |||
[I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] and discard | will only use the information contained in the periodic RTCP SR/RR | |||
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard]. For more accurate | packets. This allows the use of low-overhead early RTP/AVPF feedback | |||
reporting the receiver can use Run-length encoded (RLE) lost | without triggering the RTP circuit breaker, and so is suitable for | |||
[RFC3611] or discarded [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] | RTP congestion control algorithms that need to quickly report loss | |||
packets. | events in between regular RTCP reports. | |||
For precise measurement of network roundtrip delay the receiver can | 6. Impact of RTCP XR | |||
signal its end-system delay [I-D.ietf-xrblock-rtcp-xr-delay] | ||||
[RFC3611]. | ||||
A receiver can also indicate onset or end of congestion by reporting | RTCP Extended Report (XR) blocks provide additional reception quality | |||
the distribution of the inter-packet delay variation | metrics, but do not change the RTCP timing rules. Some of the RTCP | |||
[I-D.ietf-xrblock-rtcp-xr-pdv] [RFC3611]. | XR blocks provide information that might be useful for congestion | |||
control purposes, others provided non-congestion-related metrics. | ||||
The presence of RTCP XR blocks in a compound RTCP packet does not | ||||
affect the RTP circuit breaker algorithm; for consistency and ease of | ||||
implementation, only the reception report blocks contained in RTCP SR | ||||
or RR packets are used by the RTP circuit breaker algorithm. | ||||
7. Impact of Explicit Congestion Notification (ECN) | 7. Impact of Explicit Congestion Notification (ECN) | |||
ECN-CE marked packets SHOULD be treated as if it were lost for the | ECN-CE marked packets SHOULD be treated as if it were lost for the | |||
purposes of congestion control, when determining the optimal rate at | purposes of congestion control, when determining the optimal media | |||
which to send. However, it seems unwise to treat the receipt of | sending rate for an RTP flow. If an RTP sender has negotiated ECN | |||
multiple ECN-CE marked packets as a circuit breaker, since it is | support for an RTP session, and has successfully initiated ECN use on | |||
likely that ECN-capable and non-ECN-capable paths will exist for a | the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD | |||
long time to come. Rather, consider packet loss as the circuit | be treated as if they were lost when calculating if the congestion- | |||
breaker condition as for non-ECN flows. | based RTP circuit breaker (Section 4.3) has been met. | |||
8. Session Timeout | The use of ECN for RTP flows does not affect the media timeout RTP | |||
circuit breaker (Section 4.1) or the RTCP timeout circuit breaker | ||||
(Section 4.2), since these are both connectivity checks that simply | ||||
determinate if any packets are being received. | ||||
From a usability perspective, if there is no audio or video response | 8. Security Considerations | |||
from the other peer, it is likely that the user will terminate the | ||||
session. | ||||
According to RFC 3550 [RFC3550], any participant that has not sent an | The security considerations of [RFC3550] apply. | |||
RTP packet within the last two RTCP interval is removed from the | ||||
sender list. To avoid timing out the specific flow, the endpoint | ||||
MUST send corresponding RTCP reports. Interactive Connectivity | ||||
Establishment (ICE) [RFC5245] recommends that the timeout MUST NOT be | ||||
less than 15 seconds. | ||||
If no RTCP RR arrives for two complete SR intervals, the sender | If the RTP/AVPF profile is used to provide rapid RTCP feedback, the | |||
SHOULD cease transmission. However, if the endpoint can reduce the | security considerations of [RFC4585] apply. If ECN feedback for RTP | |||
media rate then it MAY first reduce the rate to the lower value, but | over UDP/IP is used, the security considerations of [RFC6679] apply. | |||
terminate the transmission if still no RTCP RR is received in the | ||||
next two SR intervals. | If non-authenticated RTCP reports are used, an on-path attacker can | |||
trivially generate fake RTCP packets that indicate high packet loss | ||||
rates, causing the circuit breaker to trigger and disrupting an RTP | ||||
session. This is somewhat more difficult for an off-path attacker, | ||||
due to the need to guess the randomly chosen RTP SSRC value and the | ||||
RTP sequence number. This attack can be avoided if RTCP packets are | ||||
authenticated, for example using the Secure RTP profile [RFC3711]. | ||||
9. IANA Considerations | 9. IANA Considerations | |||
There are no actions for IANA. | There are no actions for IANA. | |||
10. Security Considerations | 10. Acknowledgements | |||
(tbd: Security considerations: how to protect against fake RTCP | ||||
reports being used to force sessions to close? SRTCP is one option, | ||||
but are there any lighter weight options?) | ||||
11. Open Issues | ||||
o Clarify: when will the recipient end a call, if it receives no | ||||
data? | ||||
o When we say "cease transmission", do we need some minimum interval | ||||
before we're allowed to restart? | ||||
o What does "cease transmission" mean? Do we send an RTCP BYE and | ||||
leave the session, or is it more temporary than that? | ||||
o Add a receiver-based circuit-breaker condition. Note that this is | ||||
dependent on the signalling still working, since the receiver | ||||
needs to be able to inform the sender. | ||||
12. Acknowledgements | ||||
The authors would like to thank Harald Alvestrand, Randell Jesup, and | The authors would like to thank Harald Alvestrand, Randell Jesup, | |||
Abheek Saha for their valuable feedback. | Matt Mathis, and Abheek Saha for their valuable feedback. | |||
13. References | 11. References | |||
13.1. Normative References | 11.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, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP | [RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP | |||
Friendly Rate Control (TFRC): Protocol Specification", | Friendly Rate Control (TFRC): Protocol Specification", | |||
RFC 3448, January 2003. | RFC 3448, January 2003. | |||
[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 | |||
skipping to change at page 13, line 33 ¶ | skipping to change at page 14, line 18 ¶ | |||
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control | [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control | |||
Protocol Extended Reports (RTCP XR)", RFC 3611, | Protocol Extended Reports (RTCP XR)", RFC 3611, | |||
November 2003. | November 2003. | |||
[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, | |||
July 2006. | July 2006. | |||
13.2. Informative References | 11.2. Informative References | |||
[I-D.ietf-avtcore-ecn-for-rtp] | [Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer, | |||
Westerlund, M., Johansson, I., Perkins, C., and K. | "Equation-Based Congestion Control for Unicast | |||
Carlberg, "Explicit Congestion Notification (ECN) for RTP | Applications", Proc. ACM SIGCOMM 2000, DOI 10.1145/ | |||
over UDP", draft-ietf-avtcore-ecn-for-rtp-06 (work in | 347059.347397, August 2000. | |||
progress), February 2012. | ||||
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] | [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] | |||
Clark, A., Hunt, G., Wu, W., and R. Huang, "RTCP XR Report | Clark, A., Huang, R., and W. Wu, "RTP Control | |||
Block for Burst/Gap Discard metric Reporting", | Protocol(RTCP) Extended Report (XR) Block for Discard | |||
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-02 (work in | Count metric Reporting", | |||
progress), January 2012. | draft-ietf-xrblock-rtcp-xr-burst-gap-discard-06 (work in | |||
progress), October 2012. | ||||
[I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] | [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] | |||
Clark, A., Hunt, G., Zhao, J., Wu, W., and S. Zhang, "RTCP | Clark, A., Zhang, S., Zhao, J., and W. Wu, "RTP Control | |||
XR Report Block for Burst/Gap Loss metric Reporting", | Protocol (RTCP) Extended Report (XR) Block for Burst/Gap | |||
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-01 (work in | Loss metric Reporting", | |||
progress), January 2012. | draft-ietf-xrblock-rtcp-xr-burst-gap-loss-04 (work in | |||
progress), October 2012. | ||||
[I-D.ietf-xrblock-rtcp-xr-delay] | [I-D.ietf-xrblock-rtcp-xr-delay] | |||
Hunt, G., Gross, K., and A. Clark, "RTCP XR Report Block | Clark, A., Gross, K., and W. Wu, "RTP Control Protocol | |||
for Delay metric Reporting", | (RTCP) Extended Report (XR) Block for Delay metric | |||
draft-ietf-xrblock-rtcp-xr-delay-01 (work in progress), | Reporting", draft-ietf-xrblock-rtcp-xr-delay-10 (work in | |||
December 2011. | progress), October 2012. | |||
[I-D.ietf-xrblock-rtcp-xr-discard] | [I-D.ietf-xrblock-rtcp-xr-discard] | |||
Hunt, G., Clark, A., Zorn, G., and W. Wu, "RTCP XR Report | Clark, A., Zorn, G., and W. Wu, "RTP Control Protocol | |||
Block for Discard metric Reporting", | (RTCP) Extended Report (XR) Block for Discard Count metric | |||
draft-ietf-xrblock-rtcp-xr-discard-01 (work in progress), | Reporting", draft-ietf-xrblock-rtcp-xr-discard-09 (work in | |||
December 2011. | progress), October 2012. | |||
[I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] | [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] | |||
Ott, J., Singh, V., and I. Curcio, "Real-time Transport | Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol | |||
Control Protocol (RTCP) Extension Report (XR) for Run | (RTCP) Extended Reports (XR) for Run Length Encoding (RLE) | |||
Length Encoding of Discarded Packets", | of Discarded Packets", | |||
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-03 (work in | draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-04 (work in | |||
progress), February 2012. | progress), July 2012. | |||
[I-D.ietf-xrblock-rtcp-xr-pdv] | [I-D.ietf-xrblock-rtcp-xr-pdv] | |||
Hunt, G. and A. Clark, "RTCP XR Report Block for Packet | Clark, A. and W. Wu, "RTP Control Protocol (RTCP) Extended | |||
Delay Variation Metric Reporting", | Report (XR) Block for Packet Delay Variation Metric | |||
draft-ietf-xrblock-rtcp-xr-pdv-02 (work in progress), | Reporting", draft-ietf-xrblock-rtcp-xr-pdv-08 (work in | |||
December 2011. | progress), September 2012. | |||
[Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, | ||||
"Modeling TCP Throughput: A Simple Model and its Empirical | ||||
Validation", Proc. ACM SIGCOMM 1998, DOI 10.1145/ | ||||
285237.285291, August 1998. | ||||
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |||
of Explicit Congestion Notification (ECN) to IP", | of Explicit Congestion Notification (ECN) to IP", | |||
RFC 3168, September 2001. | RFC 3168, September 2001. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | ||||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | ||||
RFC 3711, March 2004. | ||||
[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, February 2008. | with Feedback (AVPF)", RFC 5104, February 2008. | |||
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment | ||||
(ICE): A Protocol for Network Address Translator (NAT) | ||||
Traversal for Offer/Answer Protocols", RFC 5245, | ||||
April 2010. | ||||
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in | [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in | |||
RTP Streams", RFC 5450, March 2009. | RTP Streams", RFC 5450, March 2009. | |||
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size | ||||
Real-Time Transport Control Protocol (RTCP): Opportunities | ||||
and Consequences", RFC 5506, April 2009. | ||||
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP | [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP | |||
Flows", RFC 6051, November 2010. | Flows", RFC 6051, November 2010. | |||
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., | ||||
and K. Carlberg, "Explicit Congestion Notification (ECN) | ||||
for RTP over UDP", RFC 6679, August 2012. | ||||
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 | Aalto University | |||
School of Science and Technology | School of Electrical Engineering | |||
Otakaari 5 A | Otakaari 5 A | |||
Espoo, FIN 02150 | Espoo, FIN 02150 | |||
Finland | Finland | |||
Email: varun@comnet.tkk.fi | Email: varun@comnet.tkk.fi | |||
URI: http://www.netlab.tkk.fi/~varun/ | URI: http://www.netlab.tkk.fi/~varun/ | |||
End of changes. 55 change blocks. | ||||
194 lines changed or deleted | 236 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |