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