idnits 2.17.1 draft-ietf-avtcore-cc-feedback-message-05.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 4, 2019) is 1634 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 (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-17 == Outdated reference: A later version (-12) exists of draft-ietf-rmcat-rtp-cc-feedback-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rmcat-rtp-cc-feedback (ref. 'I-D.ietf-rmcat-rtp-cc-feedback') Summary: 1 error (**), 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 7, 2020 University of Glasgow 6 V. Singh 7 callstats.io 8 M. Ramalho 9 November 4, 2019 11 RTP Control Protocol (RTCP) Feedback for Congestion Control 12 draft-ietf-avtcore-cc-feedback-message-05 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 May 7, 2020. 40 Copyright Notice 42 Copyright (c) 2019 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 . . . . . . . . . . . . 7 63 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 8 65 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 12.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 running over the User Datagram Protocol (UDP). RTP does not provide 79 any guarantee of Quality of Service (QoS), reliability, or timely 80 delivery, and expects the underlying transport protocol to do so. 81 UDP alone certainly does not meet that expectation. However, the RTP 82 Control Protocol (RTCP) provides a mechanism by which the receiver of 83 an RTP flow can periodically send transport and media quality metrics 84 to the sender of that RTP flow. This information can be used by the 85 sender to perform congestion control. In the absence of standardized 86 messages for this purpose, designers of congestion control algorithms 87 have developed proprietary RTCP messages that convey only those 88 parameters needed for their respective designs. As a direct result, 89 the different congestion control (i.e., rate adaptation) designs are 90 not interoperable. To enable algorithm evolution as well as 91 interoperability across designs (e.g., different rate adaptation 92 algorithms), it is highly desirable to have generic congestion 93 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 [I-D.ietf-rmcat-nada], SCReAM [RFC8298], Google 98 Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck 99 Detection [RFC8382], and hopefully also by future RTP congestion 100 control algorithms. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 In addition the terminology defined in [RFC3550], [RFC3551], 109 [RFC3611], [RFC4585], and [RFC5506] applies. 111 3. RTCP Feedback for Congestion Control 113 Based on an analysis of NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], 114 Google Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck 115 Detection [RFC8382], the following per-RTP packet congestion control 116 feedback information has been determined to be necessary: 118 o RTP sequence number: The receiver of an RTP flow needs to feedback 119 the sequence numbers of the received RTP packets to the sender, so 120 the sender can determine which packets were received and which 121 were lost. Packet loss is used as an indication of congestion by 122 many congestion control algorithms. 124 o Packet Arrival Time: The receiver of an RTP flow needs to feedback 125 the arrival time of each RTP packet to the sender. Packet delay 126 and/or delay variation (jitter) is used as a congestion signal by 127 some congestion control algorithms. 129 o Packet Explicit Congestion Notification (ECN) Marking: If ECN 130 [RFC3168], [RFC6679] is used, it is necessary to feedback the 131 2-bit ECN mark in received RTP packets, indicating for each RTP 132 packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE. 133 If the path used by the RTP traffic is ECN capable the sender can 134 use Congestion Experienced (ECN-CE) marking information as a 135 congestion control signal. 137 Every RTP flow is identified by its Synchronization Source (SSRC) 138 identifier. Accordingly, the RTCP feedback format needs to group its 139 reports by SSRC, sending one report block per received SSRC. 141 As a practical matter, we note that host operating system (OS) 142 process interruptions can occur at inopportune times. Accordingly, 143 recording RTP packet send times at the sender, and the corresponding 144 RTP packet arrival times at the receiver, needs to be done with 145 deliberate care. This is because the time duration of host OS 146 interruptions can be significant relative to the precision desired in 147 the one-way delay estimates. Specifically, the send time needs to be 148 recorded at the last opportunity prior to transmitting the RTP packet 149 at the sender, and the arrival time at the receiver needs to be 150 recorded at the earliest available opportunity. 152 3.1. RTCP Congestion Control Feedback Report 154 Congestion control feedback can be sent as part of a regular 155 scheduled RTCP report, or in an RTP/AVPF early feedback packet. If 156 sent as early feedback, congestion control feedback MAY be sent in a 157 non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] 158 or the RTP/SAVPF profile [RFC5124] is used. 160 Irrespective of how it is transported, the congestion control 161 feedback is sent as a Transport Layer Feedback Message (RTCP packet 162 type 205). The format of this RTCP packet is shown in Figure 1: 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |V=2|P| FMT=CCFB | PT = 205 | length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | SSRC of RTCP packet sender | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | SSRC of 1st RTP Stream | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | begin_seq | num_reports | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |L|ECN| Arrival time offset | ... . 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 . . 178 . . 179 . . 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | SSRC of nth RTP Stream | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | begin_seq | num_reports | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |L|ECN| Arrival time offset | ... | 186 . . 187 . . 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Report Timestamp (32bits) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: RTCP Congestion Control Feedback Packet Format 194 The first eight octets comprise a standard RTCP header, with PT=205 195 and FMT=CCFB indicating that this is a congestion control feedback 196 packet, and with the SSRC set to that of the sender of the RTCP 197 packet. (NOTE TO RFC EDITOR: please replace CCFB here and in the 198 above diagram with the IANA assigned RTCP feedback packet type, and 199 remove this note) 201 Section 6.1 of [RFC4585] requires the RTCP header to be followed by 202 the SSRC of the RTP flow being reported upon. Accordingly, the RTCP 203 header is followed by a report block for each SSRC from which RTP 204 packets have been received, followed by a Report Timestamp. 206 Each report block begins with the SSRC of the received RTP Stream on 207 which it is reporting. Following this, the report block contains a 208 16-bit packet metric block for each RTP packet with sequence number 209 in the range begin_seq to begin_seq+num_reports inclusive (calculated 210 using arithmetic modulo 65536 to account for possible sequence number 211 wrap-around). If the number of 16-bit packet metric blocks included 212 in the report block is not a multiple of two, then 16 bits of zero 213 padding MUST be added after the last packet metric block, to align 214 the end of the packet metric blocks with the next 32 bit boundary. 215 The value of num_reports MAY be zero, indicating that there are no 216 packet metric blocks included for that SSRC. Each report block MUST 217 NOT include more than 16384 packet metric blocks (i.e., it MUST NOT 218 report on more than one quarter of the sequence number space in a 219 single report). 221 The contents of each 16-bit packet metric block comprises the L, ECN, 222 and ATO fields are as follows: 224 o L (1 bit): is a boolean to indicate if the packet was received. 0 225 represents that the packet was not yet received and all the 226 subsequent bits (ECN and ATO) are also set to 0. 1 represent the 227 packet was received and the subsequent bits in the block need to 228 be parsed. 230 o ECN (2 bits): is the echoed ECN mark of the packet. These are set 231 to 00 if not received, or if ECN is not used. 233 o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP 234 packet at the receiver, as an offset before the time represented 235 by the RTS field of this RTCP congestion control feedback report. 236 The ATO field is in units of 1/1024 seconds (this unit is chosen 237 to give exact offsets from the RTS field) so, for example, an ATO 238 value of 512 indicates that the corresponding RTP packet arrived 239 exactly half a second before the time instant represented by the 240 RTS field. If the measured value is greater than 8189/1024 241 seconds (the value that would be coded as 0x1FFD), the value 242 0x1FFE MUST be reported to indicate an over-range measurement. If 243 the measurement is unavailable, or if the arrival time of the RTP 244 packet is after the time represented by the RTS field, then an ATO 245 value of 0x1FFF MUST be reported for the packet. 247 The RTCP congestion control feedback report packet concludes with the 248 Report Timestamp field (RTS, 32 bits). This denotes the time instant 249 on which this packet is reporting, and is the instant from which the 250 arrival time offset values are calculated. The value of RTS field is 251 derived from the same clock used to generate the NTP timestamp field 252 in RTCP Sender Report (SR) packets. It is formatted as the middle 32 253 bits of an NTP format timestamp, as described in Section 4 of 254 [RFC3550]. 256 RTCP congestion control feedback packets SHOULD include a report 257 block for every active SSRC. The sequence number ranges reported on 258 in consecutive reports for a given SSRC will generally be contiguous, 259 but overlapping reports MAY be sent (and need to be sent in cases 260 where RTP packet reordering occurs across the boundary between 261 consecutive reports). If reports covering overlapping sequence 262 number ranges are sent, information in later reports updates that in 263 sent previous reports for RTP packets included in both reports. If 264 an RTP packet was reported as received in one report, that packet 265 MUST also be reported as received in any overlapping reports sent 266 later that cover its sequence number range. 268 RTCP congestion control feedback packets can be large if they are 269 sent infrequently relative to the number of RTP data packets. If an 270 RTCP congestion control feedback packet is too large to fit within 271 the path MTU, its sender SHOULD split it into multiple feedback 272 packets. The RTCP reporting interval SHOULD be chosen such that 273 feedback packets are sent often enough that they are small enough to 274 fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] provides 275 guidance on how to choose the reporting interval). 277 If duplicate copies of a particular RTP packet are received, then the 278 arrival time of the first copy to arrive MUST be reported. If any of 279 the copies of the duplicated packet are ECN-CE marked, then an ECN-CE 280 mark MUST be reported that for packet; otherwise the ECN mark of the 281 first copy to arrive is reported. 283 If no packets are received from an SSRC in a reporting interval, a 284 report block MAY be sent with begin_seq set to the highest sequence 285 number previously received from that SSRC and num_reports set to zero 286 (or, the report can simply to omitted). The corresponding SR/RR 287 packet will have a non-increased extended highest sequence number 288 received field that will inform the sender that no packets have been 289 received, but it can ease processing to have that information 290 available in the congestion control feedback reports too. 292 A report block indicating that certain RTP packets were lost is not 293 to be interpreted as a request to retransmit the lost packets. The 294 receiver of such a report might choose to retransmit such packets, 295 provided a retransmission payload format has been negotiated, but 296 there is no requirement that it do so. 298 4. Feedback Frequency and Overhead 300 There is a trade-off between speed and accuracy of reporting, and the 301 overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses 302 this trade-off, suggests desirable RTCP feedback rates, and provides 303 guidance on how to configure the RTCP bandwidth fraction, etc., to 304 make appropriate use of the reporting block described in this memo. 305 Specifications for RTP congestion control algorithms can also provide 306 guidance. 308 It is a general understanding that the congestion control algorithms 309 will work better with more frequent feedback - per packet feedback. 310 However, RTCP bandwidth and transmission rules put some upper limits 311 on how frequently the RTCP feedback messages can be send from the RTP 312 receiver to the RTP sender. It has been shown 313 [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame 314 feedback is a reasonable assumption on how frequent the RTCP feedback 315 messages can be transmitted. It has also been noted that even if a 316 higher frequency of feedback is desired it is not viable if the 317 feedback messages starts to compete against the RTP traffic on the 318 feedback path during congestion period. Analyzing the feedback 319 interval requirement [feedback-requirements] it can be seen that the 320 candidate algorithms can perform with a feedback interval range of 321 50-200ms. A value within this range need to be negotiated at session 322 setup. 324 5. Response to Loss of Feedback Packets 326 Like all RTCP packets, RTCP congestion control feedback packets might 327 be lost. All RTP congestion control algorithms MUST specify how they 328 respond to the loss of feedback packets. 330 If only a single congestion control feedback packet is lost, an 331 appropriate response is to assume that the level of congestion has 332 remained roughly the same as the previous report. However, if 333 multiple consecutive congestion control feedback packets are lost, 334 the sender SHOULD rapidly reduce its sending rate towards zero, as 335 this likely indicates a path failure. The RTP circuit breaker 336 [RFC8083] provides further guidance. 338 6. SDP Signalling 340 A new "ack" feedback parameter, "ccfb", is defined for use with the 341 "a=rtcp-fb:" SDP extension to indicate the use of the RTP Congestion 342 Control feedback packet format defined in Section 3. The ABNF 343 definition of this SDP parameter extension is: 345 rtcp-fb-ack-param = 346 rtcp-fb-ack-param =/ ccfb-par 347 ccfb-par = SP "ccfb" 349 When used with "ccfb" feedback, the wildcard payload type ("*") MUST 350 be used. This implies that the congestion control feedback is sent 351 for all payload types in use in the session, including any FEC and 352 retransmission payload types. An example of the resulting SDP 353 attribute is: 355 a=rtcp-fb:* ack ccfb 357 The offer/answer rules for these SDP feedback parameters are 358 specified in Section 4.2 of the RTP/AVPF profile [RFC4585]. 360 An SDP offer might indicate support for both the congestion control 361 feedback mechanism specified in this memo and one or more alternative 362 congestion control feedback mechanisms that offer substantially the 363 same semantics. In this case, the answering party SHOULD include 364 only one of the offered congestion control feedback mechanisms in its 365 answer. If a re-invite offering the same set of congestion control 366 feedback mechanisms is received, the generated answer SHOULD choose 367 the same congestion control feedback mechanism as in the original 368 answer where possible. 370 When the SDP BUNDLE extension 371 [I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing, 372 the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT 373 [I-D.ietf-mmusic-sdp-mux-attributes]. 375 7. Relation to RFC 6679 377 Use of Explicit Congestion Notification (ECN) with RTP is described 378 in [RFC6679]. That specifies how to negotiate the use of ECN with 379 RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback 380 reports. It uses an SDP "a=ecn-capaable-rtp:" attribute to negotiate 381 use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter 382 "ecn" to negotiate the use of RTCP ECN Feedback Packets. 384 The RTCP ECN Feedback Packet is not useful when ECN is used with the 385 RTP Congestion Control Feedback Packet defined in this memo since it 386 provides duplicate information. Accordingly, when congestion control 387 feedback is to be used with RTP and ECN, the SDP offer generated MUST 388 include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, 389 along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" 390 to indicate that the RTP Congestion Control Feedback Packet is to be 391 used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the 392 "nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be 393 used. 395 8. Design Rationale 397 The primary function of RTCP SR/RR packets is to report statistics on 398 the reception of RTP packets. The reception report blocks sent in 399 these packets contain information about observed jitter, fractional 400 packet loss, and cumulative packet loss. It was intended that this 401 information could be used to support congestion control algorithms, 402 but experience has shown that it is not sufficient for that purpose. 403 An efficient congestion control algorithm requires more fine grained 404 information on per packet reception quality than is provided by SR/RR 405 packets to react effectively. The feedback format defined in this 406 memo provides such fine grained feedback. 408 Several other RTCP extensions also provide more detailed feedback 409 than SR/RR packets: 411 TMMBR: The Codec Control Messages for the RTP/AVPF profile [RFC5104] 412 include a Temporary Maximum Media Bit Rate (TMMBR) message. This 413 is used to convey a temporary maximum bit rate limitation from a 414 receiver of RTP packets to their sender. Even though it was not 415 designed to replace congestion control, TMMBR has been used as a 416 means to do receiver based congestion control where the session 417 bandwidth is high enough to send frequent TMMBR messages, 418 especially when used with non-compound RTCP packets [RFC5506]. 419 This approach requires the receiver of the RTP packets to monitor 420 their reception, determine the level of congestion, and recommend 421 a maximum bit rate suitable for current available bandwidth on the 422 path; it also assumes that the RTP sender can/will respect that 423 bit rate. This is the opposite of the sender based congestion 424 control approach suggested in this memo, so TMMBR cannot be used 425 to convey the information needed for a sender based congestion 426 control. TMMBR could, however, be viewed a complementary 427 mechanism that can inform the sender of the receiver's current 428 view of acceptable maximum bit rate. The Received Estimated 429 Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb] 430 provides similar feedback. 432 RTCP Extended Reports (XR): Numerous RTCP extended report (XR) 433 blocks have been defined to report details of packet loss, arrival 434 times [RFC3611], delay [RFC6843], and ECN marking [RFC6679]. It 435 is possible to combine several such XR blocks into a compound RTCP 436 packet, to report the detailed loss, arrival time, and ECN marking 437 marking information needed for effective sender-based congestion 438 control. However, the result has high overhead both in terms of 439 bandwidth and complexity, due to the need to stack multiple 440 reports. 442 Transport-wide Congestion Control: The format defined in this memo 443 provides individual feedback on each SSRC. An alternative is to 444 add a header extension to each RTP packet, containing a single, 445 transport-wide, packet sequence number, then have the receiver 446 send RTCP reports giving feedback on these additional sequence 447 numbers [I-D.holmer-rmcat-transport-wide-cc-extensions]. Such an 448 approach adds the per-packet overhead of the header extension (8 449 octets per packet in the referenced format), but reduces the size 450 of the feedback packets, and can simplify the rate calculation at 451 the sender if it maintains a single rate limit that applies to all 452 RTP packets sent irrespective of their SSRC. Equally, the use of 453 transport-wide feedback makes it more difficult to adapt the 454 sending rate, or respond to lost packets, based on the reception 455 and/or loss patterns observed on a per-SSRC basis (for example, to 456 perform differential rate control and repair for audio and video 457 flows, based on knowledge of what packets from each flow were 458 lost). Transport-wide feedback is also a less natural fit with 459 the wider RTP framework, which makes extensive use of per-SSRC 460 sequence numbers and feedback. 462 Considering these issues, we believe it appropriate to design a new 463 RTCP feedback mechanism to convey information for sender based 464 congestion control algorithms. The new congestion control feedback 465 RTCP packet described in Section 3 provides such a mechanism. 467 9. Acknowledgements 469 This document is based on the outcome of a design team discussion in 470 the RTP Media Congestion Avoidance Techniques (RMCAT) working group. 471 The authors would like to thank David Hayes, Stefan Holmer, Randell 472 Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils 473 Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable 474 feedback. 476 10. IANA Considerations 478 The IANA is requested to register one new RTP/AVPF Transport-Layer 479 Feedback Message in the table for FMT values for RTPFB Payload Types 480 [RFC4585] as defined in Section 3.1: 482 Name: CCFB 483 Long name: RTP Congestion Control Feedback 484 Value: (to be assigned by IANA) 485 Reference: (RFC number of this document, when published) 487 The IANA is also requested to register one new SDP "rtcp-fb" 488 attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" 489 Attribute Values) registry: 491 Value name: ccfb 492 Long name: Congestion Control Feedback 493 Usable with: ack 494 Reference: (RFC number of this document, when published) 496 11. Security Considerations 498 The security considerations of the RTP specification [RFC3550], the 499 applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), 500 and the RTP congestion control algorithm that is in use (e.g., 501 [I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) 502 apply. 504 A receiver that intentionally generates inaccurate RTCP congestion 505 control feedback reports might be able trick the sender into sending 506 at a greater rate than the path can support, thereby congesting the 507 path. This will negatively impact the quality of experience of that 508 receiver. Since RTP is an unreliable transport, a sender can 509 intentionally leave a gap in the RTP sequence number space without 510 causing harm, to check that the receiver is correctly reporting 511 losses. 513 An on-path attacker that can modify RTCP congestion control feedback 514 packets can change the reports to trick the sender into sending at 515 either an excessively high or excessively low rate, leading to denial 516 of service. The secure RTCP profile [RFC3711] can be used to 517 authenticate RTCP packets to protect against this attack. 519 12. References 521 12.1. Normative References 523 [I-D.ietf-mmusic-sdp-bundle-negotiation] 524 Holmberg, C., Alvestrand, H., and C. Jennings, 525 "Negotiating Media Multiplexing Using the Session 526 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 527 negotiation-54 (work in progress), December 2018. 529 [I-D.ietf-mmusic-sdp-mux-attributes] 530 Nandakumar, S., "A Framework for SDP Attributes when 531 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 532 (work in progress), February 2018. 534 [I-D.ietf-rmcat-rtp-cc-feedback] 535 Perkins, C., "RTP Control Protocol (RTCP) Feedback for 536 Congestion Control in Interactive Multimedia Conferences", 537 draft-ietf-rmcat-rtp-cc-feedback-04 (work in progress), 538 July 2018. 540 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 541 Requirement Levels", BCP 14, RFC 2119, 542 DOI 10.17487/RFC2119, March 1997, 543 . 545 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 546 of Explicit Congestion Notification (ECN) to IP", 547 RFC 3168, DOI 10.17487/RFC3168, September 2001, 548 . 550 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 551 Jacobson, "RTP: A Transport Protocol for Real-Time 552 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 553 July 2003, . 555 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 556 Video Conferences with Minimal Control", STD 65, RFC 3551, 557 DOI 10.17487/RFC3551, July 2003, 558 . 560 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 561 "RTP Control Protocol Extended Reports (RTCP XR)", 562 RFC 3611, DOI 10.17487/RFC3611, November 2003, 563 . 565 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 566 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 567 RFC 3711, DOI 10.17487/RFC3711, March 2004, 568 . 570 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 571 "Extended RTP Profile for Real-time Transport Control 572 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 573 DOI 10.17487/RFC4585, July 2006, 574 . 576 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 577 Real-time Transport Control Protocol (RTCP)-Based Feedback 578 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 579 2008, . 581 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 582 Real-Time Transport Control Protocol (RTCP): Opportunities 583 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 584 2009, . 586 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 587 and K. Carlberg, "Explicit Congestion Notification (ECN) 588 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 589 2012, . 591 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 592 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 593 DOI 10.17487/RFC8083, March 2017, 594 . 596 12.2. Informative References 598 [feedback-requirements] 599 "RMCAT Feedback Requirements", 600 <://www.ietf.org/proceedings/95/slides/slides-95-rmcat- 601 1.pdf>. 603 [I-D.alvestrand-rmcat-remb] 604 Alvestrand, H., "RTCP message for Receiver Estimated 605 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 606 progress), October 2013. 608 [I-D.holmer-rmcat-transport-wide-cc-extensions] 609 Holmer, S., Flodman, M., and E. Sprang, "RTP Extensions 610 for Transport-wide Congestion Control", draft-holmer- 611 rmcat-transport-wide-cc-extensions-01 (work in progress), 612 October 2015. 614 [I-D.ietf-rmcat-gcc] 615 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 616 Mascolo, "A Google Congestion Control Algorithm for Real- 617 Time Communication", draft-ietf-rmcat-gcc-02 (work in 618 progress), July 2016. 620 [I-D.ietf-rmcat-nada] 621 Zhu, X., *, R., Ramalho, M., and S. Cruz, "NADA: A Unified 622 Congestion Control Scheme for Real-Time Media", draft- 623 ietf-rmcat-nada-13 (work in progress), September 2019. 625 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 626 "Codec Control Messages in the RTP Audio-Visual Profile 627 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 628 February 2008, . 630 [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol 631 (RTCP) Extended Report (XR) Block for Delay Metric 632 Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, 633 . 635 [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 636 for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 637 2017, . 639 [RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, 640 "Shared Bottleneck Detection for Coupled Congestion 641 Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, 642 June 2018, . 644 Authors' Addresses 646 Zaheduzzaman Sarker 647 Ericsson AB 648 Luleae 649 Sweden 651 Phone: +46107173743 652 Email: zaheduzzaman.sarker@ericsson.com 654 Colin Perkins 655 University of Glasgow 656 School of Computing Science 657 Glasgow G12 8QQ 658 United Kingdom 660 Email: csp@csperkins.org 662 Varun Singh 663 CALLSTATS I/O Oy 664 Annankatu 31-33 C 42 665 Helsinki 00100 666 Finland 668 Email: varun.singh@iki.fi 669 URI: http://www.callstats.io/ 670 Michael A. Ramalho 671 6310 Watercrest Way Unit 203 672 Lakewood Ranch, FL 34202-5122 673 USA 675 Phone: +1 732 832 9723 676 Email: mar42@cornell.edu 677 URI: http://ramalho.webhop.info/