draft-ietf-rmcat-rtp-cc-feedback-08.txt		draft-ietf-rmcat-rtp-cc-feedback-09.txt
	Network Working Group C. Perkins		Network Working Group C. Perkins
	Internet-Draft University of Glasgow		Internet-Draft University of Glasgow
	Intended status: Informational December 28, 2021		Intended status: Informational July 11, 2022
	Expires: July 1, 2022		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-08		draft-ietf-rmcat-rtp-cc-feedback-09
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 July 1, 2022.		This Internet-Draft will expire on January 12, 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 . . . . . . . . . . . . . . 3		2. Considerations for RTCP Feedback . . . . . . . . . . . . . . 3
	3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5		3. What Feedback is Achievable With RTCP? . . . . . . . . . . . 5
	3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5		3.1. Scenario 1: Voice Telephony . . . . . . . . . . . . . . . 5
	3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 8		3.2. Scenario 2: Point-to-Point Video Conference . . . . . . . 8
	4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11		4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	8. Informative References . . . . . . . . . . . . . . . . . . . 12		8. Informative References . . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	control, or if some form of RTP extension is needed.		control, or if some form of RTP extension is needed.
	This memo considers unicast congestion feedback that can be sent		This memo considers unicast congestion feedback that can be sent
	using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version		using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version
	of the RTP/AVPF profile [RFC4585]). This profile was chosen as it		of the RTP/AVPF profile [RFC4585]). This profile was chosen as it
	forms the basis for media transport in WebRTC [RFC8834] systems.		forms the basis for media transport in WebRTC [RFC8834] systems.
	Nothing in this memo is specific to the secure version of the		Nothing in this memo is specific to the secure version of the
	profile, or to WebRTC, however. It is also assumed that the		profile, or to WebRTC, however. It is also assumed that the
	congestion control feedback mechanism described in [RFC8888], and		congestion control feedback mechanism described in [RFC8888], and
	common RTCP extensions for efficient feedback [RFC5506], [RFC8108],		common RTCP extensions for efficient feedback [RFC5506], [RFC8108],
	[RFC8861], [RFC8861], and [RFC8872] are available.		[RFC8861], and [RFC8872] are available.
	2. Possible Models for RTCP Feedback		2. Considerations for RTCP Feedback
	Several questions need to be answered when providing RTCP reception		Several questions need to be answered when providing RTCP reception
	quality feedback for congestion control purposes. These include:		quality feedback for congestion control purposes. These include:
	o How often is feedback needed?		o How often is feedback needed?
	o How much overhead is acceptable?		o How much overhead is acceptable?
	o How much, and what, data does each report contain?		o How much, and what, data does each report contain?
	skipping to change at page 3, line 37 ¶		skipping to change at page 3, line 37 ¶
	separate acknowledgement packets when those packets are much smaller		separate acknowledgement packets when those packets are much smaller
	than data packets.		than data packets.
	Frequent acknowledgements can become a problem, however, when there		Frequent acknowledgements can become a problem, however, when there
	is no return traffic on which to piggyback feedback, or if separate		is no return traffic on which to piggyback feedback, or if separate
	feedback and data packets are sent and the feedback is similar in		feedback and data packets are sent and the feedback is similar in
	size to the data being acknowledged. This can be the case for some		size to the data being acknowledged. This can be the case for some
	forms of media traffic, especially for voice over IP flows, leading		forms of media traffic, especially for voice over IP flows, leading
	to high overhead when using a transport protocol that sends frequent		to high overhead when using a transport protocol that sends frequent
	feedback. Approaches like in-network filtering of acknowledgements		feedback. Approaches like in-network filtering of acknowledgements
	can reduce the feedback frequency and overhead in some cases, but		have been proposed to reduce acknowledgement overheads on highly
	this so-called "stretch-ACK" behaviour is non-standard and not		asymmetric links (e.g., as mentioned in [RFC3449]) can also reduce
	guaranteed.		the feedback frequency and overhead for multimedia traffic, but this
			so-called "stretch-ACK" behaviour is non-standard and not guaranteed.
	Accordingly, when implementing congestion control for RTP-based		Accordingly, when implementing congestion control for RTP-based
	multimedia traffic, it might make sense to give the option of sending		multimedia traffic, it might make sense to give the option of sending
	congestion feedback less often than does TCP. For example, it might		congestion feedback less often than does TCP. For example, it might
	be possible to send a feedback packet once per video frame, or every		be possible to send a feedback packet once per video frame, or every
	few frames, or once per network round trip time (RTT). This could		few frames, or once per network round trip time (RTT). This could
	still give sufficiently frequent feedback for the congestion control		still give sufficiently frequent feedback for the congestion control
	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
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 39 ¶
	contribute to link utilization, and can affect the timing of other		contribute to link utilization, and can affect the timing of other
	traffic on the network. This can affect performance on some types of		traffic on the network. This can affect performance on some types of
	network, that can be impacted by the rate, timing, and size of		network, that can be impacted by the rate, timing, and size of
	feedback packets, as well as by the overall volume of feedback bytes.		feedback packets, as well as by the overall volume of feedback bytes.
	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 feedback is sent in		considered acceptable has to be determined. RTCP feedback 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 is generally acceptable,
	providing the ability to change this fraction. Is this still the		while providing the ability to change this fraction. Is this still
	case for congestion control feedback? Is there a desire to provide		the case for congestion control feedback? Is there a desire to
	more responsive feedback and congestion control, possibility with a		provide more responsive feedback and congestion control, possibly
	higher overhead? Or is lower overhead wanted, accepting that this		with a higher overhead? Or is lower overhead wanted, accepting that
	might reduce responsiveness of the congestion control algorithm?		this might reduce responsiveness of the congestion control algorithm?
	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? Is it useful		acceptable to send more complex feedback less often? Is it useful
	for the congestion control to receive frequent feedback, perhaps to		for the congestion control to receive frequent feedback, perhaps to
	provide more accurate round-trip time estimates, or to provide		provide more accurate round-trip time estimates, or to provide
	robustness in case feedback packets are lost, even if the media		robustness in case feedback packets are lost, even if the media
	sending rate cannot quickly be changed? Or is low-rate feedback,		sending rate cannot quickly be changed? Or is low-rate feedback,
	resulting in slowly responsive changes the sending rate, acceptable?		resulting in slowly responsive changes to the sending rate,
	Different combinations of congestion control algorithm and media		acceptable? Different combinations of congestion control algorithm
	codec might require different trade-offs, and the correct trade-off		and media codec might require different trade-offs, and the correct
	for interactive, self-paced, real-time multimedia traffic might not		trade-off for interactive, self-paced, real-time multimedia traffic
	be the same as that for TCP congestion control.		might not be the same as that for TCP congestion control.
	3. What Feedback is Achievable With RTCP?		3. What Feedback is Achievable With RTCP?
	The following sections illustrate how the RTCP congestion control		The following sections illustrate how the RTCP congestion control
	feedback report [RFC8888] can be used in different scenarios, and		feedback report [RFC8888] can be used in different scenarios, and
	illustrate the overheads of this approach.		illustrate the overheads of this approach.
	3.1. Scenario 1: Voice Telephony		3.1. Scenario 1: Voice Telephony
	In many ways, point-to-point voice telephony is the simplest scenario		In many ways, point-to-point voice telephony is the simplest scenario
	for congestion control, since there is only a single media stream to		for congestion control, since there is only a single media stream to
	control. It's complicated, however, by severe bandwidth constraints		control. It's complicated, however, by severe bandwidth constraints
	on the feedback, to keep the overhead manageable.		on the feedback, to keep the overhead manageable.
	Assume a two-party point-to-point voice-over-IP call, using RTP over		Assume a two-party point-to-point voice-over-IP call, using RTP over
	UDP/IP. A rate adaptive speech codec, such as Opus, is used, encoded		UDP/IP. A rate adaptive speech codec, such as Opus, is used, encoded
	into RTP packets in frames of duration Tf seconds (Tf = 20ms in many		into RTP packets in frames of duration Tf seconds (Tf = 0.020s in
	cases, but values up to 60ms are not uncommon). The congestion		many cases, but values up to 0.060s are not uncommon). The
	control algorithm requires feedback every Nr frames, i.e., every Nr *		congestion control algorithm requires feedback every Nr frames, i.e.,
	Tf seconds, to ensure effective control. Both parties in the call		every Nr * Tf seconds, to ensure effective control. Both parties in
	send speech data or comfort noise with sufficient frequency that they		the call send speech data or comfort noise with sufficient frequency
	are counted as senders for the purpose of the RTCP reporting interval		that they are counted as senders for the purpose of the RTCP
	calculation.		reporting interval calculation.
	RTCP feedback packets can be full, compound, RTCP feedback packets,		RTCP feedback packets can be full, compound, RTCP feedback packets,
	or non-compound RTCP packets [RFC5506]. A compound RTCP packet is		or reduced-size RTCP packets [RFC5506]. A compound RTCP packet is
	sent once for every Nnc non-compound RTCP packets.		sent once for every Nrs reduced-size RTCP packets.
	Compound RTCP packets contain a Sender Report (SR) packet, a Source		Compound RTCP packets contain a Sender Report (SR) packet, a Source
	Description (SDES) packet, and an RTP Congestion Control Feedback		Description (SDES) packet, and an RTP Congestion Control Feedback
	(CCFB) packet [RFC8888]. Non-compound RTCP packets contain only the		(CCFB) packet [RFC8888]. Reduced-size RTCP packets contain only the
	CCFB packet. Since each participant sends only a single RTP media		CCFB packet. Since each participant sends only a single RTP media
	stream, the extensions for RTCP report aggregation [RFC8108] and		stream, the extensions for RTCP report aggregation [RFC8108] and
	reporting group optimisation [RFC8861] are not used.		reporting group optimisation [RFC8861] are not used.
	Within each compound RTCP packet, the SR packet will contain a sender		Within each compound RTCP packet, the SR packet will contain a sender
	information block (28 octets) and a single reception report block (24		information block (28 octets) and a single reception report block (24
	octets), for a total of 52 octets. A minimal SDES packet will		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		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		octets) and a CNAME item, and if the recommendations for choosing the
	CNAME [RFC7022] are followed, the CNAME item will comprise a 2 octet		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		header, 16 octets of data, and 2 octets of padding, for a total SDES
	packet size of 28 octets. The CCFB packets contains an RTCP header		packet size of 28 octets. The CCFB packets contain an RTCP header
	and SSRC (8 octets), a report timestamp (4 octets), the SSRC,		and SSRC (8 octets), a report timestamp (4 octets), the SSRC,
	beginning and ending sequence numbers (8 octets), and 2*Nr octets of		beginning and ending sequence numbers (8 octets), and 2*Nr octets of
	reports, for a total of 20 + 2*Nr octets. The compound Secure RTCP		reports, for a total of 20 + 2*Nr octets. The compound Secure RTCP
	packet will include 4 octets of trailer followed by an 80 bit (10		packet will include 4 octets of trailer followed by an 80 bit (10
	octet) authentication tag if HMAC-SHA1 authentication is used. If		octet) authentication tag if HMAC-SHA1 authentication is used. If
	IPv4 is used, with no IP options, the UDP/IP header will be 28 octets		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 = 142 +		in size. This gives a total compound RTCP packet size of Sc = 142 +
	2*Nr octets.		2*Nr octets.
	The non-compound RTCP packets will comprise just the CCFB packet,		The reduced-size RTCP packets will comprise just the CCFB packet,
	SRTCP trailer and authentication tag, and a UDP/IP header. It can be		SRTCP trailer and authentication tag, and a UDP/IP header. It can be
	seen that these packets will be Snc = 62 + 2*Nr octets in size.		seen that these packets will be Srs = 62 + 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		Trtcp = n * Srtcp / Brtcp
	where Srtcp = (Sc + Nnc * Snc)/(1 + Nnc) is the average RTCP packet		where Srtcp = (Sc + Nrs * Srs)/(1 + Nrs) is the average RTCP packet
	size in octets, Brtcp is the bandwidth allocated to RTCP in octets		size in octets, Brtcp is the bandwidth allocated to RTCP in octets
	per second, and n is the number of participants in the RTP session		per second, and n is the number of participants in the RTP session
	(in this scenario, n = 2).		(in this scenario, n = 2).
	To ensure an RTCP report containing congestion control feedback is		To ensure an RTCP report containing congestion control feedback is
	sent after every Nr frames of audio, it is necessary to set the RTCP		sent after every Nr frames of audio, it is necessary to set the RTCP
	reporting interval Trtcp = Nr * Tf, which when substituted into the		reporting interval Trtcp = Nr * Tf, which when substituted into the
	previous gives Nr * Tf = n * Srtcp/Brtcp. Solving this to give the		previous gives Nr * Tf = n * Srtcp/Brtcp. Solving this to give the
	RTCP bandwidth, Brtcp, and expanding the definition of Srtcp gives:		RTCP bandwidth, Brtcp, and expanding the definition of Srtcp gives:
	Brtcp = (n * (Sc + Nnc * Snc))/(Nr * Tf * (1 + Nnc)).		Brtcp = (n * (Sc + Nrs * Srs))/(Nr * Tf * (1 + Nrs)).
	If we assume every report is a compound RTCP packet (i.e., Nnc = 0),		If we assume every report is a compound RTCP packet (i.e., Nrs = 0),
	the frame duration Tf = 20ms, and an RTCP report is sent for every		the frame duration Tf = 20ms, and an RTCP report is sent for every
	second frame (i.e., 25 RTCP reports per second), this gives an RTCP		second frame (i.e., 25 RTCP reports per second), this gives an RTCP
	feedback bandwidth, Brtcp = 57kbps. Increasing the frame duration,		feedback bandwidth, Brtcp = 57kbps. Increasing the frame duration,
	or reducing the frequency of reports, will reduce the RTCP bandwidth		or reducing the frequency of reports, will reduce the RTCP bandwidth
	as shown in Table 1.		as shown in Table 1.
	+--------------+-------------+----------------+		+--------------+-------------+----------------+
	| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |		| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
	+--------------+-------------+----------------+		+--------------+-------------+----------------+
	| 0.020 | 2 | 57.0 |		| 0.020 | 2 | 57.0 |
	| 0.020 | 4 | 29.3 |		| 0.020 | 4 | 29.3 |
	| 0.020 | 8 | 15.4 |		| 0.020 | 8 | 15.4 |
	| 0.020 | 16 | 8.5 |		| 0.020 | 16 | 8.5 |
	| 0.060 | 2 | 19.0 |		| 0.060 | 2 | 19.0 |
	| 0.060 | 4 | 9.8 |		| 0.060 | 4 | 9.8 |
	| 0.060 | 8 | 5.1 |		| 0.060 | 8 | 5.1 |
	| 0.060 | 16 | 2.8 |		| 0.060 | 16 | 2.8 |
	+--------------+-------------+----------------+		+--------------+-------------+----------------+
	Table 1: RTCP bandwidth needed for VoIP feedback		Table 1: RTCP bandwidth needed for VoIP feedback (compound reports
			only)
	The final row of Table 1 (60ms frames, report every 16 frames) sends		The final row of Table 1 (60ms frames, report every 16 frames) sends
	RTCP reports once per second, giving an RTCP bandwidth overhead of		RTCP reports once per second, giving an RTCP bandwidth overhead of
	2.8kbps.		2.8kbps.
	The overhead can be reduced by sending some reports in non-compound		The overhead can be reduced by sending some reports in reduced-size
	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 the		reduced-size RTCP packets, i.e., Nrs = 1, the calculation gives the
	results shown in Table 2.		results shown in Table 2.
	+--------------+-------------+----------------+		+--------------+-------------+----------------+
	| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |		| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
	+--------------+-------------+----------------+		+--------------+-------------+----------------+
	| 0.020 | 2 | 41.4 |		| 0.020 | 2 | 41.4 |
	| 0.020 | 4 | 21.5 |		| 0.020 | 4 | 21.5 |
	| 0.020 | 8 | 11.5 |		| 0.020 | 8 | 11.5 |
	| 0.020 | 16 | 6.5 |		| 0.020 | 16 | 6.5 |
	| 0.060 | 2 | 13.8 |		| 0.060 | 2 | 13.8 |
	| 0.060 | 4 | 7.2 |		| 0.060 | 4 | 7.2 |
	| 0.060 | 8 | 3.8 |		| 0.060 | 8 | 3.8 |
	| 0.060 | 16 | 2.2 |		| 0.060 | 16 | 2.2 |
	+--------------+-------------+----------------+		+--------------+-------------+----------------+
	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.2kbps. This calculation		(once per second), can be seen to drop to 2.2kbps. This calculation
	can be repeated for other patterns of compound and non-compound RTCP		can be repeated for other patterns of compound and reduced-size RTCP
	packets, feedback frequency, and frame duration, as needed.		packets, feedback frequency, and frame duration, as needed.
	Note: To achieve the RTCP transmission intervals above the RTP/SAVPF		Note: To achieve the RTCP transmission intervals above the RTP/SAVPF
	profile with T_rr_interval=0 is used, since even when using the		profile with T_rr_interval=0 is used, since even when using the
	reduced minimal transmission interval, the RTP/SAVP profile would		reduced minimal transmission interval, the RTP/SAVP profile would
	only allow sending RTCP at most every 0.11s (every third frame of		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		video). Using RTP/SAVPF with T_rr_interval=0 however is capable of
	fully utilizing the configured 5% RTCP bandwidth fraction.		fully utilizing the configured 5% RTCP bandwidth fraction.
	3.2. Scenario 2: Point-to-Point Video Conference		3.2. Scenario 2: Point-to-Point Video Conference
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 44 ¶
	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
	sent, and on the amount of congestion control feedback sent in each		sent, and on the amount of congestion control feedback sent in each
	packet.		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 aggregate of a compound RTCP packet generated by the		contains an aggregate of a compound RTCP packet generated by the
	video SSRC and a compound RTCP packet generated by the audio SSRC.		video SSRC and a compound RTCP packet generated by the audio SSRC.
	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 non-compound 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] it will be 18 octets in		If the CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in
	size, and will need 1 octet of padding, making the SDES packet 28		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.		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),
	skipping to change at page 10, line 42 ¶		skipping to change at page 10, line 42 ¶
	| 1400 | 60 | 2 | 1 | 251.2 (17%) |		| 1400 | 60 | 2 | 1 | 251.2 (17%) |
	| 2048 | 30 | 6 | 2 | 130.3 ( 6%) |		| 2048 | 30 | 6 | 2 | 130.3 ( 6%) |
	| 2048 | 60 | 3 | 1 | 253.1 (12%) |		| 2048 | 60 | 3 | 1 | 253.1 (12%) |
	| 4096 | 30 | 12 | 2 | 135.9 ( 3%) |		| 4096 | 30 | 12 | 2 | 135.9 ( 3%) |
	| 4096 | 60 | 6 | 1 | 258.8 ( 6%) |		| 4096 | 60 | 6 | 1 | 258.8 ( 6%) |
	+---------+----------+--------------+--------------+----------------+		+---------+----------+--------------+--------------+----------------+
	Table 3: Required RTCP bandwidth, reporting on every frame		Table 3: Required RTCP bandwidth, reporting on every frame
	Use of reduced size RTCP [RFC5506] would allow the SR and SDES		Use of reduced size RTCP [RFC5506] would allow the SR and SDES
	packets to be omitted from some reports. These "non-compound"		packets to be omitted from some reports. These "reduced-size" RTCP
	(actually, compound but reduced size in this case) RTCP packets would		packets would contain an RTCP RGRS packet from the non-reporting
	contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP		SSRC, and an RTCP SDES RGRP packet and a congestion control feedback
	SDES RGRP packet and a congestion control feedback packet from the		packet from the reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv
	reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv + 8 + 2*Na		+ 8 + 2*Na octets, plus the SRTCP trailer and authentication tag, and
	octets, plus the SRTCP trailer and authentication tag, and a UDP/IP		a UDP/IP header. That is, the size of the reduced-size packets would
	header. That is, the size of the non-compound packets would be (110		be (110 + 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but
	+ 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but		alternating compound and reduced-size reports gives results as shown
	alternating compound and non-compound reports gives results as shown
	in Table 4.		in Table 4.
	+---------+----------+--------------+--------------+----------------+		+---------+----------+--------------+--------------+----------------+
	| 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: Rf | Report: Nv | Report: Na | Brtcp (kbps) |		| (kbps) | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
	+---------+----------+--------------+--------------+----------------+		+---------+----------+--------------+--------------+----------------+
	| 100 | 8 | 1 | 6 | 24.1 (24%) |		| 100 | 8 | 1 | 6 | 24.1 (24%) |
	| 200 | 16 | 1 | 3 | 46.8 (23%) |		| 200 | 16 | 1 | 3 | 46.8 (23%) |
	| 350 | 30 | 1 | 2 | 86.7 (24%) |		| 350 | 30 | 1 | 2 | 86.7 (24%) |
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 28 ¶
	| 2048 | 60 | 3 | 1 | 175.3 ( 8%) |		| 2048 | 60 | 3 | 1 | 175.3 ( 8%) |
	| 4096 | 30 | 12 | 2 | 97.0 ( 2%) |		| 4096 | 30 | 12 | 2 | 97.0 ( 2%) |
	| 4096 | 60 | 6 | 1 | 180.9 ( 4%) |		| 4096 | 60 | 6 | 1 | 180.9 ( 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 frame. 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.
	4. Discussion and Conclusions		4. Discussion and Conclusions
	Practical systems will generally send some non-media traffic on the		Practical systems will generally send some non-media traffic on the
	same path as the media traffic. This can include STUN/TURN packets		same path as the media traffic. This can include STUN/TURN packets
	to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets		to keep-alive NAT bindings [RFC8445], WebRTC Data Channel packets
	[RFC8831], etc. Such traffic also needs congestion control, but the		[RFC8831], etc. Such traffic also needs congestion control, but the
	means by which this is achieved is out of scope of this memo.		means by which this is achieved is out of scope of this memo.
	skipping to change at page 11, line 51 ¶		skipping to change at page 11, line 51 ¶
	congestion feedback with reasonable overhead.		congestion feedback with reasonable overhead.
	RTCP can, however, be used to send congestion feedback on each frame		RTCP can, however, be used to send congestion feedback on each frame
	of video sent, provided the session bandwidth exceeds a couple of		of video sent, provided the session bandwidth exceeds a couple of
	megabits per second (the exact rate depending on the number of		megabits per second (the exact rate depending on the number of
	session participants, the RTCP bandwidth fraction, and what RTCP		session participants, the RTCP bandwidth fraction, and what RTCP
	extensions are enabled, and how much detail of feedback is needed).		extensions are enabled, and how much detail of feedback is needed).
	For lower rate sessions, the overhead of reporting on every frame		For lower rate sessions, the overhead of reporting on every frame
	becomes high, but can be reduced to something reasonable by sending		becomes high, but can be reduced to something reasonable by sending
	reports once per N frames (e.g., every second frame), or by sending		reports once per N frames (e.g., every second frame), or by sending
	non-compound RTCP reports in between the regular reports.		reduced-size 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 every few		algorithm needs to be designed to work with feedback sent every few
	frames, since that fits within the limitations of RTCP. The provided		frames, since that fits within the limitations of RTCP. The provided
	feedback will be more detailed than just an acknowledgement, however,		feedback will be more detailed than just an acknowledgement, however,
	and will provide a loss bitmap, relative arrival time, and received		and will provide a loss bitmap, relative arrival time, and received
	ECN marks, for each packet sent. This will allow congestion control		ECN marks, for each packet sent. This will allow congestion control
	that is effective, if slowly responsive, to be implemented (there is		that is effective, if slowly responsive, to be implemented (there is
	guidance on providing effective congestion control in Section 3.1 of		guidance on providing effective congestion control in Section 3.1 of
	[RFC8085]).		[RFC8085]).
	The format described in [RFC8888] seems sufficient for the needs of		The format described in [RFC8888] seems sufficient for the needs of
	congestion control feedback. There is little point optimising this		congestion control feedback. There is little point optimising this
	skipping to change at page 13, line 14 ¶		skipping to change at page 13, line 14 ¶
	[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP		[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
	Headers for Low-Speed Serial Links", RFC 2508,		Headers for Low-Speed Serial Links", RFC 2508,
	DOI 10.17487/RFC2508, February 1999,		DOI 10.17487/RFC2508, February 1999,
	<https://www.rfc-editor.org/info/rfc2508>.		<https://www.rfc-editor.org/info/rfc2508>.
	[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,		[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
	RFC 2914, DOI 10.17487/RFC2914, September 2000,		RFC 2914, DOI 10.17487/RFC2914, September 2000,
	<https://www.rfc-editor.org/info/rfc2914>.		<https://www.rfc-editor.org/info/rfc2914>.
			[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
			Sooriyabandara, "TCP Performance Implications of Network
			Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
			December 2002, <https://www.rfc-editor.org/info/rfc3449>.
	[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and		[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and
	P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with		P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
	High Delay, Packet Loss and Reordering", RFC 3545,		High Delay, Packet Loss and Reordering", RFC 3545,
	DOI 10.17487/RFC3545, July 2003,		DOI 10.17487/RFC3545, July 2003,
	<https://www.rfc-editor.org/info/rfc3545>.		<https://www.rfc-editor.org/info/rfc3545>.
	[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, <https://www.rfc-editor.org/info/rfc3550>.		July 2003, <https://www.rfc-editor.org/info/rfc3550>.
End of changes. 30 change blocks.
	55 lines changed or deleted		62 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/