draft-ietf-rmcat-rtp-cc-feedback-09.txt   draft-ietf-rmcat-rtp-cc-feedback-10.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 11, 2022 Intended status: Informational July 11, 2022
Expires: January 12, 2023 Expires: January 12, 2023
Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in
Interactive Multimedia Conferences Interactive Multimedia Conferences
draft-ietf-rmcat-rtp-cc-feedback-09 draft-ietf-rmcat-rtp-cc-feedback-10
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 4, line 9 skipping to change at page 4, line 9
loop to be stable and responsive while keeping the overhead loop to be stable and responsive while keeping the overhead
reasonable when the feedback cannot be piggybacked onto returning reasonable when the feedback cannot be piggybacked onto returning
data. In this case, it is important to note that RTCP can send much data. In this case, it is important to note that RTCP can send much
more detailed feedback than simple acknowledgements. For example, if more detailed feedback than simple acknowledgements. For example, if
it were useful, it could be possible to use an RTCP extended report it were useful, it could be possible to use an RTCP extended report
(XR) packet [RFC3611] to send feedback once per RTT comprising a (XR) packet [RFC3611] to send feedback once per RTT comprising a
bitmap of lost and received packets, with reception times, over that bitmap of lost and received packets, with reception times, over that
RTT. As long as feedback is sent frequently enough that the control RTT. As long as feedback is sent frequently enough that the control
loop is stable, and the sender is kept informed when data leaves the loop is stable, and the sender is kept informed when data leaves the
network (to provide an equivalent to ACK clocking in TCP), it is not network (to provide an equivalent to ACK clocking in TCP), it is not
necessary to report on every packet at the instant it is received necessary to report on every packet at the instant it is received.
(indeed, it is unlikely that a video codec can react instantly to a Indeed, it is unlikely that a video codec can react instantly to a
rate change anyway, and there is little point in providing feedback rate change, and there is little point in providing feedback more
more often than the codec can adapt). often than the codec can adapt. This suggests that an RTP receiver
ought to be configured to provide feedback at a rate that matches the
rate of adaptation of the sender. In the best case, this will match
the media frame rate, but might often be slower.
Reducing the feedback frequency compared to TCP will reduce feedback Reducing the feedback frequency compared to TCP will reduce feedback
overhead but will lead multimedia flows to adapt to congestion more overhead but will lead multimedia flows to adapt to congestion more
slowly than TCP, raising concerns about inter-flow fairness. Similar slowly than TCP, raising concerns about inter-flow fairness. Similar
concerns are noted in [RFC5348], and accordingly the congestion concerns are noted in [RFC5348], and accordingly the congestion
control algorithm described therein aims for "reasonable" fairness control algorithm described therein aims for "reasonable" fairness
and a sending rate that is "generally within a factor of two" of that and a sending rate that is "generally within a factor of two" of that
TCP would achieve under the same conditions. It is to be noted, TCP would achieve under the same conditions. It is to be noted,
however, that TCP exhibits inter-flow unfairness when flows with however, that TCP exhibits inter-flow unfairness when flows with
differing round-trip times compete, and stretch acknowledgements due differing round-trip times compete, and stretch acknowledgements due
skipping to change at page 8, line 24 skipping to change at page 8, line 24
audio flows will likely use voice activity detection and comfort audio flows will likely use voice activity detection and comfort
noise to reduce the packet rate during silent periods, but this does noise to reduce the packet rate during silent periods, but this does
not cause the transmissions to stop). 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 the co-located audio and video separate SSRC. The RTCP reports from the co-located audio and video
SSRCs at each end point are aggregated [RFC8108], the optimisations SSRCs at each end point are aggregated [RFC8108], the optimisations
in [RFC8861] are used, and RTCP congestion control feedback is sent in [RFC8861] are used, and RTCP congestion control feedback is sent
[RFC8888]. [RFC8888].
When all members are senders, the RTCP reporting interval calculation As in Section 3.1, when all members are senders the RTCP reporting
in Section 6.2 and 6.3 of [RFC3550] and [RFC4585] reduces to: interval calculation in Section 6.2 and 6.3 of [RFC3550] and
[RFC4585] reduces to:
Trtcp = n * Srtcp / Brtcp Trtcp = n * Srtcp / Brtcp
where n is the number of members in the session, Srtcp is the average where n is the number of members in the session, Srtcp is the average
RTCP packet size in octets, and the Brtcp is the RTCP bandwidth in RTCP packet size in octets, and the Brtcp is the RTCP bandwidth in
octets per second. octets per second.
The average RTCP packet size, Srtcp, depends on the amount of The average RTCP packet size, Srtcp, depends on the amount of
feedback sent in each RTCP packet, on the number of members in the feedback sent in each RTCP packet, on the number of members in the
session, on the size of source description (RTCP SDES) information session, on the size of source description (RTCP SDES) information
skipping to change at page 9, line 4 skipping to change at page 9, line 5
When the RTCP reporting group extensions are used, one of these SSRCs When the RTCP reporting group extensions are used, one of these SSRCs
will be a reporting SSRC, to which the other SSRC will have delegated will be a reporting SSRC, to which the other SSRC will have delegated
its reports. No reduced-size RTCP packets are sent. its reports. No reduced-size RTCP packets are sent.
The aggregated compound RTCP packet from the non-reporting SSRC will The aggregated compound RTCP packet from the non-reporting SSRC will
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS contain an RTCP SR packet, an RTCP SDES packet, and an RTCP RGRS
packet. The RTCP SR packet contains the 28 octet header and sender packet. The RTCP SR packet contains the 28 octet header and sender
information, but no report blocks (since the reporting is delegated). information, but no report blocks (since the reporting is delegated).
The RTCP SDES packet will comprise a header (4 octets), originating The RTCP SDES packet will comprise a header (4 octets), originating
SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding.
If the CNAME follows [RFC7022] and [RFC8834] the CNAME chunk will be
If the CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in 18 octets in size, and will be followed one octet of padding and one
size, and will need 1 octet of padding, making the SDES packet 28 terminating null octet to align the SDES packet to the required
32-bit boundary ([RFC3550], section 6.5), making the SDES packet 28
octets in size. The RTCP RGRS packet will be 12 octets in size. octets in size. The RTCP RGRS packet will be 12 octets in size.
This gives a total of 28 + 28 + 12 = 68 octets. This gives a total of 28 + 28 + 12 = 68 octets.
The aggregated compound RTCP packet from the reporting SSRC will The aggregated compound RTCP packet from the reporting SSRC will
contain an RTCP SR packet, an RTCP SDES packet, and an RTCP contain an RTCP SR packet, an RTCP SDES packet, and an RTCP
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
 End of changes. 4 change blocks. 
10 lines changed or deleted 15 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/