University of Glasgow

School of Computing Science Glasgow G12 8QQ United Kingdom csp@csperkins.org

tsv rmcat RTP Congestion Control VoIP Video Conferencing This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and the suitability of RTCP for implementing congestion control for unicast multimedia applications.

Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Terminology
• .  Considerations for RTCP Feedback
• .  What Feedback is Achievable with RTCP?
  • .  Scenario 1: Voice Telephony
  • .  Scenario 2: Point-to-Point Video Conference
• .  Discussion and Conclusions
• .  Security Considerations
• .  IANA Considerations
• .  Normative References
• .  Informative References
• Acknowledgements
• Author's Address

Introduction The deployment of WebRTC systems has resulted in high-quality video conferencing seeing extremely wide use. To ensure 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 traffic , allowing them to adapt and adjust the media data they send to match changes in the available network capacity. In addition to ensuring the stable operation of the network, such adaptation is critical to ensuring a good user experience, since it allows the sender to match the media to the network capacity, rather than forcing the receiver to compensate for uncontrolled packet loss when the available capacity is exceeded. To develop such congestion control, it is necessary to understand the sort of congestion feedback that can be provided within the framework of RTP and the RTP Control Protocol (RTCP). It then becomes possible to determine if this is sufficient for congestion 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 using RTCP under the RTP/SAVPF profile (the secure version of the RTP/AVPF profile ). This profile was chosen because it forms the basis for media transport in WebRTC systems. However, nothing in this memo is specific to the secure version of the profile or to WebRTC. It is also assumed that the congestion control feedback mechanism described in and common RTCP extensions for efficient feedback are used.

Terminology

Nr:

number of frames between feedback reports

Nrs:

number of reduced-size RTCP packets send for every compound RTCP packet

Na:

number of audio packets per report

Nv:

number of video packets per reports

Sc:

size of a compound RTCP packet

Srs:

size of a reduced-size RTCP packet

Tf:

duration of a media frame in seconds

Rf:

frame rate 1/Tf

Considerations for RTCP Feedback Several questions need to be answered when providing RTCP feedback for congestion control purposes. These include:

• How often is feedback needed?
• How much overhead is acceptable?
• How much and what data does each report contain?

However, the key question is as follows: how often does the receiver need to send feedback on the reception quality it is experiencing and hence the congestion state of the network? Widely used transport protocols, such as TCP, send acknowledgements 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 maximum segment size has been received . That has relatively low overhead when traffic is bidirectional and acknowledgements can be piggybacked onto return path data packets. It can also be acceptable, and can have reasonable overhead, to send separate acknowledgement packets when those packets are much smaller than data packets. Frequent acknowledgements can become a problem, however, when there is no return traffic on which to piggyback feedback or if separate 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 forms of media traffic, especially for Voice over IP (VoIP) flows, leading to high overhead when using a transport protocol that sends frequent feedback. Approaches like in-network filtering of acknowledgements that have been proposed to reduce acknowledgement overheads on highly asymmetric links (e.g., as mentioned in ) can also reduce the feedback frequency and overhead for multimedia traffic, but this so-called "stretch-ACK" behavior is nonstandard and not guaranteed. Accordingly, when implementing congestion control for RTP-based multimedia traffic, it might make sense to give the option of sending congestion feedback less often than TCP does. For example, it might be possible to send a feedback packet once per video frame, every few frames, or once per network round-trip time (RTT). This could still give sufficiently frequent feedback for the congestion control loop to be stable and responsive while keeping the overhead reasonable when the feedback cannot be piggybacked onto returning data. In this case, it is important to note that RTCP can send much more detailed feedback than simple acknowledgements. For example, if it were useful, it could be possible to use an RTCP extended report (XR) packet to send feedback once per RTT; 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 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 codec can react instantly to a rate change, and there is little point in providing feedback more often than the codec can adapt. 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. In the best case, this will match the media frame rate but might often be slower. Reducing the feedback frequency compared to TCP will reduce feedback overhead but will lead multimedia flows to adapt to congestion more slowly than TCP, raising concerns about inter-flow fairness. Similar concerns are noted in , and accordingly, the congestion control algorithm described therein aims for "reasonable" fairness and a sending rate that is "generally within a factor of two" of what TCP would achieve under the same conditions. It is to be noted, however, that TCP exhibits inter-flow unfairness when flows with differing round-trip times compete, and stretch acknowledgements due to in-network traffic manipulation are not uncommon and also raise fairness concerns. Implementations need to balance potential unfairness against feedback overhead. Generating and processing feedback consumes resources at the sender and receiver. The feedback packets also incur forwarding costs, contribute to link utilization, and can affect the timing of other traffic on the network. This can affect performance on some types of networks that can be impacted by the rate, timing, and size of feedback packets, as well as the overall volume of feedback bytes. The amount of overhead due to congestion control feedback that is considered acceptable has to be determined. RTCP feedback is sent in separate packets to RTP data, and this has some cost in terms of additional header overhead compared to protocols that piggyback feedback on return path data packets. The RTP standards have long said that a 5% overhead for RTCP traffic is generally acceptable. Is this still the case for congestion control feedback? Is there a desire to provide more responsive feedback and congestion control, possibly with a higher overhead? Or is lower overhead wanted, accepting that this might reduce responsiveness of the congestion control algorithm? 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. There is a fundamental trade-off that the more frequently feedback packets are sent, the less data can be included in each packet to keep the overhead constant. Does the congestion control need a high rate but simple feedback (e.g., like TCP acknowledgements), or is it acceptable to send more complex feedback less often? Is it useful for the congestion control to receive frequent feedback, perhaps to provide more accurate round-trip time estimates, or to provide robustness in case feedback packets are lost, even if the media sending rate cannot quickly be changed? Or is low-rate feedback, resulting in slowly responsive changes to the sending rate, acceptable? Different combinations of the congestion control algorithm and media codec might require different trade-offs, and the correct trade-off for interactive, self-paced, real-time multimedia traffic might not be the same as that for TCP congestion control.

What Feedback is Achievable with RTCP? The following sections illustrate how the RTCP congestion control feedback report can be used in different scenarios and illustrate the overheads of this approach.

Scenario 1: Voice Telephony In many ways, point-to-point voice telephony is the simplest scenario for congestion control, since there is only a single media stream to control. It's complicated, however, by severe bandwidth constraints on the feedback, to keep the overhead manageable. Assume a two-party, point-to-point VoIP call, using RTP over UDP/IP. A rate-adaptive speech codec, such as Opus, is used, encoded into RTP packets in frames of a duration of Tf seconds (Tf = 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, i.e., every Nr * Tf seconds, to ensure effective control. Both parties in the call send speech data or comfort noise with sufficient frequency that they are counted as senders for the purpose of the RTCP reporting interval calculation. RTCP feedback packets can be full (compound) RTCP feedback packets or reduced-size RTCP packets . A compound RTCP packet is sent once for every Nrs reduced-size RTCP packets. Compound RTCP packets contain a Sender Report (SR) packet, a Source Description (SDES) packet, and an RTP Congestion Control Feedback (CCFB) packet . Reduced-size RTCP packets contain only the CCFB packet. Since each participant sends only a single RTP media stream, the extensions for RTCP report aggregation and reporting group optimization are not used. Within each compound RTCP packet, the SR packet will contain a sender information block (28 octets) and a single reception report block (24 octets), for a total of 52 octets. A minimal SDES packet will contain a header (4 octets), a single chunk containing a synchronization source (SSRC) (4 octets), and a CNAME item, and if the recommendations for choosing the CNAME 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 size of 28 octets. The CCFB packets contain an RTCP header and SSRC (8 octets), a report timestamp (4 octets), the other party's SSRC, beginning and ending sequence numbers (8 octets), and 2 * Nr octets of reports, for a total of 20 + (2 * Nr) octets. The compound Secure RTCP (SRTCP) packet will include 4 octets of trailer, followed by an 80-bit (10-octet) authentication tag if HMAC-SHA1 authentication is used. If IPv4 is used, with no IP options, the UDP/IP header will be 28 octets in size. This gives a total compound RTCP packet size of Sc = 142 + (2 * Nr) octets. The reduced-size RTCP packets will comprise just the CCFB packet, 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. The RTCP reporting interval calculation (Sections and of and ) for a two-party session where both participants are senders reduces to: Trtcp = n * Srtcp / Brtcp where Srtcp = (Sc + Nrs * Srs) / (1 + Nrs) is the average RTCP packet 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 (in this scenario, n = 2). To ensure an RTCP report containing congestion control feedback is sent after every Nr frames of audio, it is necessary to set the RTCP reporting interval to Trtcp = Nr * Tf, which when substituted into the previous, gives Nr * Tf = n * Srtcp / Brtcp. Solving this to give the RTCP bandwidth (Brtcp) and expanding the definition of Srtcp gives: Brtcp = (n * (Sc + Nrs * Srs)) / (Nr * Tf * (1 + Nrs)) If we assume every report is a compound RTCP packet (i.e., Nrs = 0), 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 feedback bandwidth of Brtcp = 57 kbps. Increasing the frame duration or reducing the frequency of reports will reduce the RTCP bandwidth, as shown in . RTCP Bandwidth Needed for VoIP Feedback (Compound Reports Only)

Tf (seconds)	Nr (frames)	rtcp_bw (kbps)
0.020	2	57.0
0.020	4	29.3
0.020	8	15.4
0.020	16	8.5
0.060	2	19.0
0.060	4	9.8
0.060	8	5.1
0.060	16	2.8

The final row of (60 ms frames, reporting every 16 frames) sends RTCP reports once per second, giving an RTCP bandwidth overhead of 2.8 kbps. The overhead can be reduced by sending some reports in reduced-size RTCP packets . For example, if we alternate compound and reduced-size RTCP packets, i.e., Nrs = 1, the calculation gives the results shown in . Required RTCP Bandwidth for VoIP Feedback (Alternating Compound and Reduced-Size Reports)

Tf (seconds)	Nr (frames)	rtcp_bw (kbps)
0.020	2	41.4
0.020	4	21.5
0.020	8	11.5
0.020	16	6.5
0.060	2	13.8
0.060	4	7.2
0.060	8	3.8
0.060	16	2.2

The RTCP bandwidth needed for 60 ms frames, reporting every 16 frames (once per second), can be seen to drop to 2.2 kbps. This calculation can be repeated for other patterns of compound and reduced-size RTCP packets, feedback frequency, and frame duration, as needed. 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). Rerunning the calculations from with these packet sizes gives the results shown in . As can be seen, there is a significant increase in overhead due to the use of IPv6. RTCP Bandwidth Needed for VoIP Feedback (Compound Reports Only) Using 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

Repeating the calculations from using IPv6 gives the results shown in . 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. Required RTCP Bandwidth for VoIP Feedback (Alternating Compound and Reduced-Size Reports) Using IPv6

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

Scenario 2: Point-to-Point Video Conference 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), with all four flows being active for essentially all the time (the audio flows will likely use voice activity detection and comfort noise to reduce the packet rate during silent periods, but this does not cause the transmissions to stop). 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 SSRCs at each end point are aggregated , the optimizations in are used, and RTCP congestion control feedback is sent . As in , when all members are senders, the RTCP reporting interval calculation in Sections and and in reduces to: Trtcp = n * Srtcp / Brtcp where n is the number of members in the session, Srtcp is the average RTCP packet size in octets, and Brtcp is the RTCP bandwidth in octets per second. The average RTCP packet size (Srtcp) depends on the amount of feedback sent in each RTCP packet, the number of members in the session, the size of source description (RTCP SDES) information sent, and the amount of congestion control feedback sent in each packet. As a baseline, each RTCP packet will be a compound RTCP packet that contains an aggregate of a compound RTCP packet generated by the video SSRC and a compound RTCP packet generated by the audio SSRC. 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 its reports. No reduced-size RTCP packets are sent. The aggregated compound RTCP packet from the non-reporting SSRC will contain an RTCP SR packet, an RTCP SDES packet, and an RTCP Reporting Group Reporting Sources (RGRS) packet. The RTCP SR packet contains the 28-octet UDP/IP header (assuming IPv4 with no options) and sender information but no report blocks (since the reporting is delegated). The RTCP SDES packet will comprise a header (4 octets), the originating SSRC (4 octets), a CNAME chunk, a terminating chunk, and any padding. If the CNAME follows and , the CNAME chunk will be 18 octets in 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 (), making the SDES packet 28 octets in size. The RTCP 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 contain an RTCP SR packet, an RTCP SDES packet, and an RTCP congestion control feedback packet. 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 by the reporting group extension), 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 chunk, a Reporting Group (RGRP) chunk, a terminating chunk, and any padding. If the CNAME follows and , it will be 18 octets in size. The RGRP chunk similarly comprises 18 octets, the terminating 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-octet RTCP header and SSRC, a 4-octet report timestamp, and for each of the remote audio and video SSRCs, an 8-octet report header, 2 octets per packet 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 packets per report and Na is the number of audio packets per report. The complete compound RTCP packet contains the RTCP packets from both the reporting and non-reporting SSRCs, an SRTCP trailer and authentication tag, and a UDP/IPv4 header. The size of this RTCP packet is therefore 262 + (2 * Nv) + (2 * Na) octets. Since the aggregate RTCP packet contains reports from two SSRCs, the RTCP packet size is halved before use . Accordingly, the size of the RTCP packets is: Srtcp = (262 + (2 * Nv) + (2 * Na)) / 2 How many RTP packets does the RTCP XR congestion control feedback 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 interval (Trtcp), the video bit rate and frame rate (Rf), the audio bit rate and framing interval, and whether the receiver chooses to send congestion control feedback in each RTCP packet it sends. 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 include a congestion control feedback packet in each report. 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, assume that the audio takes negligible bandwidth and that the audio framing interval can be varied within reasonable bounds, so that an integral number of audio frames align with video frame boundaries. shows the resulting values of Nv and Na (the number of video and audio packets covered by each congestion control feedback report) for a range of data rates and video frame rates, assuming congestion control feedback is sent once per video frame. The table also shows the result of inverting the RTCP reporting interval calculation to find the corresponding RTCP bandwidth (Brtcp). The RTCP bandwidth is given in kbps and as a fraction of the data rate. It can be seen that, for example, with a data rate of 1024 kbps and a video sent at 30 frames per second, the RTCP congestion control feedback report sent for each video frame will include reports on 3 video packets and 2 audio packets. The RTCP bandwidth needed to sustain this reporting rate is 127.5 kbps (12% of the data rate). This assumes an audio framing interval of 16.67 ms, so that 2 audio packets are sent for each video frame. Required RTCP Bandwidth, Reporting on Every Frame

Data Rate (kbps)	Video Frame Rate: Rf	Video Packets per Report: Nv	Audio Packets per Report: Na	Required RTCP Bandwidth: Brtcp (kbps)
100	8	1	6	34.5 (34%)
200	16	1	3	67.5 (33%)
350	30	1	2	125.6 (35%)
700	30	2	2	126.6 (18%)
700	60	1	1	249.4 (35%)
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%)

Use of reduced-size RTCP would allow the SR and SDES packets to be omitted from some reports. These reduced-size RTCP packets would contain an RTCP RGRS packet from the non-reporting 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) + 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 be (110 + (2 * Nv) + (2 * Na)) / 2 octets. Repeating the analysis above, but alternating compound and reduced-size reports, gives the results shown in . Required RTCP Bandwidth, Reporting on Every Frame, with Reduced-Size Reports

Data Rate (kbps)	Video Frame Rate: Rf	Video Packets per Report: Nv	Audio Packets per Report: Na	Required RTCP Bandwidth: Brtcp (kbps)
100	8	1	6	25.0 (25%)
200	16	1	3	48.5 (24%)
350	30	1	2	90.0 (25%)
700	30	2	2	90.9 (12%)
700	60	1	1	178.1 (25%)
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%)

The use of reduced-size RTCP gives a noticeable reduction in the needed RTCP bandwidth and can be combined with reporting every few frames, rather than every frame. Overall, it is clear that the RTCP overhead can be reasonable across the range of data and frame rates if RTCP is configured carefully. As discussed in , the reporting overhead will increase if IPv6 is used, due to the increased size of the IPv6 header. shows the overhead in this case, compared to . As can be seen, the increase in overhead due to IPv6 rapidly becomes less significant as the data rate increases. Required RTCP Bandwidth, Reporting on Every Frame, with Reduced-Size Reports, Using IPv6

Data Rate (kbps)	Video Frame Rate: Rf	Video Packets per Report: Nv	Audio Packets per Report: Na	Required RTCP Bandwidth: 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%)

Discussion and Conclusions Practical systems will generally send some non-media traffic on the same path as the media traffic. This can include Session Traversal Utilities for NAT (STUN) / Traversal Using Relays around NAT (TURN) packets to keep alive NAT bindings , WebRTC data channel packets , etc. Such traffic also needs congestion control, but the means by which this is achieved is out of the scope of this memo. RTCP, as it is currently specified, cannot be used to send per-packet congestion feedback with reasonable overhead. RTCP can, however, be used to send congestion feedback on each frame of video sent, provided the session bandwidth exceeds a couple of megabits per second (the exact rate depends on the number of session participants, the RTCP bandwidth fraction, what RTCP extensions are enabled, and how much detail of feedback is needed). For lower-rate sessions, the overhead of reporting on every 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 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 for congestion feedback in WebRTC, the multimedia congestion control algorithm needs to be designed to work with feedback sent every few frames, since that fits within the limitations of RTCP. The provided feedback will be more detailed than just an acknowledgement, however, and will provide a loss bitmap, relative arrival time, and received Explicit Congestion Notification (ECN) marks for each packet sent. This will allow congestion control that is effective, if slowly responsive, to be implemented (there is guidance on providing effective congestion control in ). The format described in seems sufficient for the needs of congestion control feedback. There is little point optimizing this format; the main overhead comes from the UDP/IP headers and the other RTCP packets included in the compound packets and can be lowered by using the extensions described in and sending reports less frequently. The use of header compression can also be beneficial. Further study of the scenarios of interest is needed to ensure that the analysis presented is applicable to other media topologies and to sessions with different data rates and sizes of membership.

Security Considerations An attacker that can modify or spoof RTCP congestion control feedback packets can manipulate the sender behavior to cause denial of service. This can be prevented by authentication and integrity protection of RTCP packets, for example, using the secure RTP profile or other means as discussed in .

IANA Considerations This document has no IANA actions.

Normative References The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK] An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. [STANDARDS-TRACK] This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585. [STANDARDS-TRACK] The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism. The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms. The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. This memo expands and clarifies the behavior of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs). This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages. This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). The framework for Web Real-Time Communication (WebRTC) provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context and gives requirements for which RTP features, profiles, and extensions need to be supported. RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP Control Protocol (RTCP) reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control. Informative References This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. [STANDARDS-TRACK] This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender. The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link- layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self- clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a header compression scheme for point to point links with packet loss and long delays. It is based on Compressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays. [STANDARDS-TRACK] This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. This document specifies TCP Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best-effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as streaming media where a relatively smooth sending rate is of importance. This document obsoletes RFC 3448 and updates RFC 4342. [STANDARDS-TRACK] The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics. The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. [STANDARDS-TRACK] This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.

Acknowledgements Thanks to , , , , , , , , , , , and the members of the RMCAT feedback design team for their feedback.

Author's Address University of Glasgow

School of Computing Science Glasgow G12 8QQ United Kingdom csp@csperkins.org