idnits 2.17.1 draft-ietf-avtcore-cc-feedback-message-04.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 (July 8, 2019) is 1754 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') == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-nada-10 Summary: 1 error (**), 0 flaws (~~), 4 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: January 9, 2020 University of Glasgow 6 V. Singh 7 callstats.io 8 M. Ramalho 9 Cisco Systems 10 July 8, 2019 12 RTP Control Protocol (RTCP) Feedback for Congestion Control 13 draft-ietf-avtcore-cc-feedback-message-04 15 Abstract 17 This document describes an RTCP feedback message intended to enable 18 congestion control for interactive real-time traffic using RTP. The 19 feedback message is designed for use with a sender-based congestion 20 control algorithm, in which the receiver of an RTP flow sends RTCP 21 feedback packets to the sender containing the information the sender 22 needs to perform congestion control. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 9, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. RTCP Feedback for Congestion Control . . . . . . . . . . . . 3 61 3.1. RTCP Congestion Control Feedback Report . . . . . . . . . 4 62 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 63 5. Response to Loss of Feedback Packets . . . . . . . . . . . . 8 64 6. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. Relation to RFC 6679 . . . . . . . . . . . . . . . . . . . . 9 66 8. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 9 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 12.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 For interactive real-time traffic, such as video conferencing flows, 78 the typical protocol choice is the Real-time Transport Protocol (RTP) 79 running over the User Datagram Protocol (UDP). RTP does not provide 80 any guarantee of Quality of Service (QoS), reliability, or timely 81 delivery, and expects the underlying transport protocol to do so. 82 UDP alone certainly does not meet that expectation. However, the RTP 83 Control Protocol (RTCP) provides a mechanism by which the receiver of 84 an RTP flow can periodically send transport and media quality metrics 85 to the sender of that RTP flow. This information can be used by the 86 sender to perform congestion control. In the absence of standardized 87 messages for this purpose, designers of congestion control algorithms 88 have developed proprietary RTCP messages that convey only those 89 parameters needed for their respective designs. As a direct result, 90 the different congestion control (i.e., rate adaptation) designs are 91 not interoperable. To enable algorithm evolution as well as 92 interoperability across designs (e.g., different rate adaptation 93 algorithms), it is highly desirable to have generic congestion 94 control feedback format. 96 To help achieve interoperability for unicast RTP congestion control, 97 this memo proposes a common RTCP feedback packet format that can be 98 used by NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], Google 99 Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck 100 Detection [RFC8382], and hopefully also by future RTP congestion 101 control algorithms. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 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 [I-D.ietf-rmcat-nada], SCReAM [RFC8298], 115 Google 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 feedback 120 the sequence numbers of the received RTP packets to the sender, so 121 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 feedback 126 the arrival time of each RTP packet 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 feedback 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 are 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 represent the 228 packet was received and the subsequent bits in the block need to 229 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 RTS field of this RTCP congestion control feedback report. 237 The ATO field is in units of 1/1024 seconds (this unit is chosen 238 to give exact offsets from the RTS field) so, for example, an ATO 239 value of 512 indicates that the corresponding RTP packet arrived 240 exactly half a second before the time instant represented by the 241 RTS field. If the measured value is greater than 8189/1024 242 seconds (the value that would be coded as 0x1FFD), the value 243 0x1FFE MUST be reported to indicate an over-range measurement. If 244 the measurement is unavailable, or if the arrival time of the RTP 245 packet is after the time represented by the RTS field, then an ATO 246 value of 0x1FFF MUST be reported for the packet. 248 The RTCP congestion control feedback report packet concludes with the 249 Report Timestamp field (RTS, 32 bits). This denotes the time instant 250 on which this packet is reporting, and is the instant from which the 251 arrival time offset values are calculated. The value of RTS field is 252 derived from the same clock used to generate the NTP timestamp field 253 in RTCP Sender Report (SR) packets. It is formatted as the middle 32 254 bits of an NTP format timestamp, as described in Section 4 of 255 [RFC3550]. 257 RTCP congestion control feedback packets SHOULD include a report 258 block for every active SSRC. The sequence number ranges reported on 259 in consecutive reports for a given SSRC will generally be contiguous, 260 but overlapping reports MAY be sent (and need to be sent in cases 261 where RTP packet reordering occurs across the boundary between 262 consecutive reports). If reports covering overlapping sequence 263 number ranges are sent, information in later reports updates that in 264 sent previous reports for RTP packets included in both reports. If 265 an RTP packet was reported as received in one report, that packet 266 MUST also be reported as received in any overlapping reports sent 267 later that cover its sequence number range. 269 RTCP congestion control feedback packets can be large if they are 270 sent infrequently relative to the number of RTP data packets. If an 271 RTCP congestion control feedback packet is too large to fit within 272 the path MTU, its sender SHOULD split it into multiple feedback 273 packets. The RTCP reporting interval SHOULD be chosen such that 274 feedback packets are sent often enough that they are small enough to 275 fit within the path MTU ([I-D.ietf-rmcat-rtp-cc-feedback] provides 276 guidance on how to choose the reporting interval). 278 If duplicate copies of a particular RTP packet are received, then the 279 arrival time of the first copy to arrive MUST be reported. If any of 280 the copies of the duplicated packet are ECN-CE marked, then an ECN-CE 281 mark MUST be reported that for packet; otherwise the ECN mark of the 282 first copy to arrive is reported. 284 If no packets are received from an SSRC in a reporting interval, a 285 report block MAY be sent with begin_seq set to the highest sequence 286 number previously received from that SSRC and num_reports set to zero 287 (or, the report can simply to omitted). The corresponding SR/RR 288 packet will have a non-increased extended highest sequence number 289 received field that will inform the sender that no packets have been 290 received, but it can ease processing to have that information 291 available in the congestion control feedback reports too. 293 A report block indicating that certain RTP packets were lost is not 294 to be interpreted as a request to retransmit the lost packets. The 295 receiver of such a report might choose to retransmit such packets, 296 provided a retransmission payload format has been negotiated, but 297 there is no requirement that it do so. 299 4. Feedback Frequency and Overhead 301 There is a trade-off between speed and accuracy of reporting, and the 302 overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses 303 this trade-off, suggests desirable RTCP feedback rates, and provides 304 guidance on how to configure the RTCP bandwidth fraction, etc., to 305 make appropriate use of the reporting block described in this memo. 306 Specifications for RTP congestion control algorithms can also provide 307 guidance. 309 It is a general understanding that the congestion control algorithms 310 will work better with more frequent feedback - per packet feedback. 311 However, RTCP bandwidth and transmission rules put some upper limits 312 on how frequently the RTCP feedback messages can be send from the RTP 313 receiver to the RTP sender. It has been shown 314 [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame 315 feedback is a reasonable assumption on how frequent the RTCP feedback 316 messages can be transmitted. It has also been noted that even if a 317 higher frequency of feedback is desired it is not viable if the 318 feedback messages starts to compete against the RTP traffic on the 319 feedback path during congestion period. Analyzing the feedback 320 interval requirement [feedback-requirements] it can be seen that the 321 candidate algorithms can perform with a feedback interval range of 322 50-200ms. A value within this range need to be negotiated at session 323 setup. 325 5. Response to Loss of Feedback Packets 327 Like all RTCP packets, RTCP congestion control feedback packets might 328 be lost. All RTP congestion control algorithms MUST specify how they 329 respond to the loss of feedback packets. 331 If only a single congestion control feedback packet is lost, an 332 appropriate response is to assume that the level of congestion has 333 remained roughly the same as the previous report. However, if 334 multiple consecutive congestion control feedback packets are lost, 335 the sender SHOULD rapidly reduce its sending rate towards zero, as 336 this likely indicates a path failure. The RTP circuit breaker 337 [RFC8083] provides further guidance. 339 6. SDP Signalling 341 A new "ack" feedback parameter, "ccfb", is defined for use with the 342 "a=rtcp-fb:" SDP extension to indicate the use of the RTP Congestion 343 Control feedback packet format defined in Section 3. The ABNF 344 definition of this SDP parameter extension is: 346 rtcp-fb-ack-param = 347 rtcp-fb-ack-param =/ ccfb-par 348 ccfb-par = SP "ccfb" 350 When used with "ccfb" feedback, the wildcard payload type ("*") MUST 351 be used. This implies that the congestion control feedback is sent 352 for all payload types in use in the session, including any FEC and 353 retransmission payload types. An example of the resulting SDP 354 attribute is: 356 a=rtcp-fb:* ack ccfb 358 The offer/answer rules for these SDP feedback parameters are 359 specified in Section 4.2 of the RTP/AVPF profile [RFC4585]. 361 An SDP offer might indicate support for both the congestion control 362 feedback mechanism specified in this memo and one or more alternative 363 congestion control feedback mechanisms that offer substantially the 364 same semantics. In this case, the answering party SHOULD include 365 only one of the offered congestion control feedback mechanisms in its 366 answer. If a re-invite offering the same set of congestion control 367 feedback mechanisms is received, the generated answer SHOULD choose 368 the same congestion control feedback mechanism as in the original 369 answer where possible. 371 When the SDP BUNDLE extension 372 [I-D.ietf-mmusic-sdp-bundle-negotiation] is used for multiplexing, 373 the "a=rtcp-fb:" attribute has multiplexing category IDENTICAL-PER-PT 374 [I-D.ietf-mmusic-sdp-mux-attributes]. 376 7. Relation to RFC 6679 378 Use of Explicit Congestion Notification (ECN) with RTP is described 379 in [RFC6679]. That specifies how to negotiate the use of ECN with 380 RTP, and defines an RTCP ECN Feedback Packet to carry ECN feedback 381 reports. It uses an SDP "a=ecn-capaable-rtp:" attribute to negotiate 382 use of ECN, and the "a=rtcp-fb:" attributes with the "nack" parameter 383 "ecn" to negotiate the use of RTCP ECN Feedback Packets. 385 The RTCP ECN Feedback Packet is not useful when ECN is used with the 386 RTP Congestion Control Feedback Packet defined in this memo since it 387 provides duplicate information. Accordingly, when congestion control 388 feedback is to be used with RTP and ECN, the SDP offer generated MUST 389 include an "a=ecn-capable-rtp:" attribute to negotiate ECN support, 390 along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb" 391 to indicate that the RTP Congestion Control Feedback Packet is to be 392 used for feedback. The "a=rtcp-fb:" attribute MUST NOT include the 393 "nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be 394 used. 396 8. Design Rationale 398 The primary function of RTCP SR/RR packets is to report statistics on 399 the reception of RTP packets. The reception report blocks sent in 400 these packets contain information about observed jitter, fractional 401 packet loss, and cumulative packet loss. It was intended that this 402 information could be used to support congestion control algorithms, 403 but experience has shown that it is not sufficient for that purpose. 404 An efficient congestion control algorithm requires more fine grained 405 information on per packet reception quality than is provided by SR/RR 406 packets to react effectively. 408 The Codec Control Messages for the RTP/AVPF profile [RFC5104] include 409 a Temporary Maximum Media Bit Rate (TMMBR) message. This is used to 410 convey a temporary maximum bit rate limitation from a receiver of RTP 411 packets to their sender. Even though it was not designed to replace 412 congestion control, TMMBR has been used as a means to do receiver 413 based congestion control where the session bandwidth is high enough 414 to send frequent TMMBR messages, especially when used with non- 415 compound RTCP packets [RFC5506]. This approach requires the receiver 416 of the RTP packets to monitor their reception, determine the level of 417 congestion, and recommend a maximum bit rate suitable for current 418 available bandwidth on the path; it also assumes that the RTP sender 419 can/will respect that bit rate. This is the opposite of the sender 420 based congestion control approach suggested in this memo, so TMMBR 421 cannot be used to convey the information needed for a sender based 422 congestion control. TMMBR could, however, be viewed a complementary 423 mechanism that can inform the sender of the receiver's current view 424 of acceptable maximum bit rate. 426 A number of RTCP eXtended Report (XR) blocks have previously been 427 defined to report details of packet loss, arrival times [RFC3611], 428 delay [RFC6843], and ECN marking [RFC6679]. It is possible to 429 combine several such XR blocks to report the detailed loss, arrival 430 time, and ECN marking marking information needed for effective 431 sender-based congestion control. However, the result has high 432 overhead both in terms of bandwidth and complexity, due to the need 433 to stack multiple reports. 435 Considering these issues, we believe it appropriate to design a new 436 RTCP feedback mechanism to convey information for sender based 437 congestion control algorithms. The new congestion control feedback 438 RTCP packet described in Section 3 provides such a mechanism. 440 9. Acknowledgements 442 This document is based on the outcome of a design team discussion in 443 the RTP Media Congestion Avoidance Techniques (RMCAT) working group. 444 The authors would like to thank David Hayes, Stefan Holmer, Randell 445 Jesup, Ingemar Johansson, Jonathan Lennox, Sergio Mena, Nils 446 Ohlmeier, Magnus Westerlund, and Xiaoqing Zhu for their valuable 447 feedback. 449 10. IANA Considerations 451 The IANA is requested to register one new RTP/AVPF Transport-Layer 452 Feedback Message in the table for FMT values for RTPFB Payload Types 453 [RFC4585] as defined in Section 3.1: 455 Name: CCFB 456 Long name: RTP Congestion Control Feedback 457 Value: (to be assigned by IANA) 458 Reference: (RFC number of this document, when published) 460 The IANA is also requested to register one new SDP "rtcp-fb" 461 attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" 462 Attribute Values) registry: 464 Value name: ccfb 465 Long name: Congestion Control Feedback 466 Usable with: ack 467 Reference: (RFC number of this document, when published) 469 11. Security Considerations 471 The security considerations of the RTP specification [RFC3550], the 472 applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), 473 and the RTP congestion control algorithm that is in use (e.g., 474 [I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) 475 apply. 477 A receiver that intentionally generates inaccurate RTCP congestion 478 control feedback reports might be able trick the sender into sending 479 at a greater rate than the path can support, thereby congesting the 480 path. This will negatively impact the quality of experience of that 481 receiver. Since RTP is an unreliable transport, a sender can 482 intentionally leave a gap in the RTP sequence number space without 483 causing harm, to check that the receiver is correctly reporting 484 losses. 486 An on-path attacker that can modify RTCP congestion control feedback 487 packets can change the reports to trick the sender into sending at 488 either an excessively high or excessively low rate, leading to denial 489 of service. The secure RTCP profile [RFC3711] can be used to 490 authenticate RTCP packets to protect against this attack. 492 12. References 493 12.1. Normative References 495 [I-D.ietf-mmusic-sdp-bundle-negotiation] 496 Holmberg, C., Alvestrand, H., and C. Jennings, 497 "Negotiating Media Multiplexing Using the Session 498 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 499 negotiation-54 (work in progress), December 2018. 501 [I-D.ietf-mmusic-sdp-mux-attributes] 502 Nandakumar, S., "A Framework for SDP Attributes when 503 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17 504 (work in progress), February 2018. 506 [I-D.ietf-rmcat-rtp-cc-feedback] 507 Perkins, C., "RTP Control Protocol (RTCP) Feedback for 508 Congestion Control in Interactive Multimedia Conferences", 509 draft-ietf-rmcat-rtp-cc-feedback-04 (work in progress), 510 July 2018. 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, 514 DOI 10.17487/RFC2119, March 1997, 515 . 517 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 518 of Explicit Congestion Notification (ECN) to IP", 519 RFC 3168, DOI 10.17487/RFC3168, September 2001, 520 . 522 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 523 Jacobson, "RTP: A Transport Protocol for Real-Time 524 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 525 July 2003, . 527 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 528 Video Conferences with Minimal Control", STD 65, RFC 3551, 529 DOI 10.17487/RFC3551, July 2003, 530 . 532 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 533 "RTP Control Protocol Extended Reports (RTCP XR)", 534 RFC 3611, DOI 10.17487/RFC3611, November 2003, 535 . 537 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 538 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 539 RFC 3711, DOI 10.17487/RFC3711, March 2004, 540 . 542 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 543 "Extended RTP Profile for Real-time Transport Control 544 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 545 DOI 10.17487/RFC4585, July 2006, 546 . 548 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 549 Real-time Transport Control Protocol (RTCP)-Based Feedback 550 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 551 2008, . 553 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 554 Real-Time Transport Control Protocol (RTCP): Opportunities 555 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 556 2009, . 558 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 559 and K. Carlberg, "Explicit Congestion Notification (ECN) 560 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 561 2012, . 563 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 564 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 565 DOI 10.17487/RFC8083, March 2017, 566 . 568 12.2. Informative References 570 [feedback-requirements] 571 "RMCAT Feedback Requirements", 572 <://www.ietf.org/proceedings/95/slides/slides-95-rmcat- 573 1.pdf>. 575 [I-D.ietf-rmcat-gcc] 576 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 577 Mascolo, "A Google Congestion Control Algorithm for Real- 578 Time Communication", draft-ietf-rmcat-gcc-02 (work in 579 progress), July 2016. 581 [I-D.ietf-rmcat-nada] 582 Zhu, X., *, R., Ramalho, M., Cruz, S., Jones, P., Fu, J., 583 and S. D'Aronco, "NADA: A Unified Congestion Control 584 Scheme for Real-Time Media", draft-ietf-rmcat-nada-10 585 (work in progress), February 2019. 587 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 588 "Codec Control Messages in the RTP Audio-Visual Profile 589 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 590 February 2008, . 592 [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol 593 (RTCP) Extended Report (XR) Block for Delay Metric 594 Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, 595 . 597 [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 598 for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 599 2017, . 601 [RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, 602 "Shared Bottleneck Detection for Coupled Congestion 603 Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, 604 June 2018, . 606 Authors' Addresses 608 Zaheduzzaman Sarker 609 Ericsson AB 610 Luleae 611 Sweden 613 Phone: +46107173743 614 Email: zaheduzzaman.sarker@ericsson.com 616 Colin Perkins 617 University of Glasgow 618 School of Computing Science 619 Glasgow G12 8QQ 620 United Kingdom 622 Email: csp@csperkins.org 624 Varun Singh 625 CALLSTATS I/O Oy 626 Annankatu 31-33 C 42 627 Helsinki 00100 628 Finland 630 Email: varun.singh@iki.fi 631 URI: http://www.callstats.io/ 632 Michael A. Ramalho 633 Cisco Systems, Inc. 634 6310 Watercrest Way Unit 203 635 Lakewood Ranch, FL 34202 636 USA 638 Phone: +1 919 476 2038 639 Email: mramalho@cisco.com