idnits 2.17.1 draft-ietf-avtcore-cc-feedback-message-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2, 2020) is 1331 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-rmcat-rtp-cc-feedback-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF RMCAT Working Group Z. Sarker 3 Internet-Draft Ericsson AB 4 Intended status: Standards Track C. Perkins 5 Expires: March 6, 2021 University of Glasgow 6 V. Singh 7 callstats.io 8 M. Ramalho 9 September 2, 2020 11 RTP Control Protocol (RTCP) Feedback for Congestion Control 12 draft-ietf-avtcore-cc-feedback-message-08 14 Abstract 16 This document describes an RTCP feedback message intended to enable 17 congestion control for interactive real-time traffic using RTP. The 18 feedback message is designed for use with a sender-based congestion 19 control algorithm, in which the receiver of an RTP flow sends RTCP 20 feedback packets to the sender containing the information the sender 21 needs to perform congestion control. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 6, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 60 3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 61 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 62 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8 63 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9 65 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 71 12.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 For interactive real-time traffic, such as video conferencing flows, 77 the typical protocol choice is the Real-time Transport Protocol (RTP) 78 [RFC3550] running over the User Datagram Protocol (UDP). RTP does 79 not provide any guarantee of Quality of Service (QoS), reliability, 80 or timely delivery, and expects the underlying transport protocol to 81 do so. UDP alone certainly does not meet that expectation. However, 82 the RTP Control Protocol (RTCP) [RFC3550] provides a mechanism by 83 which the receiver of an RTP flow can periodically send transport and 84 media quality metrics to the sender of that RTP flow. This 85 information can be used by the sender to perform congestion control. 86 In the absence of standardized messages for this purpose, designers 87 of congestion control algorithms have developed proprietary RTCP 88 messages that convey only those parameters needed for their 89 respective designs. As a direct result, the different congestion 90 control designs are not interoperable. To enable algorithm evolution 91 as well as interoperability across designs (e.g., different rate 92 adaptation algorithms), it is highly desirable to have generic 93 congestion control feedback format. 95 To help achieve interoperability for unicast RTP congestion control, 96 this memo proposes a common RTCP feedback packet format that can be 97 used by NADA [RFC8698], SCReAM [RFC8298], Google Congestion Control 98 [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection [RFC8382], and 99 hopefully also by future RTP congestion control algorithms. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 In addition the terminology defined in [RFC3550], [RFC3551], 110 [RFC3611], [RFC4585], and [RFC5506] applies. 112 3. RTCP Feedback for Congestion Control 114 Based on an analysis of NADA [RFC8698], SCReAM [RFC8298], Google 115 Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck 116 Detection [RFC8382], the following per-RTP packet congestion control 117 feedback information has been determined to be necessary: 119 o RTP sequence number: The receiver of an RTP flow needs to feed the 120 sequence numbers of the received RTP packets back to the sender, 121 so the sender can determine which packets were received and which 122 were lost. Packet loss is used as an indication of congestion by 123 many congestion control algorithms. 125 o Packet Arrival Time: The receiver of an RTP flow needs to feed the 126 arrival time of each RTP packet back to the sender. Packet delay 127 and/or delay variation (jitter) is used as a congestion signal by 128 some congestion control algorithms. 130 o Packet Explicit Congestion Notification (ECN) Marking: If ECN 131 [RFC3168], [RFC6679] is used, it is necessary to feed back the 132 2-bit ECN mark in received RTP packets, indicating for each RTP 133 packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE. 134 If the path used by the RTP traffic is ECN capable the sender can 135 use Congestion Experienced (ECN-CE) marking information as a 136 congestion control signal. 138 Every RTP flow is identified by its Synchronization Source (SSRC) 139 identifier. Accordingly, the RTCP feedback format needs to group its 140 reports by SSRC, sending one report block per received SSRC. 142 As a practical matter, we note that host operating system (OS) 143 process interruptions can occur at inopportune times. Accordingly, 144 recording RTP packet send times at the sender, and the corresponding 145 RTP packet arrival times at the receiver, needs to be done with 146 deliberate care. This is because the time duration of host OS 147 interruptions can be significant relative to the precision desired in 148 the one-way delay estimates. Specifically, the send time needs to be 149 recorded at the last opportunity prior to transmitting the RTP packet 150 at the sender, and the arrival time at the receiver needs to be 151 recorded at the earliest available opportunity. 153 3.1. RTCP Congestion Control Feedback Report 155 Congestion control feedback can be sent as part of a regular 156 scheduled RTCP report, or in an RTP/AVPF early feedback packet. If 157 sent as early feedback, congestion control feedback MAY be sent in a 158 non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] 159 or the RTP/SAVPF profile [RFC5124] is used. 161 Irrespective of how it is transported, the congestion control 162 feedback is sent as a Transport Layer Feedback Message (RTCP packet 163 type 205). The format of this RTCP packet is shown in Figure 1: 165 0 1 2 3 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |V=2|P| FMT=CCFB | PT = 205 | length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | SSRC of RTCP packet sender | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | SSRC of 1st RTP Stream | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | begin_seq | num_reports | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |L|ECN| Arrival time offset | ... . 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 . . 179 . . 180 . . 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | SSRC of nth RTP Stream | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | begin_seq | num_reports | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |L|ECN| Arrival time offset | ... | 187 . . 188 . . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Report Timestamp (32bits) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: RTCP Congestion Control Feedback Packet Format 195 The first eight octets comprise a standard RTCP header, with PT=205 196 and FMT=CCFB indicating that this is a congestion control feedback 197 packet, and with the SSRC set to that of the sender of the RTCP 198 packet. (NOTE TO RFC EDITOR: please replace CCFB here and in the 199 above diagram with the IANA assigned RTCP feedback packet type, and 200 remove this note) 202 Section 6.1 of [RFC4585] requires the RTCP header to be followed by 203 the SSRC of the RTP flow being reported upon. Accordingly, the RTCP 204 header is followed by a report block for each SSRC from which RTP 205 packets have been received, followed by a Report Timestamp. 207 Each report block begins with the SSRC of the received RTP Stream on 208 which it is reporting. Following this, the report block contains a 209 16-bit packet metric block for each RTP packet with sequence number 210 in the range begin_seq to begin_seq+num_reports inclusive (calculated 211 using arithmetic modulo 65536 to account for possible sequence number 212 wrap-around). If the number of 16-bit packet metric blocks included 213 in the report block is not a multiple of two, then 16 bits of zero 214 padding MUST be added after the last packet metric block, to align 215 the end of the packet metric blocks with the next 32 bit boundary. 216 The value of num_reports MAY be zero, indicating that there are no 217 packet metric blocks included for that SSRC. Each report block MUST 218 NOT include more than 16384 packet metric blocks (i.e., it MUST NOT 219 report on more than one quarter of the sequence number space in a 220 single report). 222 The contents of each 16-bit packet metric block comprises the L, ECN, 223 and ATO fields as follows: 225 o L (1 bit): is a boolean to indicate if the packet was received. 0 226 represents that the packet was not yet received and all the 227 subsequent bits (ECN and ATO) are also set to 0. 1 represents 228 that the packet was received and the subsequent bits in the block 229 need to be parsed. 231 o ECN (2 bits): is the echoed ECN mark of the packet. These are set 232 to 00 if not received, or if ECN is not used. 234 o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP 235 packet at the receiver, as an offset before the time represented 236 by the Report Timestamp (RTS) field of this RTCP congestion 237 control feedback report. The ATO field is in units of 1/1024 238 seconds (this unit is chosen to give exact offsets from the RTS 239 field) so, for example, an ATO value of 512 indicates that the 240 corresponding RTP packet arrived exactly half a second before the 241 time instant represented by the RTS field. If the measured value 242 is greater than 8189/1024 seconds (the value that would be coded 243 as 0x1FFD), the value 0x1FFE MUST be reported to indicate an over- 244 range measurement. If the measurement is unavailable, or if the 245 arrival time of the RTP packet is after the time represented by 246 the RTS field, then an ATO value of 0x1FFF MUST be reported for 247 the packet. 249 The RTCP congestion control feedback report packet concludes with the 250 Report Timestamp field (RTS, 32 bits). This denotes the time instant 251 on which this packet is reporting, and is the instant from which the 252 arrival time offset values are calculated. The value of RTS field is 253 derived from the same clock used to generate the NTP timestamp field 254 in RTCP Sender Report (SR) packets. It is formatted as the middle 32 255 bits of an NTP format timestamp, as described in Section 4 of 256 [RFC3550]. 258 RTCP congestion control feedback packets SHOULD include a report 259 block for every active SSRC. The sequence number ranges reported on 260 in consecutive reports for a given SSRC will generally be contiguous, 261 but overlapping reports MAY be sent (and need to be sent in cases 262 where RTP packet reordering occurs across the boundary between 263 consecutive reports). If reports covering overlapping sequence 264 number ranges are sent, information in later reports updates that in 265 sent previous reports for RTP packets included in both reports. If 266 an RTP packet was reported as received in one report, that packet 267 MUST also be reported as received in any overlapping reports sent 268 later that cover its sequence number range. 270 RTCP congestion control feedback packets can be large if they are 271 sent infrequently relative to the number of RTP data packets. If an 272 RTCP congestion control feedback packet is too large to fit within 273 the path MTU, its sender SHOULD split it into multiple feedback 274 packets. The RTCP reporting interval SHOULD be chosen such that 275 feedback packets are sent often enough that they are small enough to 276 fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] discusses 277 how to choose the reporting interval; specifications for RTP 278 congestion control algorithms can also provide guidance). 280 If duplicate copies of a particular RTP packet are received, then the 281 arrival time of the first copy to arrive MUST be reported. If any of 282 the copies of the duplicated packet are ECN-CE marked, then an ECN-CE 283 mark MUST be reported that for packet; otherwise the ECN mark of the 284 first copy to arrive is reported. 286 If no packets are received from an SSRC in a reporting interval, a 287 report block MAY be sent with begin_seq set to the highest sequence 288 number previously received from that SSRC and num_reports set to zero 289 (or, the report can simply to omitted). The corresponding SR/RR 290 packet will have a non-increased extended highest sequence number 291 received field that will inform the sender that no packets have been 292 received, but it can ease processing to have that information 293 available in the congestion control feedback reports too. 295 A report block indicating that certain RTP packets were lost is not 296 to be interpreted as a request to retransmit the lost packets. The 297 receiver of such a report might choose to retransmit such packets, 298 provided a retransmission payload format has been negotiated, but 299 there is no requirement that it do so. 301 4. Feedback Frequency and Overhead 303 There is a trade-off between speed and accuracy of reporting, and the 304 overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses 305 this trade-off, suggests desirable RTCP feedback rates, and provides 306 guidance on how to configure the RTCP bandwidth fraction, etc., to 307 make appropriate use of the reporting block described in this memo. 309 Specifications for RTP congestion control algorithms can also provide 310 guidance. 312 It is generally understood that congestion control algorithms work 313 better with more frequent feedback. However, RTCP bandwidth and 314 transmission rules put some upper limits on how frequently the RTCP 315 feedback messages can be sent from an RTP receiver to the RTP sender. 316 In many cases, sending feedback once per frame is an upper bound 317 before the reporting overhead becomes excessive, although this will 318 depend on the media rate and more frequent feedback might be needed 319 with high-rate media flows [I-D.ietf-rmcat-rtp-cc-feedback]. 320 Analysis [feedback-requirements] has also shown that some candidate 321 congestion control algorithms can operate with less frequent 322 feedback, using a feedback interval range of 50-200ms. Applications 323 need to negotiate an appropriate congestion control feedback interval 324 at session setup time, based on the choice of congestion control 325 algorithm, the expected media bit rate, and the acceptable feedback 326 overhead. 328 5. Response to Loss of Feedback Packets 330 Like all RTCP packets, RTCP congestion control feedback packets might 331 be lost. All RTP congestion control algorithms MUST specify how they 332 respond to the loss of feedback packets. 334 If only a single congestion control feedback packet is lost, an 335 appropriate response is to assume that the level of congestion has 336 remained roughly the same as the previous report. However, if 337 multiple consecutive congestion control feedback packets are lost, 338 then the sender SHOULD rapidly reduce its sending rate as this likely 339 indicates a path failure. The RTP circuit breaker [RFC8083] provides 340 further guidance. 342 6. SDP Signalling 344 A new "ack" feedback parameter, "ccfb", is defined for use with the 345 "a=rtcp-fb:" SDP extension to indicate the use of the RTP Congestion 346 Control feedback packet format defined in Section 3. The ABNF 347 definition of this SDP parameter extension is: 349 rtcp-fb-ack-param = 350 rtcp-fb-ack-param =/ ccfb-par 351 ccfb-par = SP "ccfb" 353 The payload type used with "ccfb" feedback MUST be the wildcard type 354 ("*"). This implies that the congestion control feedback is sent for 355 all payload types in use in the session, including any FEC and 356 retransmission payload types. An example of the resulting SDP 357 attribute is: 359 a=rtcp-fb:* ack ccfb 361 The offer/answer rules for these SDP feedback parameters are 362 specified in Section 4.2 of the RTP/AVPF profile [RFC4585]. 364 An SDP offer might indicate support for both the congestion control 365 feedback mechanism specified in this memo and one or more alternative 366 congestion control feedback mechanisms that offer substantially the 367 same semantics. In this case, the answering party SHOULD include 368 only one of the offered congestion control feedback mechanisms in its 369 answer. If a re-invite offering the same set of congestion control 370 feedback mechanisms is received, the generated answer SHOULD choose 371 the same congestion control feedback mechanism as in the original 372 answer where possible. 374 When the SDP BUNDLE extension 375 [I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing, 376 the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT 377 [I-D.ietf-mmusic-sdp-mux-attributes]. 379 7. Relation to RFC 6679 381 Use of Explicit Congestion Notification (ECN) with RTP is described 382 in [RFC6679]. That specifies how to negotiate the use of ECN with 383 RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback 384 reports. It uses an SDP "a=ecn-capaable-rtp:" attribute to negotiate 385 use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter 386 "ecn" to negotiate the use of RTCP ECN Feedback Packets. 388 The RTCP ECN Feedback Packet is not useful when ECN is used with the 389 RTP Congestion Control Feedback Packet defined in this memo since it 390 provides duplicate information. Accordingly, when congestion control 391 feedback is to be used with RTP and ECN, the SDP offer generated MUST 392 include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, 393 along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" 394 to indicate that the RTP Congestion Control Feedback Packet is to be 395 used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the 396 "nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be 397 used. 399 8. Design Rationale 401 The primary function of RTCP SR/RR packets is to report statistics on 402 the reception of RTP packets. The reception report blocks sent in 403 these packets contain information about observed jitter, fractional 404 packet loss, and cumulative packet loss. It was intended that this 405 information could be used to support congestion control algorithms, 406 but experience has shown that it is not sufficient for that purpose. 407 An efficient congestion control algorithm requires more fine-grained 408 information on per-packet reception quality than is provided by SR/RR 409 packets to react effectively. The feedback format defined in this 410 memo provides such fine-grained feedback. 412 Several other RTCP extensions also provide more detailed feedback 413 than SR/RR packets: 415 TMMBR: The Codec Control Messages for the RTP/AVPF profile [RFC5104] 416 include a Temporary Maximum Media Bit Rate (TMMBR) message. This 417 is used to convey a temporary maximum bit rate limitation from a 418 receiver of RTP packets to their sender. Even though it was not 419 designed to replace congestion control, TMMBR has been used as a 420 means to do receiver based congestion control where the session 421 bandwidth is high enough to send frequent TMMBR messages, 422 especially when used with non-compound RTCP packets [RFC5506]. 423 This approach requires the receiver of the RTP packets to monitor 424 their reception, determine the level of congestion, and recommend 425 a maximum bit rate suitable for current available bandwidth on the 426 path; it also assumes that the RTP sender can/will respect that 427 bit rate. This is the opposite of the sender-based congestion 428 control approach suggested in this memo, so TMMBR cannot be used 429 to convey the information needed for a sender-based congestion 430 control. TMMBR could, however, be viewed a complementary 431 mechanism that can inform the sender of the receiver's current 432 view of acceptable maximum bit rate. The Received Estimated 433 Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb] 434 provides similar feedback. 436 RTCP Extended Reports (XR): Numerous RTCP extended report (XR) 437 blocks have been defined to report details of packet loss, arrival 438 times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It 439 is possible to combine several such XR blocks into a compound RTCP 440 packet, to report the detailed loss, arrival time, and ECN marking 441 marking information needed for effective sender-based congestion 442 control. However, the result has high overhead both in terms of 443 bandwidth and complexity, due to the need to stack multiple 444 reports. 446 Transport-wide Congestion Control: The format defined in this memo 447 provides individual feedback on each SSRC. An alternative is to 448 add a header extension to each RTP packet, containing a single, 449 transport-wide, packet sequence number, then have the receiver 450 send RTCP reports giving feedback on these additional sequence 451 numbers [I-D.holmer-rmcat-transport-wide-cc-extensions]. Such an 452 approach adds the per-packet overhead of the header extension (8 453 octets per packet in the referenced format), but reduces the size 454 of the feedback packets, and can simplify the rate calculation at 455 the sender if it maintains a single rate limit that applies to all 456 RTP packets sent irrespective of their SSRC. Equally, the use of 457 transport-wide feedback makes it more difficult to adapt the 458 sending rate, or respond to lost packets, based on the reception 459 and/or loss patterns observed on a per-SSRC basis (for example, to 460 perform differential rate control and repair for audio and video 461 flows, based on knowledge of what packets from each flow were 462 lost). Transport-wide feedback is also a less natural fit with 463 the wider RTP framework, which makes extensive use of per-SSRC 464 sequence numbers and feedback. 466 Considering these issues, we believe it appropriate to design a new 467 RTCP feedback mechanism to convey information for sender-based 468 congestion control algorithms. The new congestion control feedback 469 RTCP packet described in Section 3 provides such a mechanism. 471 9. Acknowledgements 473 This document is based on the outcome of a design team discussion in 474 the RTP Media Congestion Avoidance Techniques (RMCAT) working group. 475 The authors would like to thank David Hayes, Stefan Holmer, Randell 476 Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils 477 Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable 478 feedback. 480 10. IANA Considerations 482 The IANA is requested to register one new RTP/AVPF Transport-Layer 483 Feedback Message in the table for FMT values for RTPFB Payload Types 484 [RFC4585] as defined in Section 3.1: 486 Name: CCFB 487 Long name: RTP Congestion Control Feedback 488 Value: (to be assigned by IANA) 489 Reference: (RFC number of this document, when published) 491 The IANA is also requested to register one new SDP "rtcp-fb" 492 attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" 493 Attribute Values) registry: 495 Value name: ccfb 496 Long name: Congestion Control Feedback 497 Usable with: ack 498 Reference: (RFC number of this document, when published) 500 11. Security Considerations 502 The security considerations of the RTP specification [RFC3550], the 503 applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), 504 and the RTP congestion control algorithm that is in use (e.g., 505 [RFC8698], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) apply. 507 A receiver that intentionally generates inaccurate RTCP congestion 508 control feedback reports might be able trick the sender into sending 509 at a greater rate than the path can support, thereby causing 510 congestion on the path. This will negatively impact the quality of 511 experience of that receiver. Since RTP is an unreliable transport, a 512 sender can intentionally leave a gap in the RTP sequence number space 513 without causing harm, to check that the receiver is correctly 514 reporting losses. 516 An on-path attacker that can modify RTCP congestion control feedback 517 packets can change the reports to trick the sender into sending at 518 either an excessively high or excessively low rate, leading to denial 519 of service. The secure RTCP profile [RFC3711] can be used to 520 authenticate RTCP packets to protect against this attack. 522 12. References 524 12.1. Normative References 526 [I-D.ietf-mmusic-sdp-bundle-negotiation] 527 Holmberg, C., Alvestrand, H., and C. Jennings, 528 "Negotiating Media Multiplexing Using the Session 529 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 530 negotiation-54 (work in progress), December 2018. 532 [I-D.ietf-mmusic-sdp-mux-attributes] 533 Nandakumar, S., "A Framework for SDP Attributes when 534 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-19 535 (work in progress), August 2020. 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 543 of Explicit Congestion Notification (ECN) to IP", 544 RFC 3168, DOI 10.17487/RFC3168, September 2001, 545 . 547 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 548 Jacobson, "RTP: A Transport Protocol for Real-Time 549 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 550 July 2003, . 552 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 553 Video Conferences with Minimal Control", STD 65, RFC 3551, 554 DOI 10.17487/RFC3551, July 2003, 555 . 557 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 558 "RTP Control Protocol Extended Reports (RTCP XR)", 559 RFC 3611, DOI 10.17487/RFC3611, November 2003, 560 . 562 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 563 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 564 RFC 3711, DOI 10.17487/RFC3711, March 2004, 565 . 567 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 568 "Extended RTP Profile for Real-time Transport Control 569 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 570 DOI 10.17487/RFC4585, July 2006, 571 . 573 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 574 Real-time Transport Control Protocol (RTCP)-Based Feedback 575 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 576 2008, . 578 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 579 Real-Time Transport Control Protocol (RTCP): Opportunities 580 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 581 2009, . 583 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 584 and K. Carlberg, "Explicit Congestion Notification (ECN) 585 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 586 2012, . 588 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 589 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 590 DOI 10.17487/RFC8083, March 2017, 591 . 593 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 594 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 595 May 2017, . 597 12.2. Informative References 599 [feedback-requirements] 600 "RMCAT Feedback Requirements", 601 <://www.ietf.org/proceedings/95/slides/slides-95-rmcat- 602 1.pdf>. 604 [I-D.alvestrand-rmcat-remb] 605 Alvestrand, H., "RTCP message for Receiver Estimated 606 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 607 progress), October 2013. 609 [I-D.holmer-rmcat-transport-wide-cc-extensions] 610 Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions 611 for Transport-wide Congestion Control", draft-holmer- 612 rmcat-transport-wide-cc-extensions-01 (work in progress), 613 October 2015. 615 [I-D.ietf-rmcat-gcc] 616 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 617 Mascolo, "A Google Congestion Control Algorithm for Real- 618 Time Communication", draft-ietf-rmcat-gcc-02 (work in 619 progress), July 2016. 621 [I-D.ietf-rmcat-rtp-cc-feedback] 622 Perkins, C., "RTP Control Protocol (RTCP) Feedback for 623 Congestion Control in Interactive Multimedia Conferences", 624 draft-ietf-rmcat-rtp-cc-feedback-05 (work in progress), 625 November 2019. 627 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 628 "Codec Control Messages in the RTP Audio-Visual Profile 629 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 630 February 2008, . 632 [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol 633 (RTCP) Extended Report (XR) Block for Delay Metric 634 Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, 635 . 637 [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 638 for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 639 2017, . 641 [RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, 642 "Shared Bottleneck Detection for Coupled Congestion 643 Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, 644 June 2018, . 646 [RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network- 647 Assisted Dynamic Adaptation (NADA): A Unified Congestion 648 Control Scheme for Real-Time Media", RFC 8698, 649 DOI 10.17487/RFC8698, February 2020, 650 . 652 Authors' Addresses 654 Zaheduzzaman Sarker 655 Ericsson AB 656 Torshamnsgatan 21 657 Stockholm 164 40 658 Sweden 660 Phone: +46107173743 661 Email: zaheduzzaman.sarker@ericsson.com 663 Colin Perkins 664 University of Glasgow 665 School of Computing Science 666 Glasgow G12 8QQ 667 United Kingdom 669 Email: csp@csperkins.org 671 Varun Singh 672 CALLSTATS I/O Oy 673 Annankatu 31-33 C 42 674 Helsinki 00100 675 Finland 677 Email: varun.singh@iki.fi 678 URI: http://www.callstats.io/ 679 Michael A. Ramalho 680 6310 Watercrest Way Unit 203 681 Lakewood Ranch, FL 34202-5122 682 USA 684 Phone: +1 732 832 9723 685 Email: mar42@cornell.edu 686 URI: http://ramalho.webhop.info/