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/