draft-ietf-rmcat-rtp-cc-feedback-11.txt		draft-ietf-rmcat-rtp-cc-feedback-12.txt
	Network Working Group C. Perkins		Network Working Group C. S. Perkins
	Internet-Draft University of Glasgow		Internet-Draft University of Glasgow
	Intended status: Informational October 7, 2022		Intended status: Informational 21 December 2022
	Expires: April 10, 2023		Expires: 24 June 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-11		draft-ietf-rmcat-rtp-cc-feedback-12
	Abstract		Abstract
	This memo discusses the rate at which congestion control feedback can		This memo discusses the rate at which congestion control feedback can
	be sent using the RTP Control Protocol (RTCP) and its suitability for		be sent using the RTP Control Protocol (RTCP) and its suitability for
	implementing congestion control for unicast multimedia applications.		implementing congestion control for unicast multimedia applications.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 April 10, 2023.		This Internet-Draft will expire on 24 June 2023.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Considerations 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 . . . . . . . 10
	4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 11		4. Discussion and Conclusions . . . . . . . . . . . . . . . . . 15
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	8. Informative References . . . . . . . . . . . . . . . . . . . 13		8. Normative References . . . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		9. Informative References . . . . . . . . . . . . . . . . . . . 18
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The deployment of WebRTC systems [RFC8825] has resulted in high-		The deployment of WebRTC systems [RFC8825] has resulted in high-
	quality video conferencing seeing extremely wide use. To ensure the		quality video conferencing seeing extremely wide use. To ensure the
	stability of the network in the face of this use, WebRTC systems need		stability of the network in the face of this use, WebRTC systems need
	to use some form of congestion control for their RTP-based media		to use some form of congestion control for their RTP-based media
	traffic [RFC2914], [RFC8085], [RFC8083], [RFC8834], allowing them to		traffic [RFC2914], [RFC8085], [RFC8083], [RFC8834], allowing them to
	adapt and adjust the media data they send to match changes in the		adapt and adjust the media data they send to match changes in the
	available network capacity. In addition to ensuring the stable		available network capacity. In addition to ensuring the stable
	skipping to change at page 2, line 40 ¶		skipping to change at page 2, line 41 ¶
	to the network capacity, rather than forcing the receiver to		to the network capacity, rather than forcing the receiver to
	compensate for uncontrolled packet loss when the available capacity		compensate for uncontrolled packet loss when the available capacity
	is exceeded.		is exceeded.
	To develop such congestion control, it is necessary to understand the		To develop such congestion control, it is necessary to understand the
	sort of congestion feedback that can be provided within the framework		sort of congestion feedback that can be provided within the framework
	of RTP [RFC3550] and the RTP Control Protocol (RTCP). It then		of RTP [RFC3550] and the RTP Control Protocol (RTCP). It then
	becomes possible to determine if this is sufficient for congestion		becomes possible to determine if this is sufficient for congestion
	control, or if some form of RTP extension is needed.		control, or if some form of RTP extension is needed.
			As this memo will show, if it is desired to use RTCP in something
			close to its current form for congestion feedback, the multimedia
			congestion control algorithm needs to be designed to work with
			detailed feedback sent every few frames, rather than per-frame
			acknowledgement, to match the constraints of RTCP.
	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], and [RFC8872] are used.		[RFC8861], and [RFC8872] are used.
	2. Considerations for RTCP Feedback		2. Considerations for RTCP Feedback
	Several questions need to be answered when providing RTCP feedback		Several questions need to be answered when providing RTCP feedback
	for congestion control purposes. These include:		for congestion control purposes. These include:
	o How often is feedback needed?		* How often is feedback needed?
	o How much overhead is acceptable?		* How much overhead is acceptable?
	o How much, and what, data does each report contain?		* How much, and what, data does each report contain?
	The key question is how often does the receiver need to send feedback		The key question is how often does the receiver need to send feedback
	on the reception quality it is experiencing and hence the congestion		on the reception quality it is experiencing and hence the congestion
	state of the network?		state of the network?
	Widely used transport protocols, such as TCP, send acknowledgements		Widely used transport protocols, such as TCP, send acknowledgements
	frequently. For example, a TCP receiver will send an acknowledgement		frequently. For example, a TCP receiver will send an acknowledgement
	at least once every 0.5 seconds or when new data equal to twice the		at least once every 0.5 seconds or when new data equal to twice the
	maximum segment size has been received [I-D.ietf-tcpm-rfc793bis]).		maximum segment size has been received [RFC9293]). That has
	That has relatively low overhead when traffic is bidirectional and		relatively low overhead when traffic is bidirectional and
	acknowledgements can be piggybacked onto return path data packets.		acknowledgements can be piggybacked onto return path data packets.
	It can also be acceptable, and can have reasonable overhead, to send		It can also be acceptable, and can have reasonable overhead, to send
	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
	skipping to change at page 6, line 29 ¶		skipping to change at page 6, line 36 ¶
	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 reduced-size 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 Srs = 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 + Nrs * Srs)/(1 + Nrs) 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 + Nrs * Srs))/(Nr * Tf * (1 + Nrs)).		| Brtcp = (n * (Sc + Nrs * Srs))/(Nr * Tf * (1 + Nrs)).
	If we assume every report is a compound RTCP packet (i.e., Nrs = 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 | 8 | 15.4 |		| 0.020 | 4 | 29.3 |
	| 0.020 | 16 | 8.5 |		+--------------+-------------+----------------+
	| 0.060 | 2 | 19.0 |		| 0.020 | 8 | 15.4 |
	| 0.060 | 4 | 9.8 |		+--------------+-------------+----------------+
	| 0.060 | 8 | 5.1 |		| 0.020 | 16 | 8.5 |
	| 0.060 | 16 | 2.8 |		+--------------+-------------+----------------+
			| 0.060 | 2 | 19.0 |
			+--------------+-------------+----------------+
			| 0.060 | 4 | 9.8 |
			+--------------+-------------+----------------+
			| 0.060 | 8 | 5.1 |
			+--------------+-------------+----------------+
			| 0.060 | 16 | 2.8 |
	+--------------+-------------+----------------+		+--------------+-------------+----------------+
	Table 1: RTCP bandwidth needed for VoIP feedback (compound reports		Table 1: RTCP bandwidth needed for VoIP
	only)		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 reduced-size		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
	reduced-size RTCP packets, i.e., Nrs = 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 | 8 | 11.5 |		| 0.020 | 4 | 21.5 |
	| 0.020 | 16 | 6.5 |		+--------------+-------------+----------------+
	| 0.060 | 2 | 13.8 |		| 0.020 | 8 | 11.5 |
	| 0.060 | 4 | 7.2 |		+--------------+-------------+----------------+
	| 0.060 | 8 | 3.8 |		| 0.020 | 16 | 6.5 |
	| 0.060 | 16 | 2.2 |		+--------------+-------------+----------------+
			| 0.060 | 2 | 13.8 |
			+--------------+-------------+----------------+
			| 0.060 | 4 | 7.2 |
			+--------------+-------------+----------------+
			| 0.060 | 8 | 3.8 |
			+--------------+-------------+----------------+
			| 0.060 | 16 | 2.2 |
	+--------------+-------------+----------------+		+--------------+-------------+----------------+
	Table 2: Required RTCP bandwidth for VoIP feedback (alternating		Table 2: Required RTCP bandwidth for VoIP
	compound and non-compound reports)		feedback (alternating compound and reduced-
			size 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 reduced-size 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.
			The use of IPv6 will increase the overhead by 20 octets per packet,
			due to the increased size of the IPv6 header compared to IPv4,
			assuming no IP options in either case. This increases the size of
			compound packets to Sc = 162 + 2*Nr octets and reduced size packets
			to Srs = 82 + 2*Nr. Re-running the calculations from Table 1 with
			these packet sizes gives the results shown in Table 3. As can be
			seen, there is a significant increase in overhead due to the use of
			IPv6.
			+--------------+-------------+----------------+
			| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
			+--------------+-------------+----------------+
			| 0.020 | 2 | 64.8 |
			+--------------+-------------+----------------+
			| 0.020 | 4 | 33.2 |
			+--------------+-------------+----------------+
			| 0.020 | 8 | 17.4 |
			+--------------+-------------+----------------+
			| 0.020 | 16 | 9.5 |
			+--------------+-------------+----------------+
			| 0.060 | 2 | 21.6 |
			+--------------+-------------+----------------+
			| 0.060 | 4 | 11.1 |
			+--------------+-------------+----------------+
			| 0.060 | 8 | 5.8 |
			+--------------+-------------+----------------+
			| 0.060 | 16 | 3.2 |
			+--------------+-------------+----------------+
			Table 3: RTCP bandwidth needed for VoIP
			feedback (compound reports only) using IPv6
			Repeating the calculations from Table 2 using IPv6 gives the results
			shown in Table 4. As can be seen, the overhead still increases with
			IPv6 when a mix of compound and reduced-size reports is used, but the
			effect is less pronounced than with compound reports only.
			+--------------+-------------+----------------+
			| Tf (seconds) | Nr (frames) | rtcp_bw (kbps) |
			+--------------+-------------+----------------+
			| 0.020 | 2 | 49.2 |
			+--------------+-------------+----------------+
			| 0.020 | 4 | 25.4 |
			+--------------+-------------+----------------+
			| 0.020 | 8 | 13.5 |
			+--------------+-------------+----------------+
			| 0.020 | 16 | 7.5 |
			+--------------+-------------+----------------+
			| 0.060 | 2 | 16.4 |
			+--------------+-------------+----------------+
			| 0.060 | 4 | 8.5 |
			+--------------+-------------+----------------+
			| 0.060 | 8 | 4.5 |
			+--------------+-------------+----------------+
			| 0.060 | 16 | 2.5 |
			+--------------+-------------+----------------+
			Table 4: Required RTCP bandwidth for VoIP
			feedback (alternating compound and reduced-
			size reports) using IPv6
	3.2. Scenario 2: Point-to-Point Video Conference		3.2. Scenario 2: Point-to-Point Video Conference
	Consider a point-to-point video call between two end systems. There		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,		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		with all four flows being active for essentially all the time (the
	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].
	As in Section 3.1, when all members are senders the RTCP reporting		As in Section 3.1, when all members are senders the RTCP reporting
	interval calculation in Section 6.2 and 6.3 of [RFC3550] and		interval calculation in Section 6.2 and 6.3 of [RFC3550] and
	[RFC4585] reduces to:		[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
	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 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 UDP/IP header
	information, but no report blocks (since the reporting is delegated).		(assuming IPv4 with no options) and sender information, but no report
	The RTCP SDES packet will comprise a header (4 octets), originating		blocks (since the reporting is delegated). The RTCP SDES packet will
	SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding.		comprise a header (4 octets), originating SSRC (4 octets), a CNAME
	If the CNAME follows [RFC7022] and [RFC8834] the CNAME chunk will be		chunk, a terminating chunk, and any padding. If the CNAME follows
	18 octets in size, and will be followed by one octet of padding and		[RFC7022] and [RFC8834] the CNAME chunk will be 18 octets in size,
	one terminating null octet to align the SDES packet to a 32-bit		and will be followed by one octet of padding and one terminating null
	boundary ([RFC3550], section 6.5), making the SDES packet 28 octets		octet to align the SDES packet to a 32-bit boundary ([RFC3550],
	in size. The RTCP RGRS packet will be 12 octets in size. This gives		section 6.5), making the SDES packet 28 octets in size. The RTCP
	a total of 28 + 28 + 12 = 68 octets.		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		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
	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 [RFC8834] it will be 18 octets in size.		CNAME follows [RFC7022] and [RFC8834] it will be 18 octets in size.
	skipping to change at page 9, line 38 ¶		skipping to change at page 12, line 9 ¶
	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 SRTCP trailer and		the reporting and non-reporting SSRCs, an SRTCP trailer and
	authentication tag, and a UDP/IPv4 header. The size of this RTCP		authentication tag, and a UDP/IPv4 header. The size of this RTCP
	packet is therefore: 262 + (2 * Nv) + (2 * Na) octets. Since the		packet is therefore: 262 + (2 * Nv) + (2 * Na) octets. Since the
	aggregate RTCP packet contains reports from two SSRCs, the RTCP		aggregate RTCP packet contains reports from two SSRCs, the RTCP
	packet size is halved before use [RFC8108]. Accordingly, the size of		packet size is halved before use [RFC8108]. Accordingly, the size of
	the RTCP packets is:		the RTCP packets is:
	Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2		| Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2
	How many RTP packets does the RTCP XR congestion control feedback		How many RTP packets does the RTCP XR congestion control feedback
	packet, included in these compound RTCP packets, report on? That is,		packet, included in these compound RTCP packets, report on? That is,
	what are the values of Nv and Na? This depends on the RTCP reporting		what are the values of Nv and Na? This depends on the RTCP reporting
	interval, Trtcp, the video bit rate and frame rate, Rf, the audio bit		interval, Trtcp, the video bit rate and frame rate, Rf, the audio bit
	rate and framing interval, and whether the receiver chooses to send		rate and framing interval, and whether the receiver chooses to send
	congestion control feedback in each RTCP packet it sends.		congestion control feedback in each RTCP packet it sends.
	To simplify the calculation, assume it is desired to send one RTCP		To simplify the calculation, assume it is desired to send one RTCP
	report for each frame of video received (i.e., Trtcp = 1 / Rf) and to		report for each frame of video received (i.e., Trtcp = 1 / Rf) and to
	include a congestion control feedback packet in each report. Assume		include a congestion control feedback packet in each report. Assume
	that video has constant bit rate and frame rate, and that each frame		that video has constant bit rate and frame rate, and that each frame
	of packet has to fit into a 1500 octet MTU. Further, assume that the		of video has to fit into a 1500 octet MTU. Further, assume that the
	audio takes negligible bandwidth, and that the audio framing interval		audio takes negligible bandwidth, and that the audio framing interval
	can be varied within reasonable bounds, so that an integral number of		can be varied within reasonable bounds, so that an integral number of
	audio frames align with video frame boundaries.		audio frames align with video frame boundaries.
	Table 3 shows the resulting values of Nv and Na, the number of video		Table 5 shows the resulting values of Nv and Na, the number of video
	and audio packets covered by each congestion control feedback report,		and audio packets covered by each congestion control feedback report,
	for a range of data rates and video frame rates, assuming congestion		for a range of data rates and video frame rates, assuming congestion
	control feedback is sent once per video frame. The table also shows		control feedback is sent once per video frame. The table also shows
	the result of inverting the RTCP reporting interval calculation to		the result of inverting the RTCP reporting interval calculation to
	find the corresponding RTCP bandwidth, Brtcp. The RTCP bandwidth is		find the corresponding RTCP bandwidth, Brtcp. The RTCP bandwidth is
	given in kbps and as a fraction of the data rate.		given in kbps and as a fraction of the data rate.
	It can be seen that, for example, with a date rate of 1024 kbps and		It can be seen that, for example, with a date rate of 1024 kbps and
	video sent at 30 frames-per-second, the RTCP congestion control		video sent at 30 frames-per-second, the RTCP congestion control
	feedback report sent for each video frame will include reports on 3		feedback report sent for each video frame will include reports on 3
	video packets and 2 audio packets. The RTCP bandwidth needed to		video packets and 2 audio packets. The RTCP bandwidth needed to
	sustain this reporting rate is 127.5kbps (12% of the data rate).		sustain this reporting rate is 127.5kbps (12% of the data rate).
	This assumes an audio framing interval of 16.67ms, so that two audio		This assumes an audio framing interval of 16.67ms, so that two audio
	packets are sent for each video frame.		packets are sent for each video frame.
	+---------+----------+--------------+--------------+----------------+		+-----------+----------+-------------+-------------+---------------+
	| Data | Video | Video | Audio | Required RTCP |		| Data Rate | Video | Video | Audio | Required RTCP |
	| Rate | Frame | Packets per | Packets per | bandwidth: |		| (kbps) | Frame | Packets per | Packets per | bandwidth: |
	| (kbps) | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |		| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
	+---------+----------+--------------+--------------+----------------+		+-----------+----------+-------------+-------------+---------------+
	| 100 | 8 | 1 | 6 | 34.5 (34%) |		| 100 | 8 | 1 | 6 | 34.5 (34%) |
	| 200 | 16 | 1 | 3 | 67.5 (33%) |		+-----------+----------+-------------+-------------+---------------+
	| 350 | 30 | 1 | 2 | 125.6 (35%) |		| 200 | 16 | 1 | 3 | 67.5 (33%) |
	| 700 | 30 | 2 | 2 | 126.6 (18%) |		+-----------+----------+-------------+-------------+---------------+
	| 700 | 60 | 1 | 1 | 249.4 (35%) |		| 350 | 30 | 1 | 2 | 125.6 (35%) |
	| 1024 | 30 | 3 | 2 | 127.5 (12%) |		+-----------+----------+-------------+-------------+---------------+
	| 1400 | 60 | 2 | 1 | 251.2 (17%) |		| 700 | 30 | 2 | 2 | 126.6 (18%) |
	| 2048 | 30 | 6 | 2 | 130.3 ( 6%) |		+-----------+----------+-------------+-------------+---------------+
	| 2048 | 60 | 3 | 1 | 253.1 (12%) |		| 700 | 60 | 1 | 1 | 249.4 (35%) |
	| 4096 | 30 | 12 | 2 | 135.9 ( 3%) |		+-----------+----------+-------------+-------------+---------------+
	| 4096 | 60 | 6 | 1 | 258.8 ( 6%) |		| 1024 | 30 | 3 | 2 | 127.5 (12%) |
	+---------+----------+--------------+--------------+----------------+		+-----------+----------+-------------+-------------+---------------+
			| 1400 | 60 | 2 | 1 | 251.2 (17%) |
			+-----------+----------+-------------+-------------+---------------+
			| 2048 | 30 | 6 | 2 | 130.3 ( 6%) |
			+-----------+----------+-------------+-------------+---------------+
			| 2048 | 60 | 3 | 1 | 253.1 (12%) |
			+-----------+----------+-------------+-------------+---------------+
			| 4096 | 30 | 12 | 2 | 135.9 ( 3%) |
			+-----------+----------+-------------+-------------+---------------+
			| 4096 | 60 | 6 | 1 | 258.8 ( 6%) |
			+-----------+----------+-------------+-------------+---------------+
	Table 3: Required RTCP bandwidth, reporting on every frame		Table 5: 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 "reduced-size" RTCP		packets to be omitted from some reports. These "reduced-size" RTCP
	packets would contain an RTCP RGRS packet from the non-reporting		packets would contain an RTCP RGRS packet from the non-reporting
	SSRC, and an RTCP SDES RGRP packet and a congestion control feedback		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		packet from the reporting SSRC. This will be 12 + 28 + 12 + 8 + 2*Nv
	+ 8 + 2*Na octets, plus the SRTCP trailer and authentication tag, and		+ 8 + 2*Na octets, plus the SRTCP trailer and authentication tag, and
	a UDP/IP header. That is, the size of the reduced-size packets would		a UDP/IP header. That is, the size of the reduced-size packets would
	be (110 + 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but		be (110 + 2*Nv + 2*Na)/2 octets. Repeating the analysis above, but
	alternating compound and reduced-size reports gives results as shown		alternating compound and reduced-size reports gives results as shown
	in Table 4.		in Table 6.
	+---------+----------+--------------+--------------+----------------+		+-----------+----------+-------------+-------------+---------------+
	| Data | Video | Video | Audio | Required RTCP |		| Data Rate | Video | Video | Audio | Required RTCP |
	| Rate | Frame | Packets per | Packets per | bandwidth: |		| (kbps) | Frame | Packets per | Packets per | bandwidth: |
	| (kbps) | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |		| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
	+---------+----------+--------------+--------------+----------------+		+-----------+----------+-------------+-------------+---------------+
	| 100 | 8 | 1 | 6 | 24.1 (24%) |		| 100 | 8 | 1 | 6 | 25.0 (25%) |
	| 200 | 16 | 1 | 3 | 46.8 (23%) |		+-----------+----------+-------------+-------------+---------------+
	| 350 | 30 | 1 | 2 | 86.7 (24%) |		| 200 | 16 | 1 | 3 | 48.5 (24%) |
	| 700 | 30 | 2 | 2 | 87.7 (12%) |		+-----------+----------+-------------+-------------+---------------+
	| 700 | 60 | 1 | 1 | 171.6 (24%) |		| 350 | 30 | 1 | 2 | 90.0 (25%) |
	| 1024 | 30 | 3 | 2 | 88.6 ( 8%) |		+-----------+----------+-------------+-------------+---------------+
	| 1400 | 60 | 2 | 1 | 173.4 (12%) |		| 700 | 30 | 2 | 2 | 90.9 (12%) |
	| 2048 | 30 | 6 | 2 | 91.4 ( 4%) |		+-----------+----------+-------------+-------------+---------------+
	| 2048 | 60 | 3 | 1 | 175.3 ( 8%) |		| 700 | 60 | 1 | 1 | 178.1 (25%) |
	| 4096 | 30 | 12 | 2 | 97.0 ( 2%) |		+-----------+----------+-------------+-------------+---------------+
	| 4096 | 60 | 6 | 1 | 180.9 ( 4%) |		| 1024 | 30 | 3 | 2 | 91.9 ( 8%) |
	+---------+----------+--------------+--------------+----------------+		+-----------+----------+-------------+-------------+---------------+
			| 1400 | 60 | 2 | 1 | 180.0 (12%) |
			+-----------+----------+-------------+-------------+---------------+
			| 2048 | 30 | 6 | 2 | 94.7 ( 4%) |
			+-----------+----------+-------------+-------------+---------------+
			| 2048 | 60 | 3 | 1 | 181.9 ( 8%) |
			+-----------+----------+-------------+-------------+---------------+
			| 4096 | 30 | 12 | 2 | 100.3 ( 2%) |
			+-----------+----------+-------------+-------------+---------------+
			| 4096 | 60 | 6 | 1 | 187.5 ( 4%) |
			+-----------+----------+-------------+-------------+---------------+
	Table 4: Required RTCP bandwidth, reporting on every frame, with		Table 6: 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 frame. 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.
			As discussed in Section 3.1, the reporting overhead will increase if
			IPv6 is used, due to the increased size of the IPv6 header. Table 7
			shows the overhead in this case, compared to Table 6. As can be
			seen, the increase in overhead due to IPv6 rapidly becomes less
			significant as the data rate increases.
			+-----------+----------+-------------+-------------+---------------+
			| Data Rate | Video | Video | Audio | Required RTCP |
			| (kbps) | Frame | Packets per | Packets per | bandwidth: |
			| | Rate: Rf | Report: Nv | Report: Na | Brtcp (kbps) |
			+-----------+----------+-------------+-------------+---------------+
			| 100 | 8 | 1 | 6 | 27.5 (27%) |
			+-----------+----------+-------------+-------------+---------------+
			| 200 | 16 | 1 | 3 | 53.5 (26%) |
			+-----------+----------+-------------+-------------+---------------+
			| 350 | 30 | 1 | 2 | 99.4 (28%) |
			+-----------+----------+-------------+-------------+---------------+
			| 700 | 30 | 2 | 2 | 100.3 (14%) |
			+-----------+----------+-------------+-------------+---------------+
			| 700 | 60 | 1 | 1 | 196.9 (28%) |
			+-----------+----------+-------------+-------------+---------------+
			| 1024 | 30 | 3 | 2 | 101.2 ( 9%) |
			+-----------+----------+-------------+-------------+---------------+
			| 1400 | 60 | 2 | 1 | 198.8 (14%) |
			+-----------+----------+-------------+-------------+---------------+
			| 2048 | 30 | 6 | 2 | 104.1 ( 5%) |
			+-----------+----------+-------------+-------------+---------------+
			| 2048 | 60 | 3 | 1 | 200.6 ( 9%) |
			+-----------+----------+-------------+-------------+---------------+
			| 4096 | 30 | 12 | 2 | 109.7 ( 2%) |
			+-----------+----------+-------------+-------------+---------------+
			| 4096 | 60 | 6 | 1 | 206.2 ( 5%) |
			+-----------+----------+-------------+-------------+---------------+
			Table 7: Required RTCP bandwidth, reporting on every frame, with
			reduced-size reports, using IPv6
	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.
	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 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
	reduced-size RTCP reports in between the regular reports.		reduced-size RTCP reports in between the regular reports. The
			improved compression of new video codecs exacerbates the reporting
			overhead for a given video quality level, although this is to some
			extent countered by the use of higher quality video over time.
	If it is desired to use RTCP in something close to its current form		If it is desired to use RTCP in something close to its current form
	for congestion feedback in WebRTC, the multimedia congestion control		for congestion feedback in WebRTC, the multimedia congestion control
	algorithm needs to 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
	skipping to change at page 12, line 45 ¶		skipping to change at page 17, line 7 ¶
	service. This can be prevented by authentication and integrity		service. This can be prevented by authentication and integrity
	protection of RTCP packets, for example using the secure RTP profile		protection of RTCP packets, for example using the secure RTP profile
	[RFC3711][RFC5124], or by other means as discussed in [RFC7201].		[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, Ingemar Johansson, Gorry Fairhurst,		Thanks to Bernard Aboba, Martin Duke, Linda Dunbar, Gorry Fairhurst,
	Linda Dunbar, Shuping Peng, and the members of the RMCAT feedback		Ingemar Johansson, Shuping Peng, Alvaro Retana, Zahed Sarker, John
	design team for their feedback.		Scudder, Éric Vyncke, Magnus Westerlund, and the members of the
			RMCAT feedback design team for their feedback.
	8. Informative References
	[I-D.ietf-tcpm-rfc793bis]
	Eddy, W., "Transmission Control Protocol (TCP)
	Specification", draft-ietf-tcpm-rfc793bis-20 (work in
	progress), January 2021.
	[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP		8. Normative References
	Headers for Low-Speed Serial Links", RFC 2508,
	DOI 10.17487/RFC2508, February 1999,
	<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
	P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
	High Delay, Packet Loss and Reordering", RFC 3545,
	DOI 10.17487/RFC3545, July 2003,
	<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>.
	[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
	"RTP Control Protocol Extended Reports (RTCP XR)",
	RFC 3611, DOI 10.17487/RFC3611, November 2003,
	<https://www.rfc-editor.org/info/rfc3611>.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.		[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",		Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, DOI 10.17487/RFC3711, March 2004,		RFC 3711, DOI 10.17487/RFC3711, March 2004,
	<https://www.rfc-editor.org/info/rfc3711>.		<https://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,
	<https://www.rfc-editor.org/info/rfc4585>.		<https://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, <https://www.rfc-editor.org/info/rfc5124>.		2008, <https://www.rfc-editor.org/info/rfc5124>.
	[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
	Friendly Rate Control (TFRC): Protocol Specification",
	RFC 5348, DOI 10.17487/RFC5348, September 2008,
	<https://www.rfc-editor.org/info/rfc5348>.
	[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size		[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
	Real-Time Transport Control Protocol (RTCP): Opportunities		Real-Time Transport Control Protocol (RTCP): Opportunities
	and Consequences", RFC 5506, DOI 10.17487/RFC5506, April		and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
	2009, <https://www.rfc-editor.org/info/rfc5506>.		2009, <https://www.rfc-editor.org/info/rfc5506>.
	[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
	Header Compression (ROHC) Framework", RFC 5795,
	DOI 10.17487/RFC5795, March 2010,
	<https://www.rfc-editor.org/info/rfc5795>.
	[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, <https://www.rfc-editor.org/info/rfc7022>.		September 2013, <https://www.rfc-editor.org/info/rfc7022>.
	[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP		[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
	Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,		Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
	<https://www.rfc-editor.org/info/rfc7201>.		<https://www.rfc-editor.org/info/rfc7201>.
	[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,		[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
	DOI 10.17487/RFC7667, November 2015,		"Sending Multiple RTP Streams in a Single RTP Session",
	<https://www.rfc-editor.org/info/rfc7667>.		RFC 8108, DOI 10.17487/RFC8108, March 2017,
			<https://www.rfc-editor.org/info/rfc8108>.
	[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:		[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control:
	Circuit Breakers for Unicast RTP Sessions", RFC 8083,		Circuit Breakers for Unicast RTP Sessions", RFC 8083,
	DOI 10.17487/RFC8083, March 2017,		DOI 10.17487/RFC8083, March 2017,
	<https://www.rfc-editor.org/info/rfc8083>.		<https://www.rfc-editor.org/info/rfc8083>.
	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage		[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,		Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	March 2017, <https://www.rfc-editor.org/info/rfc8085>.		March 2017, <https://www.rfc-editor.org/info/rfc8085>.
	[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
	"Sending Multiple RTP Streams in a Single RTP Session",
	RFC 8108, DOI 10.17487/RFC8108, March 2017,
	<https://www.rfc-editor.org/info/rfc8108>.
	[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
	Connectivity Establishment (ICE): A Protocol for Network
	Address Translator (NAT) Traversal", RFC 8445,
	DOI 10.17487/RFC8445, July 2018,
	<https://www.rfc-editor.org/info/rfc8445>.
	[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for		[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for
	Browser-Based Applications", RFC 8825,		Browser-Based Applications", RFC 8825,
	DOI 10.17487/RFC8825, January 2021,		DOI 10.17487/RFC8825, January 2021,
	<https://www.rfc-editor.org/info/rfc8825>.		<https://www.rfc-editor.org/info/rfc8825>.
	[RFC8831] Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
	Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
	<https://www.rfc-editor.org/info/rfc8831>.
	[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport		[RFC8834] Perkins, C., Westerlund, M., and J. Ott, "Media Transport
	and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,		and Use of RTP in WebRTC", RFC 8834, DOI 10.17487/RFC8834,
	January 2021, <https://www.rfc-editor.org/info/rfc8834>.		January 2021, <https://www.rfc-editor.org/info/rfc8834>.
	[RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,		[RFC8861] 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 RTP Control Protocol (RTCP) Reception Statistics		Grouping RTP Control Protocol (RTCP) Reception Statistics
	and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,		and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
	January 2021, <https://www.rfc-editor.org/info/rfc8861>.		January 2021, <https://www.rfc-editor.org/info/rfc8861>.
	skipping to change at page 15, line 41 ¶		skipping to change at page 18, line 45 ¶
	and R. Even, "Guidelines for Using the Multiplexing		and R. Even, "Guidelines for Using the Multiplexing
	Features of RTP to Support Multiple Media Streams",		Features of RTP to Support Multiple Media Streams",
	RFC 8872, DOI 10.17487/RFC8872, January 2021,		RFC 8872, DOI 10.17487/RFC8872, January 2021,
	<https://www.rfc-editor.org/info/rfc8872>.		<https://www.rfc-editor.org/info/rfc8872>.
	[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP		[RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP
	Control Protocol (RTCP) Feedback for Congestion Control",		Control Protocol (RTCP) Feedback for Congestion Control",
	RFC 8888, DOI 10.17487/RFC8888, January 2021,		RFC 8888, DOI 10.17487/RFC8888, January 2021,
	<https://www.rfc-editor.org/info/rfc8888>.		<https://www.rfc-editor.org/info/rfc8888>.
	Author's Address		9. Informative References
			[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
			Headers for Low-Speed Serial Links", RFC 2508,
			DOI 10.17487/RFC2508, February 1999,
			<https://www.rfc-editor.org/info/rfc2508>.
			[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
			P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with
			High Delay, Packet Loss and Reordering", RFC 3545,
			DOI 10.17487/RFC3545, July 2003,
			<https://www.rfc-editor.org/info/rfc3545>.
			[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
			"RTP Control Protocol Extended Reports (RTCP XR)",
			RFC 3611, DOI 10.17487/RFC3611, November 2003,
			<https://www.rfc-editor.org/info/rfc3611>.
			[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
			Friendly Rate Control (TFRC): Protocol Specification",
			RFC 5348, DOI 10.17487/RFC5348, September 2008,
			<https://www.rfc-editor.org/info/rfc5348>.
			[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
			Header Compression (ROHC) Framework", RFC 5795,
			DOI 10.17487/RFC5795, March 2010,
			<https://www.rfc-editor.org/info/rfc5795>.
			[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
			DOI 10.17487/RFC7667, November 2015,
			<https://www.rfc-editor.org/info/rfc7667>.
			[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
			Connectivity Establishment (ICE): A Protocol for Network
			Address Translator (NAT) Traversal", RFC 8445,
			DOI 10.17487/RFC8445, July 2018,
			<https://www.rfc-editor.org/info/rfc8445>.
			[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
			Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
			<https://www.rfc-editor.org/info/rfc8831>.
			[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
			STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
			<https://www.rfc-editor.org/info/rfc9293>.
			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. 43 change blocks.
	160 lines changed or deleted		304 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/