draft-ietf-rmcat-rtp-cc-feedback-02.txt   draft-ietf-rmcat-rtp-cc-feedback-03.txt 
Network Working Group C. Perkins Network Working Group C. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Intended status: Informational October 31, 2016 Intended status: Informational November 14, 2016
Expires: May 4, 2017 Expires: May 18, 2017
RTP Control Protocol (RTCP) Feedback for Congestion Control in RTP Control Protocol (RTCP) Feedback for Congestion Control in
Interactive Multimedia Conferences Interactive Multimedia Conferences
draft-ietf-rmcat-rtp-cc-feedback-02 draft-ietf-rmcat-rtp-cc-feedback-03
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 May 4, 2017. This Internet-Draft will expire on May 18, 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 5, line 9 skipping to change at page 5, line 9
header, 16 octets of data, and 2 octets of padding, for a total SDES 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 packet size of 28 octets. The RC2F packets contains an XR block
header and SSRC (8 octets), a block type and timestamp (8 octets), header and SSRC (8 octets), a block type and timestamp (8 octets),
the SSRC, beginning and ending sequence numbers (8 octets), and 2*Nr 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, 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. 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 This gives a total compound RTCP packet size of Sc = 132 + 2*Nr
octets. octets.
The non-compound RTCP packets will comprise just the RC2F packet with 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 a UDP/IP header. It can be seen that these packets will be Snc = 48
+ 2*Nr octets in size. + 2*Nr octets in size.
The RTCP reporting interval calculation ([RFC3550], Section 6.2) for The RTCP reporting interval calculation ([RFC3550], Section 6.2) for
a two-party session where both participants are senders, reduces to a two-party session where both participants are senders, reduces to
Trtcp = n * Srtcp/Brtcp where Srtcp = (Sc + Nnc * Snc)/(1 + Nnc) is Trtcp = n * Srtcp/Brtcp where Srtcp = (Sc + Nnc * Snc)/(1 + Nnc) is
the average RTCP packet size in octets, Brtcp is the bandwidth the average RTCP packet size in octets, Brtcp is the bandwidth
allocated to RTCP in octets per second, and n is the number of allocated to RTCP in octets per second, and n is the number of
participants (n=2 in this scenario). participants (n=2 in this scenario).
To ensure a report is sent every Nr frames, it is necessary to set To ensure a report is sent every Nr frames, it is necessary to set
skipping to change at page 6, line 12 skipping to change at page 6, line 12
sends RTCP reports once per second, giving an RTCP bandwidth of sends RTCP reports once per second, giving an RTCP bandwidth of
2.66kbps. 2.66kbps.
The overhead can be reduced by sending some reports in non-compound The overhead can be reduced by sending some reports in non-compound
RTCP packets [RFC5506]. For example, if we alternate compound and RTCP packets [RFC5506]. For example, if we alternate compound and
non-compound RTCP packets, i.e., Nnc = 1, the calculation gives: non-compound RTCP packets, i.e., Nnc = 1, the calculation gives:
+--------------+-------------+----------------+ +--------------+-------------+----------------+
| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) | | Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
| 20ms | 2 | 37.5 | | 20ms | 2 | 36.7 |
| 20ms | 4 | 19.5 | | 20ms | 4 | 19.1 |
| 20ms | 8 | 10.5 | | 20ms | 8 | 10.4 |
| 20ms | 16 | 6.1 | | 20ms | 16 | 6.0 |
| 60ms | 2 | 12.5 | | 60ms | 2 | 12.2 |
| 60ms | 4 | 6.5 | | 60ms | 4 | 6.4 |
| 60ms | 8 | 3.5 | | 60ms | 8 | 3.5 |
| 60ms | 16 | 2.01 | | 60ms | 16 | 2.0 |
+--------------+-------------+----------------+ +--------------+-------------+----------------+
Table 2: Required RTCP bandwidth for VoIP feedback (alternating Table 2: Required RTCP bandwidth for VoIP feedback (alternating
compound and non-compound reports) compound and non-compound reports)
The RTCP bandwidth needed for 60ms frames, reporting every 16 frames The RTCP bandwidth needed for 60ms frames, reporting every 16 frames
(once per second), can be seen to drop to 2.01kbps. This calculation (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 can be repeated for other patterns of compound and non-compound RTCP
packets, feedback frequency, and frame duration, as needed. packets, feedback frequency, and frame duration, as needed.
skipping to change at page 8, line 10 skipping to change at page 8, line 10
congestion control feedback report comprises an 8 octet XR header, an congestion control feedback report comprises an 8 octet XR header, an
8 octet RC2F header, then for each of the remote audio and video 8 octet RC2F header, then for each of the remote audio and video
SSRCs, an 8 octet report header, and 2 octets per packet reported SSRCs, an 8 octet report header, and 2 octets per packet reported
upon, and padding to a 4 octet boundary, if needed; that is 8 + 8 + 8 upon, and padding to a 4 octet boundary, if needed; that is 8 + 8 + 8
+ (2 * Nv) + 8 + (2 * Na) where Nv is the number of video packets per + (2 * Nv) + 8 + (2 * Na) where Nv is the number of video packets per
report, and Na is the number of audio packets per report. report, and Na is the number of audio packets per report.
The complete compound RTCP packet contains the RTCP packets from both The complete compound RTCP packet contains the RTCP packets from both
the reporting and non-reporting SSRCs, an SRTP authentication tag, the reporting and non-reporting SSRCs, an SRTP authentication tag,
and a UDP/IPv4 header. The size of this RTCP packet is therefore: and a UDP/IPv4 header. The size of this RTCP packet is therefore:
156 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet 252 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet
contains reports from two SSRCs, the RTCP packet size is halved contains reports from two SSRCs, the RTCP packet size is halved
before use [I-D.ietf-avtcore-rtp-multi-stream]. Accordingly, we before use [I-D.ietf-avtcore-rtp-multi-stream]. Accordingly, we
define Sc = (156 + (2 * Nv) + (2 * Na))/2 for this scenario. define Sc = (252 + (2 * Nv) + (2 * Na))/2 for this scenario.
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 though, I-frames from which later frames are predicted. For now though,
assume constant rate media with an MTU around 1500 octets, with assume constant rate media with an MTU around 1500 octets, with
reports for both audio and video being aggregated and sent to align reports for both audio and video being aggregated and sent to align
with video frames. This gives the following, assuming Nr =1 and Nnc with video frames. This gives the following, assuming Nr =1 and Nnc
= 0 (i.e., send a compound RTCP packet for each video frame, and no = 0 (i.e., send a compound RTCP packet for each video frame, and no
non-compound packets), and using the calculation from Scenario 1: non-compound packets), and using the calculation from Scenario 1:
Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)) Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc))
+---------+---------+--------------+--------------+-----------------+ +---------+---------+--------------+--------------+-----------------+
| Data | Video | Video | Audio | Required RTCP | | Data | Video | Video | Audio | Required RTCP |
| Rate | Frame | Packets per | Packets per | bandwidth: | | Rate | Frame | Packets per | Packets per | bandwidth: |
| (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) | | (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) |
+---------+---------+--------------+--------------+-----------------+ +---------+---------+--------------+--------------+-----------------+
| 100 | 8 | 1 | 6 | 21 (21%) | | 100 | 8 | 1 | 6 | 33.3 (33%) |
| 200 | 16 | 1 | 3 | 41 (21%) | | 200 | 16 | 1 | 3 | 65.0 (33%) |
| 350 | 30 | 1 | 2 | 76 (21%) | | 350 | 30 | 1 | 2 | 120.1 (35%) |
| 700 | 30 | 2 | 2 | 77 (11%) | | 700 | 30 | 2 | 2 | 121.9 (17%) |
| 700 | 60 | 1 | 1 | 150 (21%) | | 700 | 60 | 1 | 1 | 240.0 (34%) |
| 1024 | 30 | 3 | 2 | 78 ( 8%) | | 1024 | 30 | 3 | 2 | 122.8 (12%) |
| 1400 | 60 | 2 | 1 | 152 (11%) | | 1400 | 60 | 2 | 1 | 241.8 (17%) |
| 2048 | 30 | 6 | 2 | 81 ( 4%) | | 2048 | 30 | 6 | 2 | 125.6 ( 6%) |
| 2048 | 60 | 3 | 1 | 154 ( 8%) | | 2048 | 60 | 3 | 1 | 243.8 (12%) |
| 4096 | 30 | 12 | 2 | 86 ( 2%) | | 4096 | 30 | 12 | 2 | 131.3 ( 3%) |
| 4096 | 60 | 6 | 1 | 159 ( 4%) | | 4096 | 60 | 6 | 1 | 294.4 ( 6%) |
+---------+---------+--------------+--------------+-----------------+ +---------+---------+--------------+--------------+-----------------+
Table 3: Required RTCP bandwidth, reporting on every frame Table 3: Required RTCP bandwidth, reporting on every frame
The RTCP bandwidth needed scales inversely with Nr. That is, it is 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- 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. third if Nr=3 (report on every third packet), and so on.
The needed RTCP bandwidth scales as a percentage of the data rate The needed RTCP bandwidth scales as a percentage of the data rate
following the ratio of the frame rate to the data rate. As can be following the ratio of the frame rate to the data rate. As can be
skipping to change at page 9, line 26 skipping to change at page 9, line 26
reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na 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. octets, plus UDP/IP header. That is, Snc = (96 + 2*Nv + 2*Na)/2.
Repeating the analysis above, but alternating compound and non- Repeating the analysis above, but alternating compound and non-
compound reports, i.e., setting Nnc = 1, gives: compound reports, i.e., setting Nnc = 1, gives:
+---------+---------+--------------+--------------+-----------------+ +---------+---------+--------------+--------------+-----------------+
| Data | Video | Video | Audio | Required RTCP | | Data | Video | Video | Audio | Required RTCP |
| Rate | Frame | Packets per | Packets per | bandwidth: | | Rate | Frame | Packets per | Packets per | bandwidth: |
| (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) | | (kbps) | Rate | Report: Nv | Report: Na | Brtcp (kbps) |
+---------+---------+--------------+--------------+-----------------+ +---------+---------+--------------+--------------+-----------------+
| 100 | 8 | 1 | 6 | 18 (18%) | | 100 | 8 | 1 | 6 | 23.5 (23%) |
| 200 | 16 | 1 | 3 | 33 (17%) | | 200 | 16 | 1 | 3 | 45.5 (23%) |
| 350 | 30 | 1 | 2 | 62 (18%) | | 350 | 30 | 1 | 2 | 84.4 (24%) |
| 700 | 30 | 2 | 2 | 62 ( 9%) | | 700 | 30 | 2 | 2 | 85.3 (12%) |
| 700 | 60 | 1 | 1 | 121 (17%) | | 700 | 60 | 1 | 1 | 166.9 (24%) |
| 1024 | 30 | 3 | 2 | 64 ( 6%) | | 1024 | 30 | 3 | 2 | 86.2 ( 8%) |
| 1400 | 60 | 2 | 1 | 123 ( 9%) | | 1400 | 60 | 2 | 1 | 168.8 (12%) |
| 2048 | 30 | 6 | 2 | 66 ( 3%) | | 2048 | 30 | 6 | 2 | 89.1 ( 4%) |
| 2048 | 60 | 3 | 1 | 125 ( 6%) | | 2048 | 60 | 3 | 1 | 170.6 ( 8%) |
| 4096 | 30 | 12 | 2 | 72 ( 2%) | | 4096 | 30 | 12 | 2 | 94.7 ( 2%) |
| 4096 | 60 | 6 | 1 | 131 ( 3%) | | 4096 | 60 | 6 | 1 | 176.3 ( 4%) |
+---------+---------+--------------+--------------+-----------------+ +---------+---------+--------------+--------------+-----------------+
Table 4: Required RTCP bandwidth, reporting on every frame, with Table 4: Required RTCP bandwidth, reporting on every frame, with
reduced-size reports reduced-size reports
The use of reduced-size RTCP gives a noticeable reduction in the The use of reduced-size RTCP gives a noticeable reduction in the
needed RTCP bandwidth, and can be combined with reporting every few needed RTCP bandwidth, and can be combined with reporting every few
frames rather than every frames. Overall, it is clear that the RTCP frames rather than every frames. Overall, it is clear that the RTCP
overhead can be reasonable across the range of data and frame rates, overhead can be reasonable across the range of data and frame rates,
if RTCP is configured carefully. if RTCP is configured carefully.
 End of changes. 10 change blocks. 
36 lines changed or deleted 36 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/