draft-ietf-rmcat-rtp-cc-feedback-00.txt   draft-ietf-rmcat-rtp-cc-feedback-01.txt 
Network Working Group C. S. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Informational July 24, 2014 Intended status: Informational July 8, 2016
Expires: January 25, 2015 Expires: January 9, 2017
Using RTP Control Protocol (RTCP) Feedback for Unicast Multimedia Using RTP Control Protocol (RTCP) Feedback for Unicast Multimedia
Congestion Control Congestion Control
draft-ietf-rmcat-rtp-cc-feedback-00 draft-ietf-rmcat-rtp-cc-feedback-01
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 25, 2015. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. 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. Per-packet Feedback . . . . . . . . . . . . . . . . . . . 4
3.2. Per-frame Feedback . . . . . . . . . . . . . . . . . . . 4 3.2. Per-frame Feedback . . . . . . . . . . . . . . . . . . . 4
3.3. Per-RTT Feedback . . . . . . . . . . . . . . . . . . . . 6 3.3. Per-RTT Feedback . . . . . . . . . . . . . . . . . . . . 6
4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 6 4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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 4, line 41 skipping to change at page 4, line 40
3.2. Per-frame Feedback 3.2. Per-frame Feedback
Consider one of the simplest scenarios for WebRTC: a point to point Consider one of the simplest scenarios for WebRTC: a point to point
video call between two end systems. There will be four RTP flows in 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 this scenario, two audio and two video, with all four flows being
active for essentially all the time (the audio flows will likely use active for essentially all the time (the audio flows will likely use
voice activity detection and comfort noise to reduce the packet rate voice activity detection and comfort noise to reduce the packet rate
during silent periods, and does not cause the transmissions to stop). 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. Further, assume each SSRC sends RTCP reports for all separate SSRC; the RTCP reports from co-located audio and video SSRCs
other SSRCs in the session (i.e., the optimisations in at each end point are aggregated [RFC3550],
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] are not used, giving [I-D.ietf-avtcore-rtp-multi-stream]; the optimisations in
the worst case for the RTCP overhead). When all members are senders [I-D.ietf-avtcore-rtp-multi-stream-optimisation] are used; and
like this, the RTCP timing rules in Sections 6.2 and 6.3 of [RFC3550] congestion control feedback is sent [I-D.dt-rmcat-feedback-message].
and [RFC4585] reduce to:
rtcp_interval = avg_rtcp_size * n / rtcp_bw When all members are senders, the RTCP timing rules in Section 6.2
and 6.3 of [RFC3550] and [RFC4585] reduce to:
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).
The average RTCP size will depend on the amount of feedback that is The average RTCP size will depend on the amount of feedback that is
sent in each RTCP packet, on the number of members in the session, sent in each RTCP packet, on the number of members in the session, on
and on the size of source description (RTCP SDES) information sent. the size of source description (RTCP SDES) information sent, and on
the amount of congestion control feedback sent in each packet.
As a baseline, each RTCP packet will be a compound RTCP packet that As a baseline, each RTCP packet will be a compound RTCP packet that
contains an RTCP SR and an RTCP SDES packet. In the scenario above, contains an aggregate of a compound RTCP packet generated by the
each RTCP SR packet will contain three report blocks, once for each video SSRC and a compound RTCP packet generated by the audio SSRC.
of the other RTP SSRCs sending data, for a total of 100 octets (this Since the RTCP reporting group extensions are used, one of these
is 8 octets header, 20 octets sender info, and 3 * 24 octets report SSRCs will be a reporting SSRC, and the other will delegate its
blocks). The RTCP SDES packet will comprise a header (4 octets), an reports to that.
originating SSRC (4 octets), a CNAME chunk, and padding. If the
CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it will be 19 The aggregated compound RTCP packet from the non-reporting SSRC will
octets in size, and require 1 octet of padding. The resulting contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS
compound RTCP packet will be 128 octets in size. If sent in UDP/IPv4 packet. The RTCP SR packet contains the 28 octet header and sender
with no IP options and using Secure RTP, which adds 20 (IPv4) + 8 information, but no report blocks (since the reporting is delegated).
(UDP) + 14 (SRTP with 80 bit Authentication tag), the avg_rtcp_size The RTCP SDES packet will comprise a header (4 octets), originating
will therefore be 170 octets, including the header overhead. The SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding.
value n is this scenario is 4, and the rtcp_bw is assumed to be 5% of If the CNAME follows [RFC7022] and [I-D.ietf-rtcweb-rtp-usage] it
the session bandwidth. will be 18 octets in size, and will need 1 octet of padding, making
the SDES packet 28 octets in size. The RTCP RGRS packet will be 12
octets in size. This gives a total of 28 + 28 + 12 = 68 octets.
The aggregated compound RTCP packet from the reporting SSRC will
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP XR
congestion control feedback packet. The RTCP SR packet will contain
two report blocks, one for each of the remote SSRCs (the report for
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
comprise a header (4 octets), originating SSRC (4 octets), a CNAME
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
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
congestion control feedback report comprises an 8 octet XR header,
then for each of the remote audio and video SSRCs, a 12 octet report
header, and 2 octets per packet reported upon, and padding to a 4
octet boundary, if needed; that is 8 + 12 + (2 *
video_packets_per_report) + 12 + (2 * audio_packets_per_report). =
32 + (2 * video_packets_per_report) + (2 * 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
packets, will be sent in UDP/IPv4 with no IP options and using Secure
RTP, which adds 20 (IPv4) + 8 (UDP) + 14 (SRTP with 80 bit
Authentication tag) = 42 octets, the avg_rtcp_size will therefore be
42 + 68 + 156 + (2 * video_packets_per_report) + (2 *
audio_packets_per_report). (FIXME: this ignores padding in RTCP)
Since the aggregate RTCP packet contains reports from two SSRCs, the
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
report on? This is obviously highly dependent on the choice of codec
and encoding parameters, and might be quite bursty if the codec sends
I-frames from which later frames are predicted. For now, assume
video_packets_per_second = (video_bit_rate_bps / 8) / mtu and
video_packets_per_report = video_packets_per_seconds / fps. For
audio, assume 50 packets per second, with audio_packets_per_report
based on the video frame rate (i.e., RTCP packets for the audio SSRC
are aggregated with those from the video SSRC).
If it is desired to send RTCP feedback packets on average 30 times 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 per second, to correspond to one RTCP report every frame for 30fps
video, one can invert the above rtcp_interval calculation to get an video, one can solve the above expressions to determine the session
rtcp_bw that gives an interval of 1/30th of a second or lower. This bandwidth needed to give an RTCP reporting interval of 1/30 second.
corresponds to an rtcp_bw of 20400 octets per second (since 1/30 = This is approximately 2.5Mbps. That is, provided the video session
170 * 4 / 20400). This is 163200 bits per second, which if 5% of the bandwidth is greater than approximately 2.5Mbps, one can report on
session bandwidth, gives a session bandwidth of approximately 3.3Mbps each packet arrival (with ECN marks and arrival time) for every frame
(i.e., 3.3Mbps media rate, plus an additional 5% for RTCP, to give a of 30 fps video, using existing RTCP mechanisms. This is not out of
total data rate of approximately 3.4Mbps). That is, RTCP can report line with the expected session bandwidth for this type of
on every frame of video provided the session bandwidth is 3.3Mbps or application, suggesting the RTCP feedback can be used to provide per-
larger, when every SSRC sends a report for every video frame (due to frame congestion control feedback for WebRTC-style applications.
randomisation inherent in the RTCP timing rules, the actual RTCP
transmission intervals will be within the range [0.0135, 0.0406]s,
but will maintain an average RTCP transmission interval of 0.033s).
This is not out of line with the expected session bandwidth for this
type of application, suggesting the RTCP feedback can be used to
provide per-frame congestion control feedback for WebRTC-style
applications.
Note: To achieve the RTCP transmission intervals above the RTP/ Note: To achieve the RTCP transmission intervals above the RTP/
SAVPF profile with T_rr_interval=0 is used, since even when using SAVPF profile with T_rr_interval=0 is used, since even when using
the reduced minimal transmission interval, the RTP/SAVP profile the reduced minimal transmission interval, the RTP/SAVP profile
would only allow sending RTCP at most every 0.11s (every third 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 frame of video). Using RTP/SAVPF with T_rr_interval=0 however is
capable of fully utilizing the configured 5% RTCP bandwidth capable of fully utilizing the configured 5% RTCP bandwidth
fraction. fraction.
If additional feedback beyond the standard report block is needed,
the session bandwidth needed will increase slightly. For example,
with an additional 20 octets data being reported in each RTCP packet,
the session bandwidth needed increases to 3.5Mbps for every SSRC to
be able to report on every frame.
The above calculations highlight the baseline feasibility of RTCP
congestion control feedback, but might not be the most appropriate
usage of the RTCP bandwidth of all applications. Depending on needs,
a less frequent usage of regular RTCP compound packets, controlled by
T_rr_interval combined with using the reduced size RTCP packets, can
achieve more frequent and useful reporting. Also the optimisations
defined in [I-D.ietf-avtcore-rtp-multi-stream-optimisation] will
reduce the amount of bandwidth consumed for reporting when each
endpoint has multiple SSRCs.
It might also seem unnecessary to assign the same fraction of the
RTCP bandwidth to reporting on the audio and video, since video is
much higher rate, and so is presumably more likely to cause
congestion. Sending audio and video in separate RTCP sessions with
their own RTCP bandwidth fraction would give essentially double the
RTCP bandwidth for each video source, since RTCP bandwidth fraction
would be shared between two reporting SSRCs, rather than between the
four reporting SSRCs in the single session case. This would hence
reduce the session bandwidth needed to allow reports on every frame.
Extensions to split RTCP bandwidth unequally between participants in
a single session could be defined to allow this to work with a single
RTP session on a single UDP port, or two standard RTP sessions could
be run on a single port, using a demultiplexing shim. RTCP already
allows for different bandwidth fractions between senders and
receivers, so this is a relatively small change to the protocol.
3.3. Per-RTT Feedback 3.3. Per-RTT Feedback
The arguments made in Section 3.2 apply to this case as well. The The arguments made in Section 3.2 apply to this case as well. The
network RTT will usually be larger than the media framing interval, network RTT will usually be larger than the media framing interval,
so sending feedback per RTT is less of a load on RTCP than sending so sending feedback per RTT is less of a load on RTCP than sending
feedback per frame. feedback per frame.
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
whether audio and video are sent in one or two RTP sessions). RTCP what RTCP extensions are enabled, and how much detail of feedback is
can likely also be used to send feedback on a per-RTT basis, provided needed). RTCP can likely also be used to send feedback on a per-RTT
the RTT is not too low. basis, provided the RTT is not too low.
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 roughly each
frame or each RTT, rather than per packet, since that fits within the frame or each RTT, rather than per packet, since that fits within the
limitations of RTCP. That feedback can be a little more complex than limitations of RTCP. That feedback can be a little more complex than
just an acknowledgement, provided care is taken to consider the just an acknowledgement, provided care is taken to consider the
impact of the extra feedback on the overhead, possibly allowing for a impact of the extra feedback on the overhead, possibly allowing for a
degree of semantic feedback, meaningful to the codec layer as well as degree of semantic feedback, meaningful to the codec layer as well as
the congestion control algorithm. the congestion control algorithm.
skipping to change at page 7, line 38 skipping to change at page 7, line 45
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 for his feedback on Section 3.2.
8. Informative References 8. Informative References
[I-D.dt-rmcat-feedback-message]
Sarker, Z., Perkins, D., Singh, V., and D. Ramalho, "RTP
Control Protocol (RTCP) Feedback for Congestion Control",
draft-dt-rmcat-feedback-message-00 (work in progress),
July 2016.
[I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, Q., and D. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
December 2015.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, Q., and D. Perkins,
"Sending Multiple Media 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-03 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-12 (work
in progress), July 2014. in progress), March 2016.
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, D., 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-16 (work in progress), July draft-ietf-rtcweb-rtp-usage-26 (work in progress), March
2014. 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, July 2003. Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
Protocol Extended Reports (RTCP XR)", RFC 3611, November "RTP Control Protocol Extended Reports (RTCP XR)",
2003. RFC 3611, DOI 10.17487/RFC3611, November 2003,
<http://www.rfc-editor.org/info/rfc3611>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
2006. DOI 10.17487/RFC4585, July 2006,
<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, February 2008. (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <http://www.rfc-editor.org/info/rfc5124>.
[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, September 2013. Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
September 2013, <http://www.rfc-editor.org/info/rfc7022>.
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. 24 change blocks. 
97 lines changed or deleted 122 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/