draft-ietf-avtcore-rtp-circuit-breakers-02.txt | draft-ietf-avtcore-rtp-circuit-breakers-03.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | AVTCORE Working Group C. S. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Standards Track V. Singh | Updates: 3550 (if approved) V. Singh | |||
Expires: August 26, 2013 Aalto University | Intended status: Standards Track Aalto University | |||
February 22, 2013 | Expires: January 16, 2014 July 15, 2013 | |||
Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions | Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions | |||
draft-ietf-avtcore-rtp-circuit-breakers-02 | draft-ietf-avtcore-rtp-circuit-breakers-03 | |||
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; instead, it defines a minimal | propose a congestion control algorithm; instead, it defines a minimal | |||
set of RTP "circuit-breakers". Circuit-breakers are conditions under | set of RTP "circuit-breakers". Circuit-breakers are conditions under | |||
which an RTP sender needs to stop transmitting media data in order to | which an RTP sender needs to stop transmitting media data in order to | |||
protect the network from excessive congestion. It is expected that, | protect the network from excessive congestion. It is expected that, | |||
in the absence of severe congestion, all RTP applications running on | in the absence of severe congestion, all RTP applications running on | |||
best-effort IP networks will be able to run without triggering these | best-effort IP networks will be able to run without triggering these | |||
circuit breakers. Any future RTP congestion control specification | circuit breakers. Any future RTP congestion control specification | |||
will be expected to operate within the constraints defined by these | will be expected to operate within the constraints defined by these | |||
circuit breakers. | 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 August 26, 2013. | This Internet-Draft will expire on January 16, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
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: Media Timeout . . . . . . . . 8 | 4.1. RTP/AVP Circuit Breaker #1: Media Timeout . . . . . . . . 7 | |||
4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout . . . . . . . . . 8 | 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout . . . . . . . . 8 | |||
4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . . 9 | 4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 9 | |||
4.4. Ceasing Transmission . . . . . . . . . . . . . . . . . . . 12 | 4.4. Ceasing Transmission . . . . . . . . . . . . . . . . . . 12 | |||
5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 12 | 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 12 | |||
6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 13 | 6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7. Impact of Explicit Congestion Notification (ECN) . . . . . . . 14 | 7. Impact of RTCP Reporting Groups . . . . . . . . . . . . . . . 14 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 8. Impact of Explicit Congestion Notification (ECN) . . . . . . 14 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . . 15 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 | 12.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | ||||
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 9, line 23 ¶ | skipping to change at page 8, line 50 ¶ | |||
following Section 6.3.5 of RFC 3550 [RFC3550]. This specifies that | following Section 6.3.5 of RFC 3550 [RFC3550]. This specifies that | |||
participants in an RTP session will timeout and remove an RTP sender | participants in an RTP session will timeout and remove an RTP sender | |||
from the list of active RTP senders if no RTP data packets have been | from the list of active RTP senders if no RTP data packets have been | |||
received from that RTP sender within the last two RTCP reporting | received from that RTP sender within the last two RTCP reporting | |||
intervals. Using a timeout of three RTCP reporting intervals is | intervals. Using a timeout of three RTCP reporting intervals is | |||
therefore large enough that the other participants will have timed | therefore large enough that the other participants will have timed | |||
out the sender if a network problem stops the data packets it is | out the sender if a network problem stops the data packets it is | |||
sending from reaching the receivers, even allowing for loss of some | sending from reaching the receivers, even allowing for loss of some | |||
RTCP packets. | RTCP packets. | |||
If a sender is transmitting a large number of RTP media streams, such | ||||
that the corresponding RTCP SR or RR packets are too large to fit | ||||
into the network MTU, this will force the receiver to generate RTCP | ||||
SR or RR packets in a round-robin manner. In this case, the sender | ||||
MAY treat receipt of an RTCP SR or RR packet corresponding to an SSRC | ||||
it sent using the same 5-tuple of source and destination IP address, | ||||
port, and protocol, as an indication that the receiver and return | ||||
path are working to prevent the RTCP timeout circuit breaker from | ||||
triggering. | ||||
4.3. RTP/AVP Circuit Breaker #3: Congestion | 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 SR or | |||
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 RTP flow is | |||
skipping to change at page 10, line 11 ¶ | skipping to change at page 9, line 47 ¶ | |||
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 TCP connection would achieve over the path. | |||
For a long-lived TCP Reno connection, Padhye et al. [Padhye] showed | For a long-lived TCP Reno connection, Padhye et al. [Padhye] showed | |||
that the throughput can be estimated using the following equation: | 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 data packets vary in size, then | s is the packet size in bytes. If data packets vary in 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. | |||
skipping to change at page 10, line 38 ¶ | skipping to change at page 10, line 28 ¶ | |||
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 | |||
acknowledgement ([RFC3448] recommends the use of b=1 since many | acknowledgement ([RFC3448] recommends the use of b=1 since many | |||
TCP implementations do not use delayed acknowledgements). | TCP implementations do not use delayed acknowledgements). | |||
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, this formula can be | [RFC3448]. Under conditions of low packet loss, this formula can be | |||
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 and | Given this TCP equation, two parameters need to be estimated and | |||
reported to the sender in order to calculate the throughput: the | reported to the sender in order to calculate the throughput: the | |||
round trip time, R, and the loss event rate, p (the packet size, s, | round trip time, R, and the loss event rate, p (the packet size, s, | |||
is known to the sender). The round trip time can be estimated from | is known to the sender). The round trip time can be estimated from | |||
RTCP SR and RR packets. This is done too infrequently for accurate | RTCP SR and RR packets. This is done too infrequently for accurate | |||
statistics, but is the best that can be done with the standard RTCP | statistics, but is the best that can be done with the standard RTCP | |||
mechanisms. | mechanisms. | |||
RTCP RR packets contain the packet loss fraction, rather than the | Report blocks in RTCP SR or RR packets contain the packet loss | |||
loss event rate, so p cannot be reported (TCP typically treats the | fraction, rather than the loss event rate, so p cannot be reported | |||
loss of multiple packets within a single RTT as one loss event, but | (TCP typically treats the loss of multiple packets within a single | |||
RTCP RR packets report the overall fraction of packets lost, not | RTT as one loss event, but RTCP RR packets report the overall | |||
caring about when the losses occurred). Using the loss fraction in | fraction of packets lost, not caring about when the losses occurred). | |||
place of the loss event rate can overestimate the loss. We believe | Using the loss fraction in place of the loss event rate can | |||
that this overestimate will not be significant, given that we are | overestimate the loss. We believe that this overestimate will not be | |||
only interested in order of magnitude comparison ([Floyd] section | significant, given that we are only interested in order of magnitude | |||
3.2.1 shows that the difference is small for steady-state conditions | comparison ([Floyd] section 3.2.1 shows that the difference is small | |||
and random loss, but using the loss fraction is more conservative in | for steady-state conditions and random loss, but using the loss | |||
the case of bursty loss). | fraction is more conservative in the case of bursty loss). | |||
The congestion circuit breaker is therefore: when a sender receives | The congestion circuit breaker is therefore: when a sender receives | |||
an RTCP SR or RR packet that contains a report block for an SSRC it | an RTCP SR or RR packet that contains a report block for an SSRC it | |||
is using, that sender has to check the fraction lost field in that | is using, that sender has to check the fraction lost field in that | |||
report block to determine if there is a non-zero packet loss rate. | report block to determine if there is a non-zero packet loss rate. | |||
If the fraction lost field is zero, then continue sending as normal. | If the fraction lost field is zero, then continue sending as normal. | |||
If the fraction lost is greater than zero, then estimate the TCP | If the fraction lost is greater than zero, then estimate the TCP | |||
throughput using the simplified equation above, and the measured R, p | throughput using the simplified equation above, and the measured R, p | |||
(approximated by the fraction lost), and s. Compare this with the | (approximated by the fraction lost), and s. Compare this with the | |||
actual sending rate. If the actual sending rate is more than ten | actual sending rate. If the actual sending rate is more than ten | |||
times the estimated sending rate derived from the TCP throughput | times the estimated sending rate derived from the TCP throughput | |||
equation for two consecutive RTCP reporting intervals, the sender | equation for two consecutive RTCP reporting intervals, the sender | |||
SHOULD cease transmission (see Section 4.4). If the RTP sender is | SHOULD cease transmission (see Section 4.4). Systems that usually | |||
using a reduced minimum RTCP reporting interval (as specified in | send at a high data rate, but that can reduce their data rate | |||
Section 6.2 of RFC 3550 [RFC3550] or the RTP/AVPF profile [RFC4585]), | significantly (i.e., by at least a factor of ten), MAY first reduce | |||
then that reduced RTCP reporting interval is used when determining if | their sending rate to this lower value to see if this resolves the | |||
the circuit breaker is triggered, since that interval scales with the | congestion, but MUST then cease transmission if the problem does not | |||
media data rate. | resolve itself within a further two RTCP reporting intervals (see | |||
Section 4.4). An example of this might be a video conferencing | ||||
Systems that usually send at a high data rate, but that can reduce | system that backs off to sending audio only, before completely | |||
their data rate significantly (i.e., by at least a factor of ten), | dropping the call. If such a reduction in sending rate resolves the | |||
MAY first reduce their sending rate to this lower value to see if | congestion problem, the sender MAY gradually increase the rate at | |||
this resolves the congestion, but MUST then cease transmission if the | which it sends data after a reasonable amount of time has passed, | |||
problem does not resolve itself within a further two RTCP reporting | provided it takes care not to cause the problem to recur | |||
intervals (see Section 4.4). 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). | ("reasonable" is intentionally not defined here). | |||
If the incoming RTCP SR or RR packets are using a reduced minimum | ||||
RTCP reporting interval (as specified in Section 6.2 of RFC 3550 | ||||
[RFC3550] or the RTP/AVPF profile [RFC4585]), then that reduced RTCP | ||||
reporting interval is used when determining if the circuit breaker is | ||||
triggered. The RTCP reporting interval of the media sender does not | ||||
affect how quickly congestion circuit breaker can trigger. The | ||||
timing is based on the RTCP reporting interval of the receiver that | ||||
matters (note that RTCP requires all participants in a session to | ||||
have similar reporting intervals, else the participant timeout rules | ||||
in [RFC3550] will not work). | ||||
As in Section 4.1, we use two reporting intervals to avoid triggering | As in Section 4.1, we use two reporting intervals to avoid triggering | |||
the circuit breaker on transient failures. This circuit breaker is a | the circuit breaker on transient failures. This circuit breaker is a | |||
worst-case condition, and congestion control needs to be performed to | worst-case condition, and congestion control needs to be performed to | |||
keep well within this bound. It is expected that the circuit breaker | keep well within this bound. It is expected that the circuit breaker | |||
will only be triggered if the usual congestion control fails for some | will only be triggered if the usual congestion control fails for some | |||
reason. | reason. | |||
If there are more media streams that can be reported in a single RTCP | ||||
SR or RR packet, or if the size of a complete RTCP SR or RR packet | ||||
exceeds the network MTU, then the receiver will report on a subset of | ||||
sources in each reporting interval, with the subsets selected round- | ||||
robin across multiple intervals so that all sources are eventually | ||||
reported [RFC3550]. When generating such round-robin RTCP reports, | ||||
priority SHOULD be given to reports on sources that have high packet | ||||
loss rates, to ensure that senders are aware of network congestion | ||||
they are causing (this is an update to [RFC3550]). | ||||
4.4. Ceasing Transmission | 4.4. Ceasing Transmission | |||
What it means to cease transmission depends on the application, but | What it means to cease transmission depends on the application, but | |||
the intention is that the application will stop sending RTP data | the intention is that the application will stop sending RTP data | |||
packets to a particular destination 3-tuple (transport protocol, | packets to a particular destination 3-tuple (transport protocol, | |||
destination port, IP address), until the user makes an explicit | destination port, IP address), until the user makes an explicit | |||
attempt to restart the call. It is important that a human user is | attempt to restart the call. It is important that a human user is | |||
involved in the decision to try to restart the call, since that user | involved in the decision to try to restart the call, since that user | |||
will eventually give up if the calls repeatedly trigger the circuit | will 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 | |||
skipping to change at page 13, line 19 ¶ | skipping to change at page 13, line 26 ¶ | |||
Reduced-size RTCP reports sent under the RTP/AVPF early feedback | Reduced-size RTCP reports sent under the RTP/AVPF early feedback | |||
rules that do not contain an RTCP SR or RR packet MUST be ignored by | rules that do not contain an RTCP SR or RR packet MUST be ignored by | |||
the RTP circuit breaker (they do not contain the information used by | the RTP circuit breaker (they do not contain the information used by | |||
the circuit breaker algorithm). Reduced-size RTCP reports sent under | the circuit breaker algorithm). Reduced-size RTCP reports sent under | |||
the RTP/AVPF early feedback rules that contain RTCP SR or RR packets | the RTP/AVPF early feedback rules that contain RTCP SR or RR packets | |||
MUST be processed as if they were sent as regular RTCP reports, and | MUST be processed as if they were sent as regular RTCP reports, and | |||
counted towards the circuit breaker conditions specified in Section 4 | counted towards the circuit breaker conditions specified in Section 4 | |||
of this memo. This will potentially make the RTP circuit breaker | of this memo. This will potentially make the RTP circuit breaker | |||
fire earlier than it would if the RTP/AVPF profile was not used. | fire earlier than it would if the RTP/AVPF profile was not used. | |||
When using ECN with RTP (see Section 7), early RTCP feedback packets | When using ECN with RTP (see Section 8), 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 report is sent in | |||
an compound RTCP packet along with an RTCP SR/RR report packet. | an compound RTCP packet along with an RTCP SR/RR report packet. | |||
Reports of ECN-CE packets sent as reduced-size RTCP ECN feedback | Reports of ECN-CE packets sent as reduced-size RTCP ECN feedback | |||
packets without an RTCP SR/RR packet MUST be ignored. | packets without an RTCP SR/RR packet MUST be ignored. | |||
These rules are intended to allow the use of low-overhead early RTP/ | These rules are intended to allow the use of low-overhead early RTP/ | |||
AVPF feedback for generic NACK messages without triggering the RTP | AVPF feedback for generic NACK messages without triggering the RTP | |||
circuit breaker. This is expected to make such feedback suitable for | circuit breaker. This is expected to make such feedback suitable for | |||
skipping to change at page 13, line 41 ¶ | skipping to change at page 13, line 48 ¶ | |||
events in between regular RTCP reports. The reaction to reduced-size | events in between regular RTCP reports. The reaction to reduced-size | |||
RTCP SR/RR packets is to allow such algorithms to send feedback that | RTCP SR/RR packets is to allow such algorithms to send feedback that | |||
can trigger the circuit breaker, when desired. | can trigger the circuit breaker, when desired. | |||
6. Impact of RTCP XR | 6. Impact of RTCP 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 provided 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 8), | |||
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 RTCP Reporting Groups | |||
An optimisation for grouping RTCP reception statistics and other | ||||
feedback in RTP sessions with large numbers of participants is given | ||||
in [I-D.ietf-avtcore-rtp-multi-stream-optimisation]. This allows one | ||||
SSRC to act as a representative that sends reports on behalf of other | ||||
SSRCs that are co-located in the same endpoint and see identical | ||||
reception quality. When running the circuit breaker algorithms, an | ||||
endpoint MUST treat a reception report from the representative of the | ||||
reporting group as if a reception report was received from all | ||||
members of that group. | ||||
8. 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 | |||
circuit breaker (Section 4.1) or the RTCP timeout circuit breaker | circuit breaker (Section 4.1) or the RTCP timeout circuit breaker | |||
(Section 4.2), since these are both connectivity checks that simply | (Section 4.2), since these are both connectivity checks that simply | |||
determinate if any packets are being received. | determinate if any packets are being received. | |||
ECN-CE marked packets SHOULD be treated as if 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 media | purposes of congestion control, when determining the optimal media | |||
sending rate for an RTP flow. If an RTP sender has negotiated ECN | sending rate for an RTP flow. If an RTP sender has negotiated ECN | |||
support for an RTP session, and has successfully initiated ECN use on | support for an RTP session, and has successfully initiated ECN use on | |||
the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD | the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD | |||
be treated as if they were lost when calculating if the congestion- | be treated as if they were lost when calculating if the congestion- | |||
based RTP circuit breaker (Section 4.3) has been met. The count of | based RTP circuit breaker (Section 4.3) has been met. The count of | |||
ECN-CE marked RTP packets is returned in RTCP XR ECN summary report | ECN-CE marked RTP packets is returned in RTCP XR ECN summary report | |||
packets if support for ECN has been initiated for an RTP session. | packets if support for ECN has been initiated for an RTP session. | |||
8. 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 disrupting 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, for example using the Secure RTP profile [RFC3711]. | authenticated, for example using the Secure RTP profile [RFC3711]. | |||
9. IANA Considerations | 10. IANA Considerations | |||
There are no actions for IANA. | There are no actions for IANA. | |||
10. Acknowledgements | 11. Acknowledgements | |||
The authors would like to thank Bernard Aboba, Harald Alvestrand, | The authors would like to thank Bernard Aboba, Harald Alvestrand, | |||
Kevin Gross, Cullen Jennings, Randell Jesup, Jonathan Lennox, Matt | Kevin Gross, Cullen Jennings, Randell Jesup, Jonathan Lennox, Matt | |||
Mathis, Stephen McQuistin, Eric Rescorla, and Abheek Saha for their | Mathis, Stephen McQuistin, Eric Rescorla, and Abheek Saha for their | |||
valuable feedback. | valuable feedback. | |||
11. References | 12. References | |||
11.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, 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 | |||
RFC 3448, January 2003. | 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 | |||
Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, July 2003. | |||
[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, | |||
July 2003. | July 2003. | |||
[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 | |||
November 2003. | 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 | |||
July 2006. | 2006. | |||
11.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", Proc. ACM SIGCOMM 2000, DOI 10.1145/ | Applications", Proc. ACM SIGCOMM 2000, DOI 10.1145/ | |||
347059.347397, August 2000. | 347059.347397, August 2000. | |||
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] | ||||
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, | ||||
"Sending Multiple Media Streams in a Single RTP Session: | ||||
Grouping RTCP Reception Statistics and Other Feedback", | ||||
draft-ietf-avtcore-rtp-multi-stream-optimisation-00 (work | ||||
in progress), July 2013. | ||||
[I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] | [I-D.ietf-xrblock-rtcp-xr-burst-gap-discard] | |||
Clark, A., Huang, R., and W. Wu, "RTP Control | Clark, A., Huang, R., and W. Wu, "RTP Control | |||
Protocol(RTCP) Extended Report (XR) Block for Burst/Gap | Protocol(RTCP) Extended Report (XR) Block for Burst/Gap | |||
Discard metric Reporting", | Discard metric Reporting", draft-ietf-xrblock-rtcp-xr- | |||
draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10 (work in | burst-gap-discard-14 (work in progress), April 2013. | |||
progress), January 2013. | ||||
[I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] | [I-D.ietf-xrblock-rtcp-xr-burst-gap-loss] | |||
Clark, A., Zhang, S., Zhao, J., and W. Wu, "RTP Control | Clark, A., Zhang, S., Zhao, J., and W. Wu, "RTP Control | |||
Protocol (RTCP) Extended Report (XR) Block for Burst/Gap | Protocol (RTCP) Extended Report (XR) Block for Burst/Gap | |||
Loss metric Reporting", | Loss metric Reporting", draft-ietf-xrblock-rtcp-xr-burst- | |||
draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08 (work in | gap-loss-12 (work in progress), April 2013. | |||
progress), January 2013. | ||||
[I-D.ietf-xrblock-rtcp-xr-discard] | ||||
Clark, A., Zorn, G., and W. Wu, "RTP Control Protocol | ||||
(RTCP) Extended Report (XR) Block for Discard Count metric | ||||
Reporting", draft-ietf-xrblock-rtcp-xr-discard-11 (work in | ||||
progress), December 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, "RTP Control Protocol | Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol | |||
(RTCP) Extended Reports (XR) for Run Length Encoding (RLE) | (RTCP) Extended Reports (XR) for Run Length Encoding (RLE) | |||
of Discarded Packets", | of Discarded Packets", draft-ietf-xrblock-rtcp-xr-discard- | |||
draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-05 (work in | rle-metrics-06 (work in progress), July 2013. | |||
progress), December 2012. | ||||
[I-D.ietf-xrblock-rtcp-xr-discard] | ||||
Clark, A., Zorn, G., and W. Wu, "RTP Control Protocol | ||||
(RTCP) Extended Report (XR) Block for Discard Count metric | ||||
Reporting", draft-ietf-xrblock-rtcp-xr-discard-15 (work in | ||||
progress), June 2013. | ||||
[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", Proc. ACM SIGCOMM 1998, DOI 10.1145/ | Validation", Proc. ACM SIGCOMM 1998, DOI 10.1145/ | |||
285237.285291, August 1998. | 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 | |||
RFC 3168, September 2001. | 3168, September 2001. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, March 2004. | 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. | |||
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in | [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in | |||
End of changes. 31 change blocks. | ||||
94 lines changed or deleted | 136 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/ |