draft-ietf-rmcat-rtp-cc-feedback-01.txt | draft-ietf-rmcat-rtp-cc-feedback-02.txt | |||
---|---|---|---|---|
Network Working Group C. Perkins | Network Working Group C. Perkins | |||
Internet-Draft University of Glasgow | Internet-Draft University of Glasgow | |||
Intended status: Informational July 8, 2016 | Intended status: Informational October 31, 2016 | |||
Expires: January 9, 2017 | Expires: May 4, 2017 | |||
Using RTP Control Protocol (RTCP) Feedback for Unicast Multimedia | RTP Control Protocol (RTCP) Feedback for Congestion Control in | |||
Congestion Control | Interactive Multimedia Conferences | |||
draft-ietf-rmcat-rtp-cc-feedback-01 | draft-ietf-rmcat-rtp-cc-feedback-02 | |||
Abstract | Abstract | |||
This memo discusses the types of congestion control feedback that it | This memo discusses the types of congestion control feedback that it | |||
is possible to send using the RTP Control Protocol (RTCP), and their | is possible to send using the RTP Control Protocol (RTCP), and their | |||
suitability of use in implementing congestion control for unicast | suitability of use in implementing congestion control for unicast | |||
multimedia applications. | multimedia applications. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 34 ¶ | skipping to change at page 1, line 34 ¶ | |||
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 January 9, 2017. | This Internet-Draft will expire on May 4, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Possible Models for RTCP Feedback . . . . . . . . . . . . . . 2 | 2. Possible Models for RTCP Feedback . . . . . . . . . . . . . . 2 | |||
3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 4 | 3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 4 | |||
3.1. Per-packet Feedback . . . . . . . . . . . . . . . . . . . 4 | 3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 4 | |||
3.2. Per-frame Feedback . . . . . . . . . . . . . . . . . . . 4 | 3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 6 | |||
3.3. Per-RTT Feedback . . . . . . . . . . . . . . . . . . . . 6 | 3.3. Scenario 3: Group Video Conference . . . . . . . . . . . 10 | |||
4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 7 | 3.4. Scenario 4: Screen Sharing . . . . . . . . . . . . . . . 10 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 10 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
8. Informative References . . . . . . . . . . . . . . . . . . . 7 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 | 8. Informative References . . . . . . . . . . . . . . . . . . . 11 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
1. Introduction | 1. Introduction | |||
The coming deployment of WebRTC systems raises the prospect that high | The coming deployment of WebRTC systems raises the prospect that high | |||
quality video conferencing will see extremely wide use. To ensure | quality video conferencing will see extremely wide use. To ensure | |||
the stability of the network in the face of this use, WebRTC systems | the stability of the network in the face of this use, WebRTC systems | |||
will need to use some form of congestion control for their RTP-based | will need to use some form of congestion control for their RTP-based | |||
media traffic. To develop such congestion control, it is necessary | media traffic. To develop such congestion control, it is necessary | |||
to understand the sort of congestion feedback that can be provided | to understand the sort of congestion feedback that can be provided | |||
within the framework of RTP [RFC3550] and the RTP Control Protocol | within the framework of RTP [RFC3550] and the RTP Control Protocol | |||
skipping to change at page 3, line 18 ¶ | skipping to change at page 3, line 19 ¶ | |||
reasonable overhead, to send separate acknowledgement packets when | reasonable overhead, to send separate acknowledgement packets when | |||
those packets are much smaller than data packets. It becomes a | those packets are much smaller than data packets. It becomes a | |||
problem, however, when there is no return traffic on which to | problem, however, when there is no return traffic on which to | |||
piggyback acknowledgements, and when acknowledgements are similar in | piggyback acknowledgements, and when acknowledgements are similar in | |||
size to data packets; this can be the case for some forms of media | size to data packets; this can be the case for some forms of media | |||
traffic, especially for voice over IP (VoIP) flows, but less so for | traffic, especially for voice over IP (VoIP) flows, but less so for | |||
video. | video. | |||
When considering multimedia traffic, it might make sense to consider | When considering multimedia traffic, it might make sense to consider | |||
less frequent feedback. For example, it might be possible to send a | less frequent feedback. For example, it might be possible to send a | |||
feedback packet once per video frame, or once per network round trip | feedback packet once per video frame, or every few frames, or once | |||
time (RTT). This could still give sufficiently frequent feedback for | per network round trip time (RTT). This could still give | |||
the congestion control loop to be stable and responsive while keeping | sufficiently frequent feedback for the congestion control loop to be | |||
the overhead reasonable when the feedback cannot be piggybacked onto | stable and responsive while keeping the overhead reasonable when the | |||
returning data. In this case, it is important to note that RTCP can | feedback cannot be piggybacked onto returning data. In this case, it | |||
send much more detailed feedback than simple acknowledgements. For | is important to note that RTCP can send much more detailed feedback | |||
example, if it were useful, it could be possible to use an RTCP | than simple acknowledgements. For example, if it were useful, it | |||
extended report (XR) packet [RFC3611] to send feedback once per RTT | could be possible to use an RTCP extended report (XR) packet | |||
comprising a bitmap of lost and received packets, with reception | [RFC3611] to send feedback once per RTT comprising a bitmap of lost | |||
times, over that RTT. As long as feedback is sent frequently enough | and received packets, with reception times, over that RTT. As long | |||
that the control loop is stable, and the sender is kept informed when | as feedback is sent frequently enough that the control loop is | |||
data leaves the network (to provide an equivalent to ACK clocking in | stable, and the sender is kept informed when data leaves the network | |||
TCP), it is not necessary to report on every packet at the instant it | (to provide an equivalent to ACK clocking in TCP), it is not | |||
is received (indeed, it is unlikely that a video codec can react | necessary to report on every packet at the instant it is received | |||
instantly to a rate change anyway, and there is little point in | (indeed, it is unlikely that a video codec can react instantly to a | |||
providing feedback more often than the codec can adapt). | rate change anyway, and there is little point in providing feedback | |||
more often than the codec can adapt). | ||||
The amount of overhead due to congestion control feedback that is | The amount of overhead due to congestion control feedback that is | |||
considered acceptable has to be determined. RTCP data is sent in | considered acceptable has to be determined. RTCP data is sent in | |||
separate packets to RTP data, and this has some cost in terms of | separate packets to RTP data, and this has some cost in terms of | |||
additional header overhead compared to protocols that piggyback | additional header overhead compared to protocols that piggyback | |||
feedback on return path data packets. The RTP standards have long | feedback on return path data packets. The RTP standards have long | |||
said that a 5% overhead for RTCP traffic generally acceptable, while | said that a 5% overhead for RTCP traffic generally acceptable, while | |||
providing the ability to change this fraction. Is this still the | providing the ability to change this fraction. Is this still the | |||
case for congestion control feedback? Or is there a desire to either | case for congestion control feedback? Or is there a desire to either | |||
see more responsive feedback and congestion control, possibility with | see more responsive feedback and congestion control, possibility with | |||
skipping to change at page 4, line 9 ¶ | skipping to change at page 4, line 11 ¶ | |||
Finally, the details of how much, and what, data is to be sent in | Finally, the details of how much, and what, data is to be sent in | |||
each report will affect the frequency and/or overhead of feedback. | each report will affect the frequency and/or overhead of feedback. | |||
There is a fundamental trade-off that the more frequently feedback | There is a fundamental trade-off that the more frequently feedback | |||
packets are sent, the less data can be included in each packet to | packets are sent, the less data can be included in each packet to | |||
keep the overhead constant. Does the congestion control need high | keep the overhead constant. Does the congestion control need high | |||
rate but simple feedback (e.g., like TCP acknowledgements), or is it | rate but simple feedback (e.g., like TCP acknowledgements), or is it | |||
acceptable to send more complex feedback less often? | acceptable to send more complex feedback less often? | |||
3. What Feedback is Achievable With RTCP? | 3. What Feedback is Achievable With RTCP? | |||
3.1. Per-packet Feedback | 3.1. Scenario 1: Voice Telephony | |||
RTCP packets are sent as separate packets to RTP media data, and the | In many ways, point-to-point voice telephony is the simplest scenario | |||
protocol includes no mechanism for piggybacking an RTCP packet onto | for congestion control, since there is only a single media stream to | |||
an RTP data packet. In addition, the RTCP timing rules are based on | control. It's complicated, however, by severe bandwidth constraints | |||
the size of the RTP session, the number of active senders, the RTCP | on the feedback, to keep the overhead manageable. | |||
packet size, and the configured RTCP bandwidth fraction, with | ||||
randomisation to prevent synchronisation of reports; accordingly the | ||||
RTCP packet transmission times are extremely unlikely to line up with | ||||
RTP packet transmission times. As a result, RTCP cannot be used to | ||||
send per-packet feedback in it's current form. | ||||
All of these issues with using RTCP for per-packet feedback could be | Assume a two-party point-to-point voice-over-IP call, using RTP over | |||
resolved in an update to the RTP protocol, of course. Such an update | UDP/IP. A rate adaptive speech codec, such as Opus, is used, encoded | |||
could change the RTCP timing rules, and might define a shim layer to | into RTP packets in frames of duration Tf seconds (Tf = 20ms in many | |||
allow multiplexing of RTP and RTCP into a single packet, or to extend | cases, but values up to 60ms are not uncommon). The congestion | |||
the RTP header to piggyback feedback data. This sort of change would | control algorithm requires feedback every Nr frames, i.e., every Nr * | |||
be a large, and almost certainly backwards incompatible, extension to | Tf seconds, to ensure effective control. Both parties in the call | |||
the RTP protocol, and is unlikely to be completed quickly, but could | send speech data or comfort noise with sufficient frequency that they | |||
be done if there was a need. | are counted as senders for the purpose of the RTCP reporting interval | |||
calculation. | ||||
3.2. Per-frame Feedback | RTCP feedback packets can be full, compound, RTCP feedback packets, | |||
or non-compound RTCP packets. A compound RTCP packet is sent once | ||||
for every Nnc non-compound RTCP packets. | ||||
Consider one of the simplest scenarios for WebRTC: a point to point | Compound RTCP packets contain a Sender Report (SR) packet and a | |||
video call between two end systems. There will be four RTP flows in | Source Description (SDES) packet, and an RTP Congestion Control | |||
this scenario, two audio and two video, with all four flows being | Feedback (RC2F) packet [I-D.dt-rmcat-feedback-message]. Non-compound | |||
active for essentially all the time (the audio flows will likely use | RTCP packets contain only the RC2F packet. Since each participant | |||
voice activity detection and comfort noise to reduce the packet rate | sends only a single media stream, the extensions for RTCP report | |||
during silent periods, and does not cause the transmissions to stop). | aggregation [I-D.ietf-avtcore-rtp-multi-stream] and reporting group | |||
optimisation [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are not | ||||
used. | ||||
Within each compound RTCP packet, the SR packet will contain a sender | ||||
information block (28 octets) and a single reception report block (24 | ||||
octets), for a total of 52 octets. A minimal SDES packet will | ||||
contain a header (4 octets) and a single chunk containing an SSRC (4 | ||||
octets) and a CNAME item, and if the recommendations for choosing the | ||||
CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet | ||||
header, 16 octets of data, and 2 octets of padding, for a total SDES | ||||
packet size of 28 octets. The RC2F packets contains an XR block | ||||
header and SSRC (8 octets), a block type and timestamp (8 octets), | ||||
the SSRC, beginning and ending sequence numbers (8 octets), and 2*Nr | ||||
octets of reports, for a total of 24 + 2*Nr octets. If IPv4 is used, | ||||
with no IP options, the UDP/IP header will be 28 octets in size. | ||||
This gives a total compound RTCP packet size of Sc = 132 + 2*Nr | ||||
octets. | ||||
The non-compound RTCP packets will comprise just the RC2F packet with | ||||
a UDP/IP header. It can be seen that these packets will be Snc = 52 | ||||
+ 2*Nr octets in size. | ||||
The RTCP reporting interval calculation ([RFC3550], Section 6.2) for | ||||
a two-party session where both participants are senders, reduces to | ||||
Trtcp = n * Srtcp/Brtcp where Srtcp = (Sc + Nnc * Snc)/(1 + Nnc) is | ||||
the average RTCP packet size in octets, Brtcp is the bandwidth | ||||
allocated to RTCP in octets per second, and n is the number of | ||||
participants (n=2 in this scenario). | ||||
To ensure a report is sent every Nr frames, it is necessary to set | ||||
the RTCP reporting interval Trtcp = Nr * Tf, which when substituted | ||||
into the previous gives Nr * Tf = n * Srtcp/Brtcp. | ||||
Solving for the RTCP bandwidth, Brtcp, and expanding the definition | ||||
of Srtcp gives Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)). | ||||
If we assume every report is a compound RTCP packet (i.e., Nnc = 0), | ||||
the frame duration Tf = 20ms, and an RTCP report is sent for every | ||||
second frame (i.e., 25 RTCP reports per second), this expression | ||||
gives the needed RTCP bandwidth Brtcp = 53.1kbps. Increasing the | ||||
frame duration, or reducing the frequency of reports, reduces the | ||||
RTCP bandwidth, as shown below: | ||||
+--------------+-------------+----------------+ | ||||
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | ||||
+--------------+-------------+----------------+ | ||||
| 20ms | 2 | 53.1 | | ||||
| 20ms | 4 | 27.3 | | ||||
| 20ms | 8 | 14.5 | | ||||
| 20ms | 16 | 8.01 | | ||||
| 60ms | 2 | 17.7 | | ||||
| 60ms | 4 | 9.1 | | ||||
| 60ms | 8 | 4.8 | | ||||
| 60ms | 16 | 2.66 | | ||||
+--------------+-------------+----------------+ | ||||
Table 1: Required RTCP bandwidth for VoIP feedback | ||||
The final row of the table (60ms frames, report every 16 frames) | ||||
sends RTCP reports once per second, giving an RTCP bandwidth of | ||||
2.66kbps. | ||||
The overhead can be reduced by sending some reports in non-compound | ||||
RTCP packets [RFC5506]. For example, if we alternate compound and | ||||
non-compound RTCP packets, i.e., Nnc = 1, the calculation gives: | ||||
+--------------+-------------+----------------+ | ||||
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | ||||
+--------------+-------------+----------------+ | ||||
| 20ms | 2 | 37.5 | | ||||
| 20ms | 4 | 19.5 | | ||||
| 20ms | 8 | 10.5 | | ||||
| 20ms | 16 | 6.1 | | ||||
| 60ms | 2 | 12.5 | | ||||
| 60ms | 4 | 6.5 | | ||||
| 60ms | 8 | 3.5 | | ||||
| 60ms | 16 | 2.01 | | ||||
+--------------+-------------+----------------+ | ||||
Table 2: Required RTCP bandwidth for VoIP feedback (alternating | ||||
compound and non-compound reports) | ||||
The RTCP bandwidth needed for 60ms frames, reporting every 16 frames | ||||
(once per second), can be seen to drop to 2.01kbps. This calculation | ||||
can be repeated for other patterns of compound and non-compound RTCP | ||||
packets, feedback frequency, and frame duration, as needed. | ||||
Note: To achieve the RTCP transmission intervals above the RTP/SAVPF | ||||
profile with T_rr_interval=0 is used, since even when using the | ||||
reduced minimal transmission interval, the RTP/SAVP profile would | ||||
only allow sending RTCP at most every 0.11s (every third frame of | ||||
video). Using RTP/SAVPF with T_rr_interval=0 however is capable of | ||||
fully utilizing the configured 5% RTCP bandwidth fraction. | ||||
3.2. Scenario 2: Point-to-Point Video Conference | ||||
Consider a point to point video call between two end systems. There | ||||
will be four RTP flows in this scenario, two audio and two video, | ||||
with all four flows being active for essentially all the time (the | ||||
audio flows will likely use voice activity detection and comfort | ||||
noise to reduce the packet rate during silent periods, and does not | ||||
cause the transmissions to stop). | ||||
Assume all four flows are sent in a single RTP session, each using a | Assume all four flows are sent in a single RTP session, each using a | |||
separate SSRC; the RTCP reports from co-located audio and video SSRCs | separate SSRC; the RTCP reports from co-located audio and video SSRCs | |||
at each end point are aggregated [RFC3550], | at each end point are aggregated [I-D.ietf-avtcore-rtp-multi-stream]; | |||
[I-D.ietf-avtcore-rtp-multi-stream]; the optimisations in | the optimisations in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] | |||
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] are used; and | are used; and congestion control feedback is sent | |||
congestion control feedback is sent [I-D.dt-rmcat-feedback-message]. | [I-D.dt-rmcat-feedback-message]. | |||
When all members are senders, the RTCP timing rules in Section 6.2 | When all members are senders, the RTCP timing rules in Section 6.2 | |||
and 6.3 of [RFC3550] and [RFC4585] reduce to: | and 6.3 of [RFC3550] and [RFC4585] reduce to: | |||
rtcp_interval = avg_rtcp_size * n / rtcp_bw | rtcp_interval = avg_rtcp_size * n / rtcp_bw | |||
where n is the number of members in the session, the avg_rtcp_size is | where n is the number of members in the session, the avg_rtcp_size is | |||
measured in octets, and the rtcp_bw is the bandwidth available for | measured in octets, and the rtcp_bw is the bandwidth available for | |||
RTCP, measured in octets per second (this will typically be 5% of the | RTCP, measured in octets per second (this will typically be 5% of the | |||
session bandwidth). | session bandwidth). | |||
skipping to change at page 5, line 44 ¶ | skipping to change at page 7, line 49 ¶ | |||
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP XR | contain an RTCP SR packet, an RTCP SDES packet, and an RTCP XR | |||
congestion control feedback packet. The RTCP SR packet will contain | congestion control feedback packet. The RTCP SR packet will contain | |||
two report blocks, one for each of the remote SSRCs (the report for | two report blocks, one for each of the remote SSRCs (the report for | |||
the other local SSRC is suppressed by the reporting group extension), | the other local SSRC is suppressed by the reporting group extension), | |||
for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will | for a total of 28 + (2 * 24) = 76 octets. The RTCP SDES packet will | |||
comprise a header (4 octets), originating SSRC (4 octets), a CNAME | comprise a header (4 octets), originating SSRC (4 octets), a CNAME | |||
chunk, an RGRP chunk, a terminating chunk, and any padding. If the | chunk, an RGRP chunk, a terminating chunk, and any padding. If the | |||
CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it will be 18 | CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it will be 18 | |||
octets in size. The RGRP chunk similarly comprises 18 octets, and 3 | octets in size. The RGRP chunk similarly comprises 18 octets, and 3 | |||
octets of padding are needed, for a total of 48 octets. The RTCP XR | octets of padding are needed, for a total of 48 octets. The RTCP XR | |||
congestion control feedback report comprises an 8 octet XR header, | congestion control feedback report comprises an 8 octet XR header, an | |||
then for each of the remote audio and video SSRCs, a 12 octet report | 8 octet RC2F header, then for each of the remote audio and video | |||
header, and 2 octets per packet reported upon, and padding to a 4 | SSRCs, an 8 octet report header, and 2 octets per packet reported | |||
octet boundary, if needed; that is 8 + 12 + (2 * | upon, and padding to a 4 octet boundary, if needed; that is 8 + 8 + 8 | |||
video_packets_per_report) + 12 + (2 * audio_packets_per_report). = | + (2 * Nv) + 8 + (2 * Na) where Nv is the number of video packets per | |||
32 + (2 * video_packets_per_report) + (2 * audio_packets_per_report). | report, and Na is the number of audio packets per report. | |||
The compound RTCP packet will be 156 + (2 * video_packets_per_report) | ||||
+ (2 * audio_packets_per_report). | ||||
The resulting aggregate RTCP packet, containing both compound RTCP | The complete compound RTCP packet contains the RTCP packets from both | |||
packets, will be sent in UDP/IPv4 with no IP options and using Secure | the reporting and non-reporting SSRCs, an SRTP authentication tag, | |||
RTP, which adds 20 (IPv4) + 8 (UDP) + 14 (SRTP with 80 bit | and a UDP/IPv4 header. The size of this RTCP packet is therefore: | |||
Authentication tag) = 42 octets, the avg_rtcp_size will therefore be | 156 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet | |||
42 + 68 + 156 + (2 * video_packets_per_report) + (2 * | contains reports from two SSRCs, the RTCP packet size is halved | |||
audio_packets_per_report). (FIXME: this ignores padding in RTCP) | before use [I-D.ietf-avtcore-rtp-multi-stream]. Accordingly, we | |||
Since the aggregate RTCP packet contains reports from two SSRCs, the | define Sc = (156 + (2 * Nv) + (2 * Na))/2 for this scenario. | |||
avg_rtcp_packet size is halved before use | ||||
[I-D.ietf-avtcore-rtp-multi-stream]. The value n is this scenario is | ||||
4, and the rtcp_bw is assumed to be 5% of the session bandwidth. | ||||
How many packets does the RTCP XR congestion control feedback packet | How many packets does the RTCP XR congestion control feedback packet | |||
report on? This is obviously highly dependent on the choice of codec | report on? This is obviously highly dependent on the choice of codec | |||
and encoding parameters, and might be quite bursty if the codec sends | and encoding parameters, and might be quite bursty if the codec sends | |||
I-frames from which later frames are predicted. For now, assume | I-frames from which later frames are predicted. For now though, | |||
video_packets_per_second = (video_bit_rate_bps / 8) / mtu and | assume constant rate media with an MTU around 1500 octets, with | |||
video_packets_per_report = video_packets_per_seconds / fps. For | reports for both audio and video being aggregated and sent to align | |||
audio, assume 50 packets per second, with audio_packets_per_report | with video frames. This gives the following, assuming Nr =1 and Nnc | |||
based on the video frame rate (i.e., RTCP packets for the audio SSRC | = 0 (i.e., send a compound RTCP packet for each video frame, and no | |||
are aggregated with those from the video SSRC). | non-compound packets), and using the calculation from Scenario 1: | |||
Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)) | ||||
If it is desired to send RTCP feedback packets on average 30 times | +---------+---------+--------------+--------------+-----------------+ | |||
per second, to correspond to one RTCP report every frame for 30fps | | Data | Video | Video | Audio | Required RTCP | | |||
video, one can solve the above expressions to determine the session | | Rate | Frame | Packets per | Packets per | bandwidth: | | |||
bandwidth needed to give an RTCP reporting interval of 1/30 second. | | (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) | | |||
This is approximately 2.5Mbps. That is, provided the video session | +---------+---------+--------------+--------------+-----------------+ | |||
bandwidth is greater than approximately 2.5Mbps, one can report on | | 100 | 8 | 1 | 6 | 21 (21%) | | |||
each packet arrival (with ECN marks and arrival time) for every frame | | 200 | 16 | 1 | 3 | 41 (21%) | | |||
of 30 fps video, using existing RTCP mechanisms. This is not out of | | 350 | 30 | 1 | 2 | 76 (21%) | | |||
line with the expected session bandwidth for this type of | | 700 | 30 | 2 | 2 | 77 (11%) | | |||
application, suggesting the RTCP feedback can be used to provide per- | | 700 | 60 | 1 | 1 | 150 (21%) | | |||
frame congestion control feedback for WebRTC-style applications. | | 1024 | 30 | 3 | 2 | 78 ( 8%) | | |||
| 1400 | 60 | 2 | 1 | 152 (11%) | | ||||
| 2048 | 30 | 6 | 2 | 81 ( 4%) | | ||||
| 2048 | 60 | 3 | 1 | 154 ( 8%) | | ||||
| 4096 | 30 | 12 | 2 | 86 ( 2%) | | ||||
| 4096 | 60 | 6 | 1 | 159 ( 4%) | | ||||
+---------+---------+--------------+--------------+-----------------+ | ||||
Note: To achieve the RTCP transmission intervals above the RTP/ | Table 3: Required RTCP bandwidth, reporting on every frame | |||
SAVPF profile with T_rr_interval=0 is used, since even when using | ||||
the reduced minimal transmission interval, the RTP/SAVP profile | ||||
would only allow sending RTCP at most every 0.11s (every third | ||||
frame of video). Using RTP/SAVPF with T_rr_interval=0 however is | ||||
capable of fully utilizing the configured 5% RTCP bandwidth | ||||
fraction. | ||||
3.3. Per-RTT Feedback | The RTCP bandwidth needed scales inversely with Nr. That is, it is | |||
halved if Nr=2 (report on every second packet), is reduced to one- | ||||
third if Nr=3 (report on every third packet), and so on. | ||||
The arguments made in Section 3.2 apply to this case as well. The | The needed RTCP bandwidth scales as a percentage of the data rate | |||
network RTT will usually be larger than the media framing interval, | following the ratio of the frame rate to the data rate. As can be | |||
so sending feedback per RTT is less of a load on RTCP than sending | seen from the table above, the RTCP bandwidth needed is a significant | |||
feedback per frame. | fraction of the media rate, if reporting on every frame for low rate | |||
video. This can be solved by reporting less often at lower rates. | ||||
For example, to report on every frame of 100kbps/8fps video requires | ||||
the RTCP bandwidth to be 21% of the media rate; reporting every | ||||
fourth frame (i.e., twice per second) reduces this overhead to 5%. | ||||
Use of reduced size RTCP [RFC5506] would allow the SR and SDES | ||||
packets to be omitted from some reports. These "non-compound" | ||||
(actually, compound but reduced size in this case) RTCP packets would | ||||
contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP | ||||
SDES RGRP packet and a congestion control feedback packet from the | ||||
reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na | ||||
octets, plus UDP/IP header. That is, Snc = (96 + 2*Nv + 2*Na)/2. | ||||
Repeating the analysis above, but alternating compound and non- | ||||
compound reports, i.e., setting Nnc = 1, gives: | ||||
+---------+---------+--------------+--------------+-----------------+ | ||||
| Data | Video | Video | Audio | Required RTCP | | ||||
| Rate | Frame | Packets per | Packets per | bandwidth: | | ||||
| (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) | | ||||
+---------+---------+--------------+--------------+-----------------+ | ||||
| 100 | 8 | 1 | 6 | 18 (18%) | | ||||
| 200 | 16 | 1 | 3 | 33 (17%) | | ||||
| 350 | 30 | 1 | 2 | 62 (18%) | | ||||
| 700 | 30 | 2 | 2 | 62 ( 9%) | | ||||
| 700 | 60 | 1 | 1 | 121 (17%) | | ||||
| 1024 | 30 | 3 | 2 | 64 ( 6%) | | ||||
| 1400 | 60 | 2 | 1 | 123 ( 9%) | | ||||
| 2048 | 30 | 6 | 2 | 66 ( 3%) | | ||||
| 2048 | 60 | 3 | 1 | 125 ( 6%) | | ||||
| 4096 | 30 | 12 | 2 | 72 ( 2%) | | ||||
| 4096 | 60 | 6 | 1 | 131 ( 3%) | | ||||
+---------+---------+--------------+--------------+-----------------+ | ||||
Table 4: Required RTCP bandwidth, reporting on every frame, with | ||||
reduced-size reports | ||||
The use of reduced-size RTCP gives a noticeable reduction in the | ||||
needed RTCP bandwidth, and can be combined with reporting every few | ||||
frames rather than every frames. Overall, it is clear that the RTCP | ||||
overhead can be reasonable across the range of data and frame rates, | ||||
if RTCP is configured carefully. | ||||
3.3. Scenario 3: Group Video Conference | ||||
(tbd) | ||||
3.4. Scenario 4: Screen Sharing | ||||
(tbd) | ||||
4. Discussion and Conclusions | 4. Discussion and Conclusions | |||
RTCP as it is currently specified cannot be used to send per-packet | RTCP as it is currently specified cannot be used to send per-packet | |||
congestion feedback. RTCP can, however, be used to send congestion | congestion feedback. RTCP can, however, be used to send congestion | |||
feedback on each frame of video sent, provided the session bandwidth | feedback on each frame of video sent, provided the session bandwidth | |||
exceeds a couple of megabits per second (the exact rate depending on | exceeds a couple of megabits per second (the exact rate depending on | |||
the number of session participants, the RTCP bandwidth fraction, and | the number of session participants, the RTCP bandwidth fraction, and | |||
what RTCP extensions are enabled, and how much detail of feedback is | what RTCP extensions are enabled, and how much detail of feedback is | |||
needed). RTCP can likely also be used to send feedback on a per-RTT | needed). For lower rate sessions, the overhead of reporting on every | |||
basis, provided the RTT is not too low. | frame becomes high, but can be reduced to something reasonable by | |||
sending reports once per N frames (e.g., every second frame), or by | ||||
sending non-compound RTCP reports in between the regular reports. | ||||
If it is desired to use RTCP in something close to it's current form | If it is desired to use RTCP in something close to it's current form | |||
for congestion feedback in WebRTC, the multimedia congestion control | for congestion feedback in WebRTC, the multimedia congestion control | |||
algorithm needs be designed to work with feedback sent roughly each | algorithm needs be designed to work with feedback sent every few | |||
frame or each RTT, rather than per packet, since that fits within the | frames, since that fits within the limitations of RTCP. That | |||
limitations of RTCP. That feedback can be a little more complex than | feedback can be a little more complex than just an acknowledgement, | |||
just an acknowledgement, provided care is taken to consider the | provided care is taken to consider the impact of the extra feedback | |||
impact of the extra feedback on the overhead, possibly allowing for a | on the overhead, possibly allowing for a degree of semantic feedback, | |||
degree of semantic feedback, meaningful to the codec layer as well as | meaningful to the codec layer as well as the congestion control | |||
the congestion control algorithm. | algorithm. | |||
The format described in [I-D.dt-rmcat-feedback-message] seems | ||||
sufficient for the needs of congestion control feedback. There is | ||||
little point optimising this format: the main overhead comes from the | ||||
UDP/IP headers and the other RTCP packets included in the compound | ||||
packets, and can be lowered by using the [RFC5506] extensions and | ||||
sending reports less frequently. | ||||
Further study of the scenarios of interest is needed, to ensure that | Further study of the scenarios of interest is needed, to ensure that | |||
the analysis presented is applicable to other media topologies, and | the analysis presented is applicable to other media topologies, and | |||
to sessions with different data rates and sizes of membership. | to sessions with different data rates and sizes of membership. | |||
5. Security Considerations | 5. Security Considerations | |||
The security considerations of [RFC3550], [RFC4585], and [RFC5124] | An attacker that can modify or spoof RTCP congestion control feedback | |||
apply. | packets can manipulate the sender behaviour to cause denial of | |||
service. This can be prevented by authentication and integrity | ||||
protection of RTCP packets, for example using the secure RTP profile | ||||
[RFC3711][RFC5124], or by other means as discussed in [RFC7201]. | ||||
6. IANA Considerations | 6. IANA Considerations | |||
There are no actions for IANA. | There are no actions for IANA. | |||
7. Acknowledgements | 7. Acknowledgements | |||
Thanks to Magnus Westerlund for his feedback on Section 3.2. | Thanks to Magnus Westerlund and the members of the RMCAT feedback | |||
design team for their feedback. | ||||
8. Informative References | 8. Informative References | |||
[I-D.dt-rmcat-feedback-message] | [I-D.dt-rmcat-feedback-message] | |||
Sarker, Z., Perkins, D., Singh, V., and D. Ramalho, "RTP | Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP | |||
Control Protocol (RTCP) Feedback for Congestion Control", | Control Protocol (RTCP) Feedback for Congestion Control", | |||
draft-dt-rmcat-feedback-message-00 (work in progress), | draft-dt-rmcat-feedback-message-01 (work in progress), | |||
July 2016. | October 2016. | |||
[I-D.ietf-avtcore-rtp-multi-stream] | [I-D.ietf-avtcore-rtp-multi-stream] | |||
Lennox, J., Westerlund, M., Wu, Q., and D. Perkins, | Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, | |||
"Sending Multiple RTP Streams in a Single RTP Session", | "Sending Multiple RTP Streams in a Single RTP Session", | |||
draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), | draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), | |||
December 2015. | December 2015. | |||
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] | [I-D.ietf-avtcore-rtp-multi-stream-optimisation] | |||
Lennox, J., Westerlund, M., Wu, Q., and D. Perkins, | Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, | |||
"Sending Multiple RTP Streams in a Single RTP Session: | "Sending Multiple RTP Streams in a Single RTP Session: | |||
Grouping RTCP Reception Statistics and Other Feedback", | Grouping RTCP Reception Statistics and Other Feedback", | |||
draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work | draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work | |||
in progress), March 2016. | in progress), March 2016. | |||
[I-D.ietf-rtcweb-rtp-usage] | [I-D.ietf-rtcweb-rtp-usage] | |||
Perkins, D., Westerlund, M., and J. Ott, "Web Real-Time | Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time | |||
Communication (WebRTC): Media Transport and Use of RTP", | Communication (WebRTC): Media Transport and Use of RTP", | |||
draft-ietf-rtcweb-rtp-usage-26 (work in progress), March | draft-ietf-rtcweb-rtp-usage-26 (work in progress), March | |||
2016. | 2016. | |||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||
July 2003, <http://www.rfc-editor.org/info/rfc3550>. | July 2003, <http://www.rfc-editor.org/info/rfc3550>. | |||
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., | [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., | |||
"RTP Control Protocol Extended Reports (RTCP XR)", | "RTP Control Protocol Extended Reports (RTCP XR)", | |||
RFC 3611, DOI 10.17487/RFC3611, November 2003, | RFC 3611, DOI 10.17487/RFC3611, November 2003, | |||
<http://www.rfc-editor.org/info/rfc3611>. | <http://www.rfc-editor.org/info/rfc3611>. | |||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | ||||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | ||||
RFC 3711, DOI 10.17487/RFC3711, March 2004, | ||||
<http://www.rfc-editor.org/info/rfc3711>. | ||||
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | |||
"Extended RTP Profile for Real-time Transport Control | "Extended RTP Profile for Real-time Transport Control | |||
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | |||
DOI 10.17487/RFC4585, July 2006, | DOI 10.17487/RFC4585, July 2006, | |||
<http://www.rfc-editor.org/info/rfc4585>. | <http://www.rfc-editor.org/info/rfc4585>. | |||
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for | [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for | |||
Real-time Transport Control Protocol (RTCP)-Based Feedback | Real-time Transport Control Protocol (RTCP)-Based Feedback | |||
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February | (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February | |||
2008, <http://www.rfc-editor.org/info/rfc5124>. | 2008, <http://www.rfc-editor.org/info/rfc5124>. | |||
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size | ||||
Real-Time Transport Control Protocol (RTCP): Opportunities | ||||
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April | ||||
2009, <http://www.rfc-editor.org/info/rfc5506>. | ||||
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, | [RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, | |||
"Guidelines for Choosing RTP Control Protocol (RTCP) | "Guidelines for Choosing RTP Control Protocol (RTCP) | |||
Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, | Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, | |||
September 2013, <http://www.rfc-editor.org/info/rfc7022>. | September 2013, <http://www.rfc-editor.org/info/rfc7022>. | |||
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | ||||
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, | ||||
<http://www.rfc-editor.org/info/rfc7201>. | ||||
Author's Address | Author's Address | |||
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 | |||
End of changes. 30 change blocks. | ||||
125 lines changed or deleted | 301 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/ |