Diff: rfc9392.original.xml

	rfc9392.original.xml	rfc9392.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<?xml-model href="rfc7991bis.rnc"?>	<?xml-model href="rfc7991bis.rnc"?>
	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-rmcat-rtp-cc
	-feedback-12"	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-rmcat-rtp-cc
	category="info" ipr="trust200902" submissionType="IETF" xml:lang="en" version=	-feedback-12" number="9392" submissionType="IETF" category="info" consensus="tru
	"3">	e" ipr="trust200902" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="
		en" updates="" obsoletes="" version="3">

	<front>	<front>
	<title abbrev="RTCP Feedback for Congestion Control">	<title abbrev="RTCP Feedback for Congestion Control">
	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
	</title>	</title>

	<seriesInfo name="Internet-Draft" value="draft-ietf-rmcat-rtp-cc-feedback-12	<seriesInfo name="RFC" value="9392"/>
	"/>	<author fullname="Colin Perkins" initials="C." surname="Perkins">
	<author fullname="Colin Perkins" initials="C. S." surname="Perkins">
	<organization>University of Glasgow</organization>	<organization>University of Glasgow</organization>
	<address>	<address>
	<postal>	<postal>

	<street>School of Computing Science</street>	<extaddr>School of Computing Science</extaddr>
	<city>Glasgow</city>	<city>Glasgow</city>
	<code>G12 8QQ</code>	<code>G12 8QQ</code>
	<country>United Kingdom</country>	<country>United Kingdom</country>
	</postal>	</postal>
	<email>csp@csperkins.org</email>	<email>csp@csperkins.org</email>
	</address>	</address>
	</author>	</author>

	<date day="21" month="December" year="2022" />	<date month="April" year="2023" />
	<abstract>	<area>tsv</area>
		<workgroup>rmcat</workgroup>
		<keyword>RTP</keyword>
		<keyword>Congestion Control</keyword>
		<keyword>VoIP</keyword>
		<keyword>Video Conferencing</keyword>

		<abstract>
	<t>	<t>

	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 the suitability of RTCP
	implementing congestion control for unicast multimedia applications.	for
		implementing congestion control for unicast multimedia applications.
	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>
	<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->	<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
	<middle>	<middle>
	<section title="Introduction">	<section title="Introduction">
	<t>	<t>
	The deployment of WebRTC systems <xref target="RFC8825"/> has resulted	The deployment of WebRTC systems <xref target="RFC8825"/> has resulted
	in high-quality video conferencing seeing extremely wide use. To ensure	in high-quality video conferencing seeing extremely wide use. To ensure
	the stability of the network in the face of this use, WebRTC systems	the stability of the network in the face of this use, WebRTC systems
	need to use some form of congestion control for their RTP-based media	need to use some form of congestion control for their RTP-based media

	traffic <xref target="RFC2914"/>, <xref target="RFC8085"/>,	traffic <xref target="RFC2914"/> <xref target="RFC8083"/>
	<xref target="RFC8083"/>, <xref target="RFC8834"/>, allowing them to	<xref target="RFC8085"/> <xref target="RFC8834"/>, allowing them to
	adapt and adjust the media data they send to match	adapt and adjust the media data they send to match
	changes in the available network capacity. In addition to ensuring	changes in the available network capacity. In addition to ensuring
	the stable operation of the network, such adaptation is critical to	the stable operation of the network, such adaptation is critical to
	ensuring a good user experience, since it allows the sender to match	ensuring a good user experience, since it allows the sender to match
	the media to the network capacity, rather than forcing the receiver	the media to the network capacity, rather than forcing the receiver
	to compensate for uncontrolled packet loss when the available capacity	to compensate for uncontrolled packet loss when the available capacity
	is exceeded.	is exceeded.
	</t>	</t>

	<t>	<t>
	To develop such congestion control, it is necessary to	To develop such congestion control, it is necessary to
	understand the sort of congestion feedback that can be provided within	understand the sort of congestion feedback that can be provided within
	the framework of RTP <xref target="RFC3550"/> and the RTP Control	the framework of RTP <xref target="RFC3550"/> and the RTP Control
	Protocol (RTCP). It then becomes possible to determine if this is	Protocol (RTCP). It then becomes possible to determine if this is

	sufficient for congestion control, or if some form of RTP extension	sufficient for congestion control or if some form of RTP extension
	is needed.	is needed.
	</t>	</t>

	<t>	<t>
	As this memo will show, if it is desired to use RTCP in something	As this memo will show, if it is desired to use RTCP in something
	close to its current form for congestion feedback, the multimedia	close to its current form for congestion feedback, the multimedia
	congestion control algorithm needs to be designed to work with	congestion control algorithm needs to be designed to work with
	detailed feedback sent every few frames, rather than per-frame	detailed feedback sent every few frames, rather than per-frame
	acknowledgement, to match the constraints of RTCP.	acknowledgement, to match the constraints of RTCP.
	</t>	</t>

	<t>	<t>
	This memo considers unicast congestion feedback that can be sent using	This memo considers unicast congestion feedback that can be sent using
	RTCP under the RTP/SAVPF profile <xref target="RFC5124"/> (the secure	RTCP under the RTP/SAVPF profile <xref target="RFC5124"/> (the secure

	version of the RTP/AVPF profile <xref target="RFC4585"/>). This	version of the RTP/AVPF profile <xref target="RFC4585"/>).
	profile was chosen as it forms the basis for media transport in WebRTC	This
	<xref target="RFC8834"/> systems. Nothing in this memo is specific to	profile was chosen because it forms the basis for media transport in Web
	the secure version of the profile, or to WebRTC, however. It is also	RTC
		<xref target="RFC8834"/> systems. However, nothing in this memo is speci
		fic to
		the secure version of the profile or to WebRTC. It is also
	assumed that the congestion control feedback mechanism described in	assumed that the congestion control feedback mechanism described in

	<xref target="RFC8888"/>, and common RTCP extensions for efficient feedb	<xref target="RFC8888"/> and common RTCP extensions for efficient feedba
	ack	ck
	<xref target="RFC5506"/>, <xref target="RFC8108"/>,	<xref target="RFC5506"/> <xref target="RFC8108"/>
	<xref target="RFC8861"/>, and <xref target="RFC8872"/> are used.	<xref target="RFC8861"/> <xref target="RFC8872"/> are used.
	</t>	</t>

		<section title="Terminology">
		<dl newline="false" spacing="normal">
		<dt>Nr:</dt> <dd>number of frames between feedback reports</dd>
		<dt>Nrs:</dt> <dd>number of reduced-size RTCP packets send for every co
		mpound RTCP packet</dd>
		<dt>Na:</dt> <dd>number of audio packets per report</dd>
		<dt>Nv:</dt> <dd>number of video packets per reports</dd>
		<dt>Sc:</dt> <dd>size of a compound RTCP packet</dd>
		<dt>Srs:</dt> <dd>size of a reduced-size RTCP packet</dd>
		<dt>Tf:</dt> <dd>duration of a media frame in seconds </dd>
		<dt>Rf:</dt> <dd>frame rate 1/Tf</dd>
		</dl>
		</section>
	</section>	</section>

	<section title="Considerations for RTCP Feedback">	<section title="Considerations for RTCP Feedback">
	<t>	<t>
	Several questions need to be answered when providing RTCP	Several questions need to be answered when providing RTCP
	feedback for congestion control purposes. These include:	feedback for congestion control purposes. These include:
	</t>	</t>
	<ul>	<ul>
	<li> How often is feedback needed? </li>	<li> How often is feedback needed? </li>
	<li> How much overhead is acceptable? </li>	<li> How much overhead is acceptable? </li>

	<li> How much, and what, data does each report contain? </li>	<li> How much and what data does each report contain? </li>
	</ul>	</ul>
	<t>	<t>

	The key question is how often does the receiver need to send feedback	However, the key question is as follows: how often does the receiver need
	on the reception quality it is experiencing and hence the congestion	to send feedback on the reception quality it is experiencing and hence th
	state of the network?	e
		congestion state of the network?
	</t>	</t>

	<t>	<t>
	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 maxi mum	at least once every 0.5 seconds or when new data equal to twice the maxi mum

	segment size has been received <xref target="RFC9293"/>).	segment size has been received <xref target="RFC9293"/>.
	That has relatively low overhead when traffic is bidirectional	That has relatively low overhead when traffic is bidirectional
	and acknowledgements can be piggybacked onto return path data packets.	and 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.
	</t>	</t>

	<t>	<t>
	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 (VoIP) flows, leadi ng
	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
	that have been proposed to reduce acknowledgement overheads on highly	that have been proposed to reduce acknowledgement overheads on highly
	asymmetric links (e.g., as mentioned in <xref target="RFC3449"/>)	asymmetric links (e.g., as mentioned in <xref target="RFC3449"/>)
	can also reduce the feedback frequency and overhead for multimedia traff ic, but this	can also reduce the feedback frequency and overhead for multimedia traff ic, but this

	so-called "stretch-ACK" behaviour is non-standard and not guaranteed.	so-called "stretch-ACK" behavior is nonstandard and not guaranteed.
	</t>	</t>

	<t>	<t>
	Accordingly, when implementing congestion control for RTP-based multimed ia traffic,	Accordingly, when implementing congestion control for RTP-based multimed ia traffic,
	it might make sense to give the option of sending congestion feedback le ss often	it might make sense to give the option of sending congestion feedback le ss often
	than TCP does. For example, it might be possible to send a feedback pac ket	than TCP does. For example, it might be possible to send a feedback pac ket

	once per video frame, or every few frames, or once per network round tri p	once per video frame, every few frames, or once per network round-trip
	time (RTT). This could still give sufficiently frequent feedback for	time (RTT). This could still give sufficiently frequent feedback for
	the congestion control loop to be stable and responsive while keeping	the congestion control loop to be stable and responsive while keeping
	the overhead reasonable when the feedback cannot be piggybacked onto	the overhead reasonable when the feedback cannot be piggybacked onto
	returning data. In this case, it is important to note that RTCP can	returning data. In this case, it is important to note that RTCP can

	send much more detailed feedback than simple acknowledgements. For	send much more detailed feedback than simple acknowledgements.
	example, if it were useful, it could be possible to use an RTCP	For example, if it were useful, it could be possible to use an RTCP exten
	extended report (XR) packet <xref target="RFC3611"/> to send feedback	ded
	once per RTT comprising a bitmap of lost and received packets, with	report (XR) packet <xref target="RFC3611"/> to send feedback once per RTT
	reception times, over that RTT. As long as feedback is sent	;
	frequently enough that the control loop is stable, and the sender is	the feedback could comprise a
		bitmap of lost and received packets, with reception times, over that
		RTT. As long as feedback is sent
		frequently enough that the control loop is stable and the sender is
	kept informed when data leaves the network (to provide an equivalent	kept informed when data leaves the network (to provide an equivalent

	to ACK clocking in TCP), it is not necessary to report on every packet	to acknowledgement (ACK) clocking in TCP), it is not necessary to report on every packet
	at the instant it is received. Indeed, it is unlikely that a video	at the instant it is received. Indeed, it is unlikely that a video
	codec can react instantly to a rate change, and there is little	codec can react instantly to a rate change, and there is little
	point in providing feedback more often than the codec can adapt.	point in providing feedback more often than the codec can adapt.
	This suggests that an RTP receiver needs to be configured to provide	This suggests that an RTP receiver needs to be configured to provide
	feedback at a rate that matches the rate of adaptation of the sender.	feedback at a rate that matches the rate of adaptation of the sender.

	In the best case, this will match the media frame rate, but might	In the best case, this will match the media frame rate but might
	often be slower.	often be slower.
	</t>	</t>

	<t>	<t>
	Reducing the feedback frequency compared to TCP will reduce feedback	Reducing the feedback frequency compared to TCP will reduce feedback
	overhead but will lead multimedia flows to adapt to congestion more	overhead but will lead multimedia flows to adapt to congestion more
	slowly than TCP, raising concerns about inter-flow fairness. Similar	slowly than TCP, raising concerns about inter-flow fairness. Similar

	concerns are noted in <xref target="RFC5348"/>, and accordingly the	concerns are noted in <xref target="RFC5348"/>, and accordingly, the
	congestion control algorithm described therein aims for "reasonable"	congestion control algorithm described therein aims for "reasonable"
	fairness and a sending rate that is "generally within a factor of	fairness and a sending rate that is "generally within a factor of

	two" of that TCP would achieve under the same conditions. It is	two" of what TCP would achieve under the same conditions. It is
	to be noted, however, that TCP exhibits inter-flow unfairness when	to be noted, however, that TCP exhibits inter-flow unfairness when
	flows with differing round-trip times compete, and stretch	flows with differing round-trip times compete, and stretch
	acknowledgements due to in-network traffic manipulation are not	acknowledgements due to in-network traffic manipulation are not
	uncommon and also raise fairness concerns. Implementations need	uncommon and also raise fairness concerns. Implementations need
	to balance potential unfairness against feedback overhead.	to balance potential unfairness against feedback overhead.
	</t>	</t>

	<t>	<t>
	Generating and processing feedback consumes resources at the sender	Generating and processing feedback consumes resources at the sender
	and receiver. The feedback packets also incur forwarding costs, contribu te	and receiver. The feedback packets also incur forwarding costs, contribu te
	to link utilization, and can affect the timing of other traffic on the	to link utilization, and can affect the timing of other traffic on the

	network. This can affect performance on some types of network, that can	network. This can affect performance on some types of networks that can
	be	be
	impacted by the rate, timing, and size of feedback packets, as well as b	impacted by the rate, timing, and size of feedback packets, as well as
	y
	the overall volume of feedback bytes.	the overall volume of feedback bytes.
	</t>	</t>

	<t>	<t>
	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 said	feedback on return path data packets. The RTP standards have long said

	that a 5% overhead for RTCP traffic is generally acceptable, while	that a 5% overhead for RTCP traffic is generally acceptable. Is this sti
	providing the ability to change this fraction. Is this still the case	ll
		the case
	for congestion control feedback? Is there a desire to provide	for congestion control feedback? Is there a desire to provide
	more responsive feedback and congestion control, possibly with a	more responsive feedback and congestion control, possibly with a
	higher overhead? Or is lower overhead wanted, accepting that this	higher overhead? Or is lower overhead wanted, accepting that this
	might reduce responsiveness of the congestion control algorithm?	might reduce responsiveness of the congestion control algorithm?
	</t>	</t>

	<t>	<t>

	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 a high
	rate but simple feedback (e.g., like TCP acknowledgements), or is	rate but simple feedback (e.g., like TCP acknowledgements), or is
	it acceptable to send more complex feedback less often?	it acceptable to send more complex feedback less often?
	Is it useful for the congestion control to receive frequent feedback,	Is it useful for the congestion control to receive frequent feedback,
	perhaps to provide more accurate round-trip time estimates, or to	perhaps to provide more accurate round-trip time estimates, or to
	provide robustness in case feedback packets are lost, even if the	provide robustness in case feedback packets are lost, even if the
	media sending rate cannot quickly be changed? Or is low-rate feedback,	media sending rate cannot quickly be changed? Or is low-rate feedback,
	resulting in slowly responsive changes to the sending rate, acceptable?	resulting in slowly responsive changes to the sending rate, acceptable?

	Different combinations of congestion control algorithm and media	Different combinations of the congestion control algorithm and media
	codec might require different trade-offs, and the correct trade-off	codec might require different trade-offs, and the correct trade-off
	for interactive, self-paced, real-time multimedia traffic might not	for interactive, self-paced, real-time multimedia traffic might not
	be the same as that for TCP congestion control.	be the same as that for TCP congestion control.
	</t>	</t>
	</section>	</section>


	<section title="What Feedback is Achievable With RTCP?">	<section title="What Feedback is Achievable with RTCP?">
	<t>	<t>
	The following sections illustrate how the RTCP congestion control	The following sections illustrate how the RTCP congestion control
	feedback report <xref target="RFC8888"/> can be used in different	feedback report <xref target="RFC8888"/> can be used in different

	scenarios, and illustrate the overheads of this approach.	scenarios and illustrate the overheads of this approach.
	</t>	</t>

	<section title="Scenario 1: Voice Telephony" anchor="sec-p2p-audio">	<section title="Scenario 1: Voice Telephony" anchor="sec-p2p-audio">
	<t>	<t>
	In many ways, point-to-point voice telephony is the simplest	In many ways, point-to-point voice telephony is the simplest
	scenario for congestion control, since there is only a single	scenario for congestion control, since there is only a single
	media stream to control. It's complicated, however, by severe	media stream to control. It's complicated, however, by severe
	bandwidth constraints on the feedback, to keep the overhead	bandwidth constraints on the feedback, to keep the overhead
	manageable.	manageable.
	</t>	</t>

	<t>	<t>

	Assume a two-party point-to-point voice-over-IP call, using RTP	Assume a two-party, point-to-point VoIP call, using RTP
	over UDP/IP. A rate adaptive speech codec, such as Opus, is used,	over UDP/IP. A rate-adaptive speech codec, such as Opus, is used,
	encoded into RTP packets in frames of duration Tf seconds (Tf =	encoded into RTP packets in frames of a duration of Tf seconds (Tf =
	0.020s in many cases, but values up to 0.060s are not uncommon). The	0.020 s in many cases, but values up to 0.060 s are not uncommon). The
	congestion control algorithm requires feedback every Nr frames,	congestion control algorithm requires feedback every Nr frames,
	i.e., every Nr * Tf seconds, to ensure effective control. Both	i.e., every Nr * Tf seconds, to ensure effective control. Both
	parties in the call send speech data or comfort noise with	parties in the call send speech data or comfort noise with
	sufficient frequency that they are counted as senders for the	sufficient frequency that they are counted as senders for the
	purpose of the RTCP reporting interval calculation.	purpose of the RTCP reporting interval calculation.
	</t>	</t>

	<t>	<t>

	RTCP feedback packets can be full, compound, RTCP feedback	RTCP feedback packets can be full (compound) RTCP feedback
	packets, or reduced-size RTCP packets <xref target="RFC5506"/>.	packets or reduced-size RTCP packets <xref target="RFC5506"/>.
	A compound RTCP packet is sent once for every Nrs reduced-size	A compound RTCP packet is sent once for every Nrs reduced-size
	RTCP packets.	RTCP packets.
	</t>	</t>

	<t>	<t>
	Compound RTCP packets contain a Sender Report (SR) packet, a	Compound RTCP packets contain a Sender Report (SR) packet, a
	Source Description (SDES) packet, and an RTP Congestion Control	Source Description (SDES) packet, and an RTP Congestion Control
	Feedback (CCFB) packet <xref target="RFC8888"/>. Reduced-size	Feedback (CCFB) packet <xref target="RFC8888"/>. Reduced-size
	RTCP packets contain only the CCFB packet. Since each participant	RTCP packets contain only the CCFB packet. Since each participant
	sends only a single RTP media stream, the extensions for RTCP report	sends only a single RTP media stream, the extensions for RTCP report

	aggregation <xref target="RFC8108"/> and reporting group optimisation	aggregation <xref target="RFC8108"/> and reporting group optimization
	<xref target="RFC8861"/> are not used.	<xref target="RFC8861"/> are not used.
	</t>	</t>

	<t>	<t>
	Within each compound RTCP packet, the SR packet will contain a	Within each compound RTCP packet, the SR packet will contain a
	sender information block (28 octets) and a single reception	sender information block (28 octets) and a single reception
	report block (24 octets), for a total of 52 octets. A minimal	report block (24 octets), for a total of 52 octets. A minimal

	SDES packet will contain a header (4 octets) and a single chunk	SDES packet will contain a header (4 octets), a single chunk
	containing an SSRC (4 octets) and a CNAME item, and if the	containing a synchronization source (SSRC) (4 octets), and a CNAME ite
		m, and if the
	recommendations for choosing the CNAME <xref target="RFC7022"/>	recommendations for choosing the CNAME <xref target="RFC7022"/>
	are followed, the CNAME item will comprise a 2-octet header, 16	are followed, the CNAME item will comprise a 2-octet header, 16
	octets of data, and 2 octets of padding, for a total SDES packet	octets of data, and 2 octets of padding, for a total SDES packet

	size of 28 octets. The CCFB packets contain an RTCP header	size of 28 octets.
	and SSRC (8 octets), a report timestamp (4 octets), the	The CCFB packets contain an RTCP header
	SSRC, beginning and ending sequence numbers (8 octets), and 2*Nr	and SSRC (8 octets), a report timestamp (4 octets), the other party's
	octets of reports, for a total of 20 + 2*Nr octets.	SSRC, beginning and ending sequence numbers (8 octets), and 2 * Nr
	The compound Secure RTCP packet will include 4 octets of trailer	octets of reports, for a total of 20 + (2 * Nr) octets.
	followed by an 80 bit (10 octet) authentication tag if HMAC-SHA1	The compound Secure RTCP (SRTCP) packet will include 4 octets of trail
		er,
		followed by an 80-bit (10-octet) authentication tag if HMAC-SHA1
	authentication is used.	authentication is used.
	If IPv4 is used, with no IP options, the UDP/IP header will be	If 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	28 octets in size. This gives a total compound RTCP packet size

	of Sc = 142 + 2*Nr octets.	of Sc = 142 + (2 * Nr) octets.
	</t>	</t>


	<t>	<t>
	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	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.	be seen that these packets will be Srs = 62 + (2 * Nr) octets in size.
	</t>	</t>

	<t>	<t>

	The RTCP reporting interval calculation (<xref target="RFC3550"/>,	The RTCP reporting interval calculation (Sections <xref target="RFC355
	Section 6.2) for a two-party session where both participants	0" section="6.2" sectionFormat="bare"/> and <xref target="RFC3550" section="6.3"
	are senders, reduces to:	sectionFormat="bare"/> of <xref target="RFC3550"/> and <xref target="RFC4585"/>
		) for a two-party session where both participants
		are senders reduces to:
	</t>	</t>

	<blockquote>	<artwork name="" type="" align="left"><![CDATA[
	<artwork>	Trtcp = n * Srtcp / Brtcp
	Trtcp = n * Srtcp / Brtcp	]]></artwork>
	</artwork>
	</blockquote>
	<t>	<t>

	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).
	</t>	</t>

	<t>	<t>
	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 to Trtcp = Nr * Tf, which when substituted into the
	previous gives Nr * Tf = n * Srtcp/Brtcp.	previous, gives Nr * Tf = n * Srtcp / Brtcp.
	Solving this to give the RTCP bandwidth, Brtcp, and expanding the	Solving this to give the RTCP bandwidth (Brtcp) and expanding the
	definition of Srtcp gives:	definition of Srtcp gives:
	</t>	</t>

	<blockquote>	<artwork name="" type="" align="left"><![CDATA[
	<artwork>	Brtcp = (n * (Sc + Nrs * Srs)) / (Nr * Tf * (1 + Nrs))
	Brtcp = (n * (Sc + Nrs * Srs))/(Nr * Tf * (1 + Nrs)).	]]></artwork>
	</artwork>
	</blockquote>

	<t>	<t>
	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 is Tf = 20 ms, 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 of Brtcp = 57 kbps. 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 <xref target="voip_rtcp_bw"/>.	as shown in <xref target="voip_rtcp_bw"/>.
	</t>	</t>

	<table anchor='voip_rtcp_bw'>	<table anchor='voip_rtcp_bw'>

	<name>RTCP bandwidth needed for VoIP feedback (compound reports only)< /name>	<name>RTCP Bandwidth Needed for VoIP Feedback (Compound Reports Only)< /name>
	<thead>	<thead>
	<tr>	<tr>

	<td align='center'>Tf (seconds)</td>	<th align='center'>Tf (seconds)</th>
	<td align='center'>Nr (frames)</td>	<th align='center'>Nr (frames)</th>
	<td align='center'>rtcp_bw (kbps)</td>	<th align='center'>rtcp_bw (kbps)</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td> 0.020 </td>	<td> 0.020 </td>
	<td> 2 </td>	<td> 2 </td>
	<td> 57.0 </td>	<td> 57.0 </td>
	</tr>	</tr>
	<tr>	<tr>
	<td> 0.020 </td>	<td> 0.020 </td>

	skipping to change at line 380 ¶	skipping to change at line 397 ¶
	</tr>	</tr>
	<tr>	<tr>
	<td> 0.060 </td>	<td> 0.060 </td>
	<td> 16 </td>	<td> 16 </td>
	<td> 2.8 </td>	<td> 2.8 </td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<t>	<t>

	The final row of <xref target="voip_rtcp_bw"/> (60ms frames, report	The final row of <xref target="voip_rtcp_bw"/> (60 ms frames, reportin g
	every 16 frames) sends RTCP reports once per second, giving an RTCP	every 16 frames) sends RTCP reports once per second, giving an RTCP

	bandwidth overhead of 2.8kbps.	bandwidth overhead of 2.8 kbps.
	</t>	</t>

	<t>	<t>
	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 <xref target="RFC5506"/>. For example, if we alternate	RTCP packets <xref target="RFC5506"/>. For example, if we alternate
	compound and reduced-size RTCP packets, i.e., Nrs = 1, the calculation	compound and reduced-size RTCP packets, i.e., Nrs = 1, the calculation
	gives the results shown in <xref target="voip_rtcp_bw_non-compound"/>.	gives the results shown in <xref target="voip_rtcp_bw_non-compound"/>.
	</t>	</t>

	<table anchor='voip_rtcp_bw_non-compound'>	<table anchor='voip_rtcp_bw_non-compound'>

	<name>Required RTCP bandwidth for VoIP feedback (alternating compound and reduced-size reports)</name>	<name>Required RTCP Bandwidth for VoIP Feedback (Alternating Compound and Reduced-Size Reports)</name>
	<thead>	<thead>
	<tr>	<tr>

	<td align='center'>Tf (seconds)</td>	<th align='center'>Tf (seconds)</th>
	<td align='center'>Nr (frames)</td>	<th align='center'>Nr (frames)</th>
	<td align='center'>rtcp_bw (kbps)</td>	<th align='center'>rtcp_bw (kbps)</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td> 0.020 </td>	<td> 0.020 </td>
	<td> 2 </td>	<td> 2 </td>
	<td> 41.4 </td>	<td> 41.4 </td>
	</tr>	</tr>
	<tr>	<tr>
	<td> 0.020 </td>	<td> 0.020 </td>

	skipping to change at line 446 ¶	skipping to change at line 463 ¶
	</tr>	</tr>
	<tr>	<tr>
	<td> 0.060 </td>	<td> 0.060 </td>
	<td> 16 </td>	<td> 16 </td>
	<td> 2.2 </td>	<td> 2.2 </td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<t>	<t>

	The RTCP bandwidth needed for 60ms frames, reporting every 16	The RTCP bandwidth needed for 60 ms frames, reporting every 16
	frames (once per second), can be seen to drop to 2.2kbps. This	frames (once per second), can be seen to drop to 2.2 kbps. This
	calculation can be repeated for other patterns of compound and	calculation can be repeated for other patterns of compound and
	reduced-size RTCP packets, feedback frequency, and frame duration,	reduced-size RTCP packets, feedback frequency, and frame duration,
	as needed.	as needed.
	</t>	</t>


	<t>	<aside><t>
	Note: To achieve the RTCP transmission intervals above the	Note: To achieve the RTCP transmission intervals above, the
	RTP/SAVPF profile with T_rr_interval=0 is used, since even when	RTP/SAVPF profile with T_rr_interval=0 is used, since even when
	using the reduced minimal transmission interval, the RTP/SAVP	using the reduced minimal transmission interval, the RTP/SAVP

	profile would only allow sending RTCP at most every 0.11s (every	profile would only allow sending RTCP at most every 0.11 s (every
	third frame of video). Using RTP/SAVPF with T_rr_interval=0	third frame of video). Using RTP/SAVPF with T_rr_interval=0,
	however is capable of fully utilizing the configured 5% RTCP	however, enables full utilization of the configured 5% RTCP bandwidth
	bandwidth fraction.	fraction.
	</t>	</t> </aside>

	<t>	<t>
	The use of IPv6 will increase the overhead by 20 octets per packet,	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,	due to the increased size of the IPv6 header compared to IPv4,
	assuming no IP options in either case. This increases the size	assuming no IP options in either case. This increases the size

	of compound packets to Sc = 162 + 2*Nr octets and reduced size	of compound packets to Sc = 162 + (2 * Nr) octets and reduced-size
	packets to Srs = 82 + 2*Nr. Re-running the calculations from	packets to Srs = 82 + (2 * Nr). Rerunning the calculations from
	<xref target="voip_rtcp_bw"/> with these packet sizes gives the	<xref target="voip_rtcp_bw"/> with these packet sizes gives the
	results shown in <xref target="voip_rtcp_bw_ipv6"/>.	results shown in <xref target="voip_rtcp_bw_ipv6"/>.
	As can be seen, there is a significant increase in overhead	As can be seen, there is a significant increase in overhead
	due to the use of IPv6.	due to the use of IPv6.
	</t>	</t>
	<table anchor='voip_rtcp_bw_ipv6'>	<table anchor='voip_rtcp_bw_ipv6'>

	<name>RTCP bandwidth needed for VoIP feedback (compound reports only) using IPv6</name>	<name>RTCP Bandwidth Needed for VoIP Feedback (Compound Reports Only) Using IPv6</name>
	<thead>	<thead>
	<tr>	<tr>

	<td align='center'>Tf (seconds)</td>	<th align='center'>Tf (seconds)</th>
	<td align='center'>Nr (frames)</td>	<th align='center'>Nr (frames)</th>
	<td align='center'>rtcp_bw (kbps)</td>	<th align='center'>rtcp_bw (kbps)</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td> 0.020 </td>	<td> 0.020 </td>
	<td> 2 </td>	<td> 2 </td>
	<td> 64.8 </td>	<td> 64.8 </td>
	</tr>	</tr>
	<tr>	<tr>
	<td> 0.020 </td>	<td> 0.020 </td>

	skipping to change at line 535 ¶	skipping to change at line 552 ¶
	</table>	</table>

	<t>	<t>
	Repeating the calculations from <xref target="voip_rtcp_bw_non-compoun d"/>	Repeating the calculations from <xref target="voip_rtcp_bw_non-compoun d"/>
	using IPv6 gives the results shown in <xref target="voip_rtcp_bw_non-c ompound_ipv6"/>.	using IPv6 gives the results shown in <xref target="voip_rtcp_bw_non-c ompound_ipv6"/>.
	As can be seen, the overhead still increases with IPv6 when	As can be seen, the overhead still increases with IPv6 when
	a mix of compound and reduced-size reports is used, but the	a mix of compound and reduced-size reports is used, but the
	effect is less pronounced than with compound reports only.	effect is less pronounced than with compound reports only.
	</t>	</t>
	<table anchor='voip_rtcp_bw_non-compound_ipv6'>	<table anchor='voip_rtcp_bw_non-compound_ipv6'>

	<name>Required RTCP bandwidth for VoIP feedback (alternating compound and reduced-size reports) using IPv6</name>	<name>Required RTCP Bandwidth for VoIP Feedback (Alternating Compound and Reduced-Size Reports) Using IPv6</name>
	<thead>	<thead>
	<tr>	<tr>

	<td align='center'>Tf (seconds)</td>	<th align='center'>Tf (seconds)</th>
	<td align='center'>Nr (frames)</td>	<th align='center'>Nr (frames)</th>
	<td align='center'>rtcp_bw (kbps)</td>	<th align='center'>rtcp_bw (kbps)</th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td> 0.020 </td>	<td> 0.020 </td>
	<td> 2 </td>	<td> 2 </td>
	<td> 49.2 </td>	<td> 49.2 </td>
	</tr>	</tr>
	<tr>	<tr>
	<td> 0.020 </td>	<td> 0.020 </td>

	skipping to change at line 593 ¶	skipping to change at line 610 ¶
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	</section>	</section>

	<section title="Scenario 2: Point-to-Point Video Conference" anchor="sec-p 2p-video">	<section title="Scenario 2: Point-to-Point Video Conference" anchor="sec-p 2p-video">
	<t>	<t>
	Consider a point-to-point	Consider a point-to-point
	video call between two end systems. There will be four RTP flows in	video call between two end systems. There will be four RTP flows in

	this scenario, two audio and two video, with all four flows being	this scenario (two audio and two video), with all four flows being
	active for essentially all the time (the audio flows will likely	active for essentially all the time (the audio flows will likely
	use voice activity detection and comfort noise to reduce the packet	use voice activity detection and comfort noise to reduce the packet
	rate during silent periods, but this does not cause the transmissions to	rate during silent periods, but this does not cause the transmissions to
	stop).	stop).
	</t>	</t>

	<t>	<t>
	Assume all four flows are sent in a single RTP session, each using	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	a separate SSRC. The RTCP reports from the co-located audio and video
	SSRCs at each end point are aggregated <xref target="RFC8108"/>,	SSRCs at each end point are aggregated <xref target="RFC8108"/>,

	the optimisations in <xref target="RFC8861"/> are used, and RTCP	the optimizations in <xref target="RFC8861"/> are used, and RTCP
	congestion control feedback is sent <xref target="RFC8888"/>.	congestion control feedback is sent <xref target="RFC8888"/>.
	</t>	</t>

	<t>	<t>

	As in <xref target="sec-p2p-audio"/>, when all members are senders	As in <xref target="sec-p2p-audio"/>, when all members are senders,
	the RTCP reporting interval calculation	the RTCP reporting interval calculation in Sections <xref target="RFC3
	in Section 6.2 and 6.3 of <xref target="RFC3550"/> and <xref target="R	550" section="6.2"
	FC4585"/>	sectionFormat="bare"/> and <xref target="RFC3550"
	reduces to:	section="6.3" sectionFormat="bare"/>
		<xref target="RFC3550"/> and in <xref target="RFC4585"/> reduces to:
	</t>	</t>

	<blockquote>	<artwork name="" type="" align="left"><![CDATA[
	<artwork>	Trtcp = n * Srtcp / Brtcp
	Trtcp = n * Srtcp / Brtcp	]]></artwork>
	</artwork>
	</blockquote>
	<t>	<t>
	where n is the number of members in the session, Srtcp is the	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	average RTCP packet size in octets, and Brtcp is the RTCP
	bandwidth in octets per second.	bandwidth in octets per second.
	</t>	</t>

	<t>	<t>

	The average RTCP packet size, Srtcp, depends on the amount of feedback	The average RTCP packet size (Srtcp) depends on the amount of feedback
	sent in each RTCP packet, on the number of members in the	sent in each RTCP packet, the number of members in the
	session, on the size of source description (RTCP SDES) information	session, the size of source description (RTCP SDES) information
	sent, and on the amount of congestion control feedback sent in each	sent, and the amount of congestion control feedback sent in each
	packet.	packet.
	</t>	</t>

	<t>	<t>
	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	When the RTCP reporting group extensions are used, one of these
	SSRCs will be a reporting SSRC, to which the other SSRC will have	SSRCs will be a reporting SSRC, to which the other SSRC will have
	delegated its reports. No reduced-size RTCP packets are sent.	delegated its reports. No reduced-size RTCP packets are sent.
	</t>	</t>

	<t>	<t>
	The aggregated compound RTCP packet from the non-reporting SSRC	The aggregated compound RTCP packet from the non-reporting SSRC
	will contain an RTCP SR packet, an RTCP SDES packet, and an RTCP	will contain an RTCP SR packet, an RTCP SDES packet, and an RTCP

	RGRS packet. The RTCP SR packet contains the 28 octet UDP/IP header	Reporting Group Reporting Sources (RGRS) packet. The RTCP SR packet
		contains the 28-octet UDP/IP header
	(assuming IPv4 with no options) and	(assuming IPv4 with no options) and

	sender information, but no report blocks (since the reporting is	sender information but no report blocks (since the reporting is
	delegated). The RTCP SDES packet will comprise a header (4 octets),	delegated). The RTCP SDES packet will comprise a header (4 octets),

	originating SSRC (4 octets), a CNAME chunk, a terminating chunk,	the originating SSRC (4 octets), a CNAME chunk, a terminating chunk,
	and any padding. If the CNAME follows <xref target="RFC7022"/> and	and any padding. If the CNAME follows <xref target="RFC7022"/> and

	<xref target="RFC8834"/> the CNAME chunk will be 18 octets in	<xref target="RFC8834"/>, the CNAME chunk will be 18 octets in
	size, and will be followed by one octet of padding and one terminating	size and will be followed by one octet of padding and one terminating
	null octet to align the SDES packet to a 32-bit boundary	null octet to align the SDES packet to a 32-bit boundary

	(<xref target="RFC3550"/>, section 6.5), making the SDES packet 28	(<xref target="RFC3550" sectionFormat="comma" section="6.5"/>), making the SDES packet 28
	octets in size. The RTCP RGRS packet will be 12 octets in size.	octets in size. The RTCP RGRS packet will be 12 octets in size.
	This gives a total of 28 + 28 + 12 = 68 octets.	This gives a total of 28 + 28 + 12 = 68 octets.
	</t>	</t>

	<t>	<t>
	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.	congestion control feedback packet.
	The RTCP SR packet will contain two report blocks, one for each of	The RTCP SR packet will contain two report blocks, one for each of
	the remote SSRCs (the report for the other local SSRC is suppressed	the remote SSRCs (the report for the other local SSRC is suppressed
	by the reporting group extension), for a total of 28 + (2 * 24) =	by the reporting group extension), for a total of 28 + (2 * 24) =

	76 octets.	76 octets. The RTCP SDES packet will
	The RTCP SDES packet will comprise a header (4 octets), originating	comprise a header (4 octets), originating SSRC (4 octets), a CNAME
	SSRC (4 octets), a CNAME chunk, an RGRP chunk, a terminating chunk,	chunk, a Reporting Group (RGRP) chunk, a terminating chunk, and any
	and any padding. If the CNAME follows <xref target="RFC7022"/> and	padding. If the CNAME follows <xref target="RFC7022"/> and <xref
	<xref target="RFC8834"/> it will be 18 octets in	target="RFC8834"/>, it will be 18 octets in size.
	size. The RGRP chunk similarly comprises 18 octets, and 3 octets of	The RGRP chunk similarly comprises 18 octets, the terminating
	padding are needed, for a total of 48 octets.	chunk is comprised of 1 octet, and 3 octets of padding are needed,
		for a total of 48 octets.
	The RTCP congestion control feedback (CCFB) report comprises an 8-octe t	The RTCP congestion control feedback (CCFB) report comprises an 8-octe t

	RTCP header and SSRC, a 4-octet report timestamp, and for each of the	RTCP header and SSRC, a 4-octet report timestamp, and for
	remote	each of the remote audio and video SSRCs, an 8-octet report header, 2 o
	audio and video SSRCs, an 8-octet report header, and 2 octets per pack	ctets per packet
	et	reported upon, and padding to a 4-octet boundary if needed; that is,
	reported upon, and padding to a 4-octet boundary if needed; that is	8 + 4 + 8 + (2 * Nv) + 8 + (2 * Na), where Nv is the number of video
	8 + 4 + 8 + (2 * Nv) + 8 + (2 * Na) where Nv is the number of video	packets per report and Na is the number of audio packets per report.
	packets per report, and Na is the number of audio packets per report.
	</t>	</t>

	<t>	<t>
	The complete compound RTCP packet contains the RTCP packets from	The complete compound RTCP packet contains the RTCP packets from
	both the reporting and non-reporting SSRCs, an SRTCP trailer and authe ntication	both the reporting and non-reporting SSRCs, an SRTCP trailer and authe ntication

	tag, and a UDP/IPv4 header. The size of this RTCP packet is therefore:	tag, and a UDP/IPv4 header. The size of this RTCP packet is therefore
	262 + (2 * Nv) + (2 * Na) octets.	262 + (2 * Nv) + (2 * Na) octets.
	Since the aggregate RTCP packet contains reports from two SSRCs, the	Since the aggregate RTCP packet contains reports from two SSRCs, the
	RTCP packet size is halved before use <xref target="RFC8108"/>.	RTCP packet size is halved before use <xref target="RFC8108"/>.
	Accordingly, the size of the RTCP packets is:	Accordingly, the size of the RTCP packets is:
	</t>	</t>

	<blockquote>	<artwork name="" type="" align="left"><![CDATA[
	<artwork>	Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2
	Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2	]]></artwork>
	</artwork>
	</blockquote>

	<t>	<t>
	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?	what are the values of Nv and Na?

	This depends on the RTCP reporting interval, Trtcp, the video bit	This depends on the RTCP reporting interval (Trtcp), the video bit
	rate and frame rate, Rf, the audio bit rate and framing interval,	rate and frame rate (Rf), the audio bit rate and framing interval,
	and whether the receiver chooses to send congestion control feedback	and whether the receiver chooses to send congestion control feedback
	in each RTCP packet it sends.	in each RTCP packet it sends.
	</t>	</t>

	<t>	<t>
	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	report for each frame of video received (i.e., Trtcp = 1 / Rf) and
	to include a congestion control feedback packet in each report.	to include a congestion control feedback packet in each report.

	Assume that video has constant bit rate and frame rate, and that	Assume that video has a constant bit rate and frame rate and that
	each frame of video has to fit into a 1500 octet MTU. Further,	each frame of video has to fit into a 1500-octet MTU. Further,
	assume that the audio takes negligible bandwidth, and that the	assume that the audio takes negligible bandwidth and that the
	audio framing interval can be varied within reasonable bounds, so	audio framing interval can be varied within reasonable bounds, so
	that an integral number of audio frames align with video frame	that an integral number of audio frames align with video frame
	boundaries.	boundaries.
	</t>	</t>

	<t>	<t>
	<xref target="scenario2-compound"/> shows the resulting values of	<xref target="scenario2-compound"/> shows the resulting values of

	Nv and Na, the number of video and audio packets covered by each	Nv and Na (the number of video and audio packets covered by each
	congestion control feedback report, for a range of data rates and	congestion control feedback report) for a range of data rates and
	video frame rates, assuming congestion control feedback is sent	video frame rates, assuming congestion control feedback is sent
	once per video frame.	once per video frame.
	The table also shows the result of inverting the RTCP reporting	The table also shows the result of inverting the RTCP reporting

	interval calculation to find the corresponding RTCP bandwidth,	interval calculation to find the corresponding RTCP bandwidth
	Brtcp. The RTCP bandwidth is given in kbps and as a fraction of	(Brtcp). The RTCP bandwidth is given in kbps and as a fraction of
	the data rate.	the data rate.
	</t>	</t>

	<t>	<t>

	It can be seen that, for example, with a date rate of 1024 kbps	It can be seen that, for example, with a data rate of 1024 kbps
	and video sent at 30 frames-per-second, the RTCP congestion control	and a video sent at 30 frames per second, the RTCP congestion control
	feedback report sent for each video frame will include reports on	feedback report sent for each video frame will include reports on
	3 video packets and 2 audio packets. The RTCP bandwidth needed to	3 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.5 kbps (12% of the data rate).
	This assumes an audio framing interval of 16.67ms, so that two	This assumes an audio framing interval of 16.67 ms, so that 2
	audio packets are sent for each video frame.	audio packets are sent for each video frame.
	</t>	</t>

	<table anchor='scenario2-compound'>	<table anchor='scenario2-compound'>

	<name>Required RTCP bandwidth, reporting on every frame</name>	<name>Required RTCP Bandwidth, Reporting on Every Frame</name>
	<thead>	<thead>
	<tr>	<tr>

	<td align='center'> Data Rate (kbps) </td>	<th align='center'> Data Rate (kbps) </th>
	<td align='center'> Video Frame Rate: Rf </td>	<th align='center'> Video Frame Rate: Rf </th>
	<td align='center'> Video Packets per Report: Nv </td>	<th align='center'> Video Packets per Report: Nv </th>
	<td align='center'> Audio Packets per Report: Na </td>	<th align='center'> Audio Packets per Report: Na </th>
	<td align='center'> Required RTCP bandwidth: Brtcp (kbps) </td>	<th align='center'> Required RTCP Bandwidth: Brtcp (kbps) </th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td> 100 </td>	<td> 100 </td>
	<td> 8 </td>	<td> 8 </td>
	<td> 1 </td>	<td> 1 </td>
	<td> 6 </td>	<td> 6 </td>
	<td> 34.5 (34%) </td>	<td> 34.5 (34%) </td>
	</tr>	</tr>

	skipping to change at line 843 ¶	skipping to change at line 859 ¶
	<td> 4096 </td>	<td> 4096 </td>
	<td> 60 </td>	<td> 60 </td>
	<td> 6 </td>	<td> 6 </td>
	<td> 1 </td>	<td> 1 </td>
	<td> 258.8 ( 6%) </td>	<td> 258.8 ( 6%) </td>
	</tr>	</tr>

	</tbody>	</tbody>
	</table>	</table>


	<!--
	<t>
	The RTCP bandwidth needed scales inversely with the report frequency.
	That is, it is halved when reporting on every second frame, reduced
	to one-third when reporting on every third frame, and so on.
	</t>

	<t>	<t>

	The needed RTCP bandwidth scales as a percentage	Use of reduced-size RTCP <xref target="RFC5506"/> would allow the SR
	of the data rate following the ratio of the frame rate to the data	and SDES packets to be omitted from some reports. These reduced-size
	rate. As can be seen from the table above, the RTCP bandwidth needed
	is a significant fraction of the media rate if reporting on every
	frame for low rate video. This can be solved by reporting less often
	at lower rates. For example, to report on every frame of 8fps
	video sent at 100kbps requires the RTCP bandwidth to be 34% of the med
	ia rate;
	reporting every fourth frame (i.e., twice per second) reduces this
	overhead to 5%.
	</t>

	<t>
	Use of reduced size RTCP <xref target="RFC5506"/> would allow the SR
	and SDES packets to be omitted from some reports. These "reduced-size"
	RTCP packets would	RTCP packets would

	contain an RTCP RGRS packet from the non-reporting SSRC, and an RTCP	contain an RTCP RGRS packet from the non-reporting SSRC and an RTCP
	SDES RGRP packet and a congestion control feedback packet from the	SDES RGRP packet and a congestion control feedback packet from the

	reporting SSRC. This will be 12 + 28 + 12 + 8 + 2Nv + 8 + 2Na octets	reporting SSRC. This will be 12 + 28 + 12 + 8 + (2 * Nv) + 8 + (2 * Na
	,	) octets,
	plus the SRTCP trailer and authentication tag, and a UDP/IP header.	plus the SRTCP trailer and authentication tag and a UDP/IP header.
	That is, the size of the reduced-size packets would be (110 + 2*Nv + 2	That is, the size of the reduced-size packets would be (110 + (2 * Nv)
	*Na)/2	+ (2 * Na)) / 2
	octets. Repeating the analysis above,	octets. Repeating the analysis above,

	but alternating compound and reduced-size reports gives results as sho wn	but alternating compound and reduced-size reports, gives the results s hown
	in <xref target="scenario2-compound-noncompound"/>.	in <xref target="scenario2-compound-noncompound"/>.
	</t>	</t>

	<table anchor='scenario2-compound-noncompound'>	<table anchor='scenario2-compound-noncompound'>

	<name>Required RTCP bandwidth, reporting on every frame, with reduced- size reports</name>	<name>Required RTCP Bandwidth, Reporting on Every Frame, with Reduced- Size Reports</name>
	<thead>	<thead>
	<tr>	<tr>

	<td align='center'> Data Rate (kbps) </td>	<th align='center'> Data Rate (kbps) </th>
	<td align='center'> Video Frame Rate: Rf </td>	<th align='center'> Video Frame Rate: Rf </th>
	<td align='center'> Video Packets per Report: Nv </td>	<th align='center'> Video Packets per Report: Nv </th>
	<td align='center'> Audio Packets per Report: Na </td>	<th align='center'> Audio Packets per Report: Na </th>
	<td align='center'> Required RTCP bandwidth: Brtcp (kbps) </td>	<th align='center'> Required RTCP Bandwidth: Brtcp (kbps) </th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td> 100 </td>	<td> 100 </td>
	<td> 8 </td>	<td> 8 </td>
	<td> 1 </td>	<td> 1 </td>
	<td> 6 </td>	<td> 6 </td>
	<td> 25.0 (25%) </td>	<td> 25.0 (25%) </td>
	</tr>	</tr>

	skipping to change at line 982 ¶	skipping to change at line 978 ¶
	<td> 6 </td>	<td> 6 </td>
	<td> 1 </td>	<td> 1 </td>
	<td> 187.5 ( 4%) </td>	<td> 187.5 ( 4%) </td>
	</tr>	</tr>

	</tbody>	</tbody>
	</table>	</table>

	<t>	<t>
	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	needed RTCP bandwidth and can be combined with reporting every
	few frames rather than every frame. Overall, it is clear that	few frames, rather than every frame. Overall, it is clear that
	the RTCP overhead can be reasonable across the range of data and	the RTCP overhead can be reasonable across the range of data and

	frame rates, if RTCP is configured carefully.	frame rates if RTCP is configured carefully.
	</t>	</t>

	<t>	<t>
	As discussed in <xref target="sec-p2p-audio"/>, the reporting overhead will	As discussed in <xref target="sec-p2p-audio"/>, the reporting overhead will
	increase if IPv6 is used, due to the increased size of the IPv6	increase if IPv6 is used, due to the increased size of the IPv6
	header. <xref target="scenario2-compound-noncompound-ipv6"/> shows	header. <xref target="scenario2-compound-noncompound-ipv6"/> shows
	the overhead in this case, compared to	the overhead in this case, compared to
	<xref target="scenario2-compound-noncompound"/>. As can be seen,	<xref target="scenario2-compound-noncompound"/>. As can be seen,
	the increase in overhead due to IPv6 rapidly becomes less significant as the data	the increase in overhead due to IPv6 rapidly becomes less significant as the data
	rate increases.	rate increases.
	</t>	</t>
	<table anchor='scenario2-compound-noncompound-ipv6'>	<table anchor='scenario2-compound-noncompound-ipv6'>

	<name>Required RTCP bandwidth, reporting on every frame, with reduced- size reports, using IPv6</name>	<name>Required RTCP Bandwidth, Reporting on Every Frame, with Reduced- Size Reports, Using IPv6</name>
	<thead>	<thead>
	<tr>	<tr>

	<td align='center'> Data Rate (kbps) </td>	<th align='center'> Data Rate (kbps) </th>
	<td align='center'> Video Frame Rate: Rf </td>	<th align='center'> Video Frame Rate: Rf </th>
	<td align='center'> Video Packets per Report: Nv </td>	<th align='center'> Video Packets per Report: Nv </th>
	<td align='center'> Audio Packets per Report: Na </td>	<th align='center'> Audio Packets per Report: Na </th>
	<td align='center'> Required RTCP bandwidth: Brtcp (kbps) </td>	<th align='center'> Required RTCP Bandwidth: Brtcp (kbps) </th>
	</tr>	</tr>
	</thead>	</thead>
	<tbody>	<tbody>
	<tr>	<tr>
	<td> 100 </td>	<td> 100 </td>
	<td> 8 </td>	<td> 8 </td>
	<td> 1 </td>	<td> 1 </td>
	<td> 6 </td>	<td> 6 </td>
	<td> 27.5 (27%) </td>	<td> 27.5 (27%) </td>
	</tr>	</tr>

	skipping to change at line 1101 ¶	skipping to change at line 1097 ¶
	<td> 60 </td>	<td> 60 </td>
	<td> 6 </td>	<td> 6 </td>
	<td> 1 </td>	<td> 1 </td>
	<td> 206.2 ( 5%) </td>	<td> 206.2 ( 5%) </td>
	</tr>	</tr>

	</tbody>	</tbody>
	</table>	</table>
	</section>	</section>


	<!--
	<section title="Scenario 3: Group Video Conference" anchor="sec-group-vide
	o">
	<t>
	Group video conferences can be implemented using a centralised
	model, where each participant sends the audio, a video thumbnail,
	and a full quality video stream to a central mixer, and the mixer
	forwards a subset of the audio and full quality video streams
	for the active speakers, along with the thumbnail-sized streams
	for the other participants.
	</t>

	<t>
	In this model, congestion control for the RTP streams sent from the
	participants to the mixer is handled similarly to the scenario in
	<xref target="sec-p2p-video"/>.
	</t>

	<t>
	In this model, each participant sends three RTP streams to the mixer,
	each using a different SSRC, representing audio, video thumbnail, and
	full-size video. The mixer sends to each participant a total of Np
	thumbnail video streams, where Np is the number of participants in the
	conference, with each stream using its own SSRC. In addition, the
	mixer forwards the full size video and audio streams for the active
	speaker, using SSRCs representing the mixed audio and switched video.
	Each leg of the conference therefore sees three RTP streams flowing
	from the participant to mixer, and (Np - 1) + 2 RTP streams flowing
	from mixer to the participant (Np - 1 RTP streams sending the thumbnai
	ls
	from the other participants, and two streams for the audio and video
	from the active speaker).
	</t>

	<t>
	Assume that the RTCP reports for the audio and video sent from the
	participant are aggregated into compound packets <xref target="RFC8108
	"/>
	and the RTCP grouping extensions from <xref target="RFC8861"/> are use
	d.
	Similarly, assume that RTCP reports for the video thumbnail streams, t
	he
	audio stream, and the full size video stream are generated by the mixe
	r,
	aggregated into compound packets, and the RTCP grouping extensions are
	used.
	</t>

	<t>
	As in the point-to-point video scenario described <xref target="sec-p2
	p-video"/>,
	since all members are senders the RTCP timing rules in Section 6.2 and
	6.3 of <xref target="RFC3550"/> and <xref target="RFC4585"/> reduce to
	:

	<blockquote>
	<artwork>
	Trtcp = Srtcp * n / Brtcp
	</artwork>
	</blockquote>

	where n is the number of members in the session, Srtcp is the average
	RTCP packet size measured in octets, and Brtcp is the RTCP bandwidth
	in octets per second.
	</t>

	<t>
	The number of members in the session, n = Np + 4. Each participant
	sends a thumbnail video stream, and there is one audio and one full
	size video stream flowing from participant to mixer, and one audio
	and one full size video stream flowing from mixer to participant.
	The mixer does not forward the participant's thumbnail back to it.
	</t>

	<t>
	The RTCP packets sent by the participant will all be compound RTCP
	packets containing...
	They have size...
	</t>

	<t>
	The RTCP packets sent by the mixer will all be compound RTCP packets
	containing...
	They have size...
	</t>

	<t>
	The average RTCP packet size, Srtcp, will therefore be...
	</t>

	<t>
	</t>

	<!--
	<t>
	Audio: 20ms frames, at a range of bit rates (the bit rate is likely
	unimportant). Every participant sends. Middlebox forwards 5 streams
	to all participants.
	</t>

	<t>
	Main video: 30fps, 500kbps
	</t>

	<t>
	Thumb video: 10-15 streams, 1 packet per frame, low rate (7fps?)
	</t>
	-->

	<!--
	<t>
	Other implementation strategies for group video conferences exist,
	using different RTP topologies. This analysis in this section is
	intended to be representative of the congestion control bandwidth
	overhead, rather than being an exact match for the implementation
	strategy of any particular product.
	</t>

	</section>
	</section>	</section>

	<section title="Discussion and Conclusions">	<section title="Discussion and Conclusions">
	<t>	<t>
	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 Session Traversal Utili
	to keep-alive NAT bindings <xref target="RFC8445"/>, WebRTC Data	ties for NAT (STUN) / Traversal Using Relays around NAT (TURN) packets
	Channel packets <xref target="RFC8831"/>, etc. Such traffic also	to keep alive NAT bindings <xref target="RFC8445"/>, WebRTC data
		channel packets <xref target="RFC8831"/>, etc. Such traffic also
	needs congestion control, but the means by which this is achieved	needs congestion control, but the means by which this is achieved

	is out of scope of this memo.	is out of the scope of this memo.
	</t>	</t>

	<t>	<t>

	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.
	</t>	</t>

	<t>	<t>
	RTCP can, however, be used to send congestion	RTCP can, however, be used to send congestion
	feedback on each frame of video sent, provided the session bandwidth	feedback on each frame of video sent, provided the session bandwidth

	exceeds a couple of megabits per second (the exact rate depending on	exceeds a couple of megabits per second (the exact rate depends on
	the number of session participants, the RTCP bandwidth fraction, and	the number of session participants, the RTCP bandwidth fraction,
	what RTCP extensions are enabled, and how much detail of feedback is	what RTCP extensions are enabled, and how much detail of feedback is

	needed). For lower rate sessions, the overhead of reporting on every	needed). For lower-rate sessions, the overhead of reporting on every
	frame becomes high, but can be reduced to something reasonable by	frame 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.	sending reduced-size RTCP reports in between the regular reports.
	The improved compression of new video codecs exacerbates the	The improved compression of new video codecs exacerbates the
	reporting overhead for a given video quality level, although this	reporting overhead for a given video quality level, although this

	is to some extent countered by the use of higher quality video	is to some extent countered by the use of higher-quality video
	over time.	over time.
	</t>	</t>

	<t>	<t>
	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 fee dback	frames, since that fits within the limitations of RTCP. The provided fee dback
	will be more detailed than just an acknowledgement, however, and will pr ovide	will be more detailed than just an acknowledgement, however, and will pr ovide

	a loss bitmap, relative arrival time, and received ECN marks, for each	a loss bitmap, relative arrival time, and received Explicit Congestion N otification (ECN) marks for each
	packet sent. This will allow congestion control	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 <xref target="RFC8
	<xref target="RFC8085"/>).	085" section="3.1" sectionFormat="of"/>).
	</t>	</t>

	<t>	<t>
	The format described in <xref target="RFC8888"/>	The format described in <xref target="RFC8888"/>
	seems sufficient for the needs of congestion control feedback. There	seems sufficient for the needs of congestion control feedback. There

	is little point optimising this format: the main overhead comes from	is little point optimizing this format; the main overhead comes from
	the UDP/IP headers and the other RTCP packets included in the compound	the UDP/IP headers and the other RTCP packets included in the compound

	packets, and can be lowered by using the <xref target="RFC5506"/>	packets and can be lowered by using the extensions described in
	extensions and sending reports less frequently. The use of header	<xref target="RFC5506"/> and sending reports less frequently. The use of
	compression <xref target="RFC2508"/>, <xref target="RFC3545"/>,	header
		compression <xref target="RFC2508"/> <xref target="RFC3545"/>
	<xref target="RFC5795"/> can also be beneficial.	<xref target="RFC5795"/> can also be beneficial.
	</t>	</t>

	<t>	<t>

	Further study of the scenarios of interest is needed, to ensure that	Further study of the scenarios of interest is needed to ensure that
	the analysis presented is applicable to other media topologies	the analysis presented is applicable to other media topologies

	<xref target="RFC7667"/>, and to sessions with different data rates	<xref target="RFC7667"/> and to sessions with different data rates
	and sizes of membership.	and sizes of membership.
	</t>	</t>

	</section>	</section>

	<section title="Security Considerations">	<section title="Security Considerations">
	<t>	<t>
	An attacker that can modify or spoof RTCP congestion control feedback	An attacker that can modify or spoof RTCP congestion control feedback

	packets can manipulate the sender behaviour to cause denial of service.	packets can manipulate the sender behavior to cause denial of service.
	This can be prevented by authentication and integrity protection of	This can be prevented by authentication and integrity protection of

	RTCP packets, for example using the secure RTP profile	RTCP packets, for example, using the secure RTP profile
	<xref target="RFC3711"/><xref target="RFC5124"/>, or by other means	<xref target="RFC3711"/> <xref target="RFC5124"/> or other means
	as discussed in <xref target="RFC7201"/>.	as discussed in <xref target="RFC7201"/>.
	</t>	</t>
	</section>	</section>

	<section title="IANA Considerations">	<section title="IANA Considerations">
	<t>	<t>

	There are no actions for IANA.	This document has no IANA actions.
	</t>	</t>
	</section>	</section>


	<section anchor="Acknowledgements" title="Acknowledgements">
	<t>
	Thanks to Bernard Aboba, Martin Duke, Linda Dunbar, Gorry Fairhurst,
	Ingemar Johansson, Shuping Peng, Alvaro Retana, Zahed Sarker, John
	Scudder, Éric Vyncke, Magnus Westerlund, and the members of the RMCAT
	feedback design team for their feedback.
	</t>
	</section>
	</middle>	</middle>
	<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->	<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
	<back>	<back>
	<references title="Normative References">	<references title="Normative References">

	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.291	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.291
	4.xml"/>	4.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.355	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.355
	0.xml"/>	0.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.371	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.371
	1.xml"/>	1.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.458	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.458
	5.xml"/>	5.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.512	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.512
	4.xml"/>	4.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.550	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.550
	6.xml"/>	6.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.702	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.702
	2.xml"/>	2.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.720	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.720
	1.xml"/>	1.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.810	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.810
	8.xml"/>	8.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.808	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.808
	3.xml"/>	3.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.808	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.808
	5.xml"/>	5.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.882	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.882
	5.xml"/>	5.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.883	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.883
	4.xml"/>	4.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.886	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.886
	1.xml"/>	1.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.887	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.887
	2.xml"/>	2.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.888	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.888
	8.xml"/>	8.xml"/>
	</references>	</references>
	<references title="Informative References">	<references title="Informative References">

	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.250	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.250
	8.xml"/>	8.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.344	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.344
	9.xml"/>	9.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.354	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.354
	5.xml"/>	5.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.361	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.361
	1.xml"/>	1.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.534	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.534
	8.xml"/>	8.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.579	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.579
	5.xml"/>	5.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.766	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.766
	7.xml"/>	7.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.844	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.844
	5.xml"/>	5.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.883	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.883
	1.xml"/>	1.xml"/>
	<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.929	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.929
	3.xml"/>	3.xml"/>
	</references>	</references>

		<section anchor="Acknowledgements" title="Acknowledgements" numbered="false"
		>
		<t>
		Thanks to <contact fullname="Bernard Aboba"/>, <contact
		fullname="Martin Duke"/>, <contact fullname="Linda Dunbar"/>,
		<contact fullname="Gorry Fairhurst"/>, <contact
		fullname="Ingemar Johansson"/>, <contact fullname="Shuping
		Peng"/>, <contact fullname="Alvaro Retana"/>, <contact
		fullname="Zahed Sarker"/>, <contact fullname="John Scudder"/>,
		<contact fullname="Éric Vyncke"/>, <contact fullname="Magnus Westerlund"
		/>, and the members of the RMCAT
		feedback design team for their feedback.
		</t>
		</section>
	</back>	</back>
	</rfc>	</rfc>
	<!-- vim: set ts=2 sw=2 tw=77 et ai: -->	<!-- vim: set ts=2 sw=2 tw=77 et ai: -->

End of changes. 113 change blocks.
	431 lines changed or deleted	327 lines changed or added
This html diff was produced by rfcdiff 1.48.