idnits 2.17.1 draft-ietf-avtcore-cc-feedback-message-02.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 15, 2018) is 2111 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-rmcat-rtp-cc-feedback-03 ** 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-04 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: January 16, 2019 University of Glasgow 6 V. Singh 7 callstats.io 8 M. Ramalho 9 Cisco Systems 10 July 15, 2018 12 RTP Control Protocol (RTCP) Feedback for Congestion Control 13 draft-ietf-avtcore-cc-feedback-message-02 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 http://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 16, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . . 6 63 5. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 10.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 For interactive real-time traffic, such as video conferencing flows, 76 the typical protocol choice is the Real-time Transport Protocol (RTP) 77 running over the User Datagram Protocol (UDP). RTP does not provide 78 any guarantee of Quality of Service (QoS), reliability, or timely 79 delivery, and expects the underlying transport protocol to do so. 80 UDP alone certainly does not meet that expectation. However, the RTP 81 Control Protocol (RTCP) provides a mechanism by which the receiver of 82 an RTP flow can periodically send transport and media quality metrics 83 to the sender of that RTP flow. This information can be used by the 84 sender to perform congestion control. In the absence of standardized 85 messages for this purpose, designers of congestion control algorithms 86 have developed proprietary RTCP messages that convey only those 87 parameters needed for their respective designs. As a direct result, 88 the different congestion control (i.e., rate adaptation) designs are 89 not interoperable. To enable algorithm evolution as well as 90 interoperability across designs (e.g., different rate adaptation 91 algorithms), it is highly desirable to have generic congestion 92 control feedback format. 94 To help achieve interoperability for unicast RTP congestion control, 95 this memo proposes a common RTCP feedback packet format that can be 96 used by NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], Google 97 Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck 98 Detection [RFC8382], and hopefully also by future RTP congestion 99 control algorithms. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 In addition the terminology defined in [RFC3550], [RFC3551], 108 [RFC3611], [RFC4585], and [RFC5506] applies. 110 3. RTCP Feedback for Congestion Control 112 Based on an analysis of NADA [I-D.ietf-rmcat-nada], SCReAM [RFC8298], 113 Google Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck 114 Detection [RFC8382], the following per-RTP packet congestion control 115 feedback information has been determined to be necessary: 117 o RTP sequence number: The receiver of an RTP flow needs to feedback 118 the sequence numbers of the received RTP packets to the sender, so 119 the sender can determine which packets were received and which 120 were lost. Packet loss is used as an indication of congestion by 121 many congestion control algorithms. 123 o Packet Arrival Time: The receiver of an RTP flow needs to feedback 124 the arrival time of each RTP packet to the sender. Packet delay 125 and/or delay variation (jitter) is used as a congestion signal by 126 some congestion control algorithms. 128 o Packet Explicit Congestion Notification (ECN) Marking: If ECN 129 [RFC3168], [RFC6679] is used, it is necessary to feedback the 130 2-bit ECN mark in received RTP packets, indicating for each RTP 131 packet whether it is marked not-ECT, ECT(0), ECT(1), or ECN-CE. 132 If the path used by the RTP traffic is ECN capable the sender can 133 use Congestion Experienced (ECN-CE) marking information as a 134 congestion control signal. 136 Every RTP flow is identified by its Synchronization Source (SSRC) 137 identifier. Accordingly, the RTCP feedback format needs to group its 138 reports by SSRC, sending one report block per received SSRC. 140 As a practical matter, we note that host operating system (OS) 141 process interruptions can occur at inopportune times. Accordingly, 142 recording RTP packet send times at the sender, and the corresponding 143 RTP packet arrival times at the receiver, needs to be done with 144 deliberate care. This is because the time duration of host OS 145 interruptions can be significant relative to the precision desired in 146 the one-way delay estimates. Specifically, the send time needs to be 147 recorded at the last opportunity prior to transmitting the RTP packet 148 at the sender, and the arrival time at the receiver needs to be 149 recorded at the earliest available opportunity. 151 3.1. RTCP Congestion Control Feedback Report 153 Congestion control feedback can be sent as part of a regular 154 scheduled RTCP report, or in an RTP/AVPF early feedback packet. If 155 sent as early feedback, congestion control feedback MAY be sent in a 156 non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] 157 or the RTP/SAVPF profile [RFC5124] is used. 159 Irrespective of how it is transported, the congestion control 160 feedback is sent as a Transport Layer Feedback Message (RTCP packet 161 type 205). The format of this RTCP packet is shown in Figure 1: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |V=2|P| FMT=CCFB | PT = 205 | length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | SSRC of RTCP packet sender | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | SSRC of 1st RTP Stream | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | begin_seq | end_seq+1 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |L|ECN| Arrival time offset | ... . 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 . . 177 . . 178 . . 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | SSRC of nth RTP Stream | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | begin_seq | end_seq+1 | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |L|ECN| Arrival time offset | ... | 185 . . 186 . . 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Report Timestamp (32bits) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: RTCP Congestion Control Feedback Packet Format 193 The first eight octets comprise a standard RTCP header, with PT=205 194 and FMT=CCFB indicating that this is a congestion control feedback 195 packet, and with the SSRC set to that of the sender of the RTCP 196 packet. (NOTE TO RFC EDITOR: please replace CCFB here and in the 197 above diagram with the IANA assigned RTCP feedback packet type, and 198 remove this note) 200 Section 6.1 of [RFC4585] requires the RTCP header to be followed by 201 the SSRC of the RTP flow being reported upon. Accordingly, the RTCP 202 header is followed by a report block for each SSRC from which RTP 203 packets have been received, followed by a Report Timestamp. 205 Each report block begins with the SSRC of the received RTP Stream on 206 which it is reporting. Following this, the report block contains a 207 16-bit packet metric block for each RTP packet with sequence number, 208 seq, in the range begin_seq <= seq < end_seq+1 (calculated using 209 arithmetic modulo 65535 to account for possible sequence number wrap- 210 around). If the number of 16-bit packet metric blocks included in 211 the report block is not a multiple of two, then 16 bits of zero 212 padding MUST be added after the last packet metric block, to align 213 the end of the packet metric blocks with the next 32 bit boundary. 214 Each report block MUST NOT include more than 16384 packet metric 215 blocks (i.e., it MUST NOT report on more than one quarter of the 216 sequence number space in a single report). 218 The contents of each 16-bit packet metric block comprises the L, ECN, 219 and ATO fields are as follows: 221 o L (1 bit): is a boolean to indicate if the packet was received. 0 222 represents that the packet was not yet received and all the 223 subsequent bits (ECN and ATO) are also set to 0. 1 represent the 224 packet was received and the subsequent bits in the block need to 225 be parsed. 227 o ECN (2 bits): is the echoed ECN mark of the packet. These are set 228 to 00 if not received, or if ECN is not used. 230 o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP 231 packet at the receiver. It is measured as an offset from the time 232 at which the RTCP congestion control feedback report packet is 233 sent. The arrival time offset is calculated by subtracting the 234 reception time of the RTP packet denoted by this 16 bit packet 235 metric block from the Report Timestamp (RTS) field of the RTCP 236 congestion control feedback report packet in which the packet 237 metric report block is contained. The arrival time offset is 238 measured in units of 1/1024 seconds (this unit is chosen to give 239 exact offsets from the RTS field). If the measured value is 240 greater than 8189/1024 seconds (the value that would be coded as 241 0x1FFD), the value 0x1FFE MUST be reported to indicate an over- 242 range positive measurement. If the measurement is unavailable, 243 the value 0x1FFF MUST be reported. 245 The RTCP congestion control feedback report packet concludes with the 246 Report Timestamp field (RTS, 32 bits). This represents the time 247 instant when the report packet was generated. The value of RTS field 248 is derived from the same wallclock used to generate the NTP timestamp 249 field in RTCP Sender Report (SR) packets. It is formatted as the 250 middle 32 bits of an NTP format timestamp, as described in Section 4 251 of [RFC3550]. 253 RTCP congestion control feedback packets SHOULD include a report 254 block for each SSRC that is being congestion controlled. The 255 sequence number ranges reported on in consecutive reports for an SSRC 256 SHOULD be consecutive and SHOULD NOT overlap (i.e., begin_seq for a 257 report is expected to be one greater, modulo 65535, than end_seq of 258 the previous report for that SSRC). If overlapping reports are sent, 259 the information in the later report updates that in any previous 260 reports for packets included in both reports (although note that such 261 updated information will likely arrive too late to affect congestion 262 control decisions at the sender). Reports that cover RTP sequence 263 number ranges that are more than 16384 (i.e., one quarter of the 264 sequence number space) ahead of the last end_seq received from an 265 SSRC, or behind the last begin_seq received from an SSRC, modulo 266 65535 to account for wrap-around, SHOULD be ignored. An exception to 267 this occurs if sender has sent RTP packets using more than one 268 quarter of the sequence number space since it last received an RTCP 269 congestion control feedback packet, then a report on recently sent 270 RTP packets ought to be accepted, to allow recovery from report 271 packet loss. 273 If no packets are received from an SSRC in a reporting interval, a 274 report block MAY be sent with begin_seq and end_seq+1 both set to the 275 highest sequence number previously received from that SSRC (or, the 276 report can simply to omitted). The corresponding SR/RR packet will 277 have a non-increased extended highest sequence number received field 278 that will inform the sender that no packets have been received, but 279 it can ease processing to have that information available in the 280 congestion control feedback reports too. 282 4. Feedback Frequency and Overhead 284 There is a trade-off between speed and accuracy of reporting, and the 285 overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses 286 this trade-off, suggests desirable RTCP feedback rates, and provides 287 guidance on how to configure the RTCP bandwidth fraction, etc., to 288 make appropriate use of the reporting block described in this memo. 290 Specifications for RTP congestion control algorithms can also provide 291 guidance. 293 It is a general understanding that the congestion control algorithms 294 will work better with more frequent feedback - per packet feedback. 295 However, RTCP bandwidth and transmission rules put some upper limits 296 on how frequently the RTCP feedback messages can be send from the RTP 297 receiver to the RTP sender. It has been shown 298 [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame 299 feedback is a reasonable assumption on how frequent the RTCP feedback 300 messages can be transmitted. It has also been noted that even if a 301 higher frequency of feedback is desired it is not viable if the 302 feedback messages starts to compete against the RTP traffic on the 303 feedback path during congestion period. Analyzing the feedback 304 interval requirement [feedback-requirements] it can be seen that the 305 candidate algorithms can perform with a feedback interval range of 306 50-200ms. A value within this range need to be negotiated at session 307 setup. 309 5. SDP Signalling 311 A new "ack" feedback parameter, "ccfb", is defined to indicate the 312 use of the RTP Congestion Control feedback packet format defined in 313 Section 3. The ABNF definition of this SDP parameter extension is: 315 rtcp-fb-ack-param = 316 rtcp-fb-ack-param =/ ccfb-par 317 ccfb-par = SP "ccfb" 319 The offer/answer rules for these SDP feedback parameters are 320 specified in the RTP/AVPF profile [RFC4585]. 322 6. Design Rationale 324 The primary function of RTCP SR/RR packets is to report statistics on 325 the reception of RTP packets. The reception report blocks sent in 326 these packets contain information about observed jitter, fractional 327 packet loss, and cumulative packet loss. It was intended that this 328 information could be used to support congestion control algorithms, 329 but experience has shown that it is not sufficient for that purpose. 330 An efficient congestion control algorithm requires more fine grained 331 information on per packet reception quality than is provided by SR/RR 332 packets to react effectively. 334 The Codec Control Messages for the RTP/AVPF profile [RFC5104] include 335 a Temporary Maximum Media Bit Rate (TMMBR) message. This is used to 336 convey a temporary maximum bit rate limitation from a receiver of RTP 337 packets to their sender. Even though it was not designed to replace 338 congestion control, TMMBR has been used as a means to do receiver 339 based congestion control where the session bandwidth is high enough 340 to send frequent TMMBR messages, especially when used with non- 341 compound RTCP packets [RFC5506]. This approach requires the receiver 342 of the RTP packets to monitor their reception, determine the level of 343 congestion, and recommend a maximum bit rate suitable for current 344 available bandwidth on the path; it also assumes that the RTP sender 345 can/will respect that bit rate. This is the opposite of the sender 346 based congestion control approach suggested in this memo, so TMMBR 347 cannot be used to convey the information needed for a sender based 348 congestion control. TMMBR could, however, be viewed a complementary 349 mechanism that can inform the sender of the receiver's current view 350 of acceptable maximum bit rate. 352 A number of RTCP eXtended Report (XR) blocks have previously been 353 defined to report details of packet loss, arrival times [RFC3611], 354 delay [RFC6843], and ECN marking [RFC6679]. It is possible to 355 combine several such XR blocks to report the detailed loss, arrival 356 time, and ECN marking marking information needed for effective 357 sender-based congestion control. However, the result has high 358 overhead both in terms of bandwidth and complexity, due to the need 359 to stack multiple reports. 361 Considering these issues, we believe it appropriate to design a new 362 RTCP feedback mechanism to convey information for sender based 363 congestion control algorithms. The new congestion control feedback 364 RTCP packet described in Section 3 provides such a mechanism. 366 7. Acknowledgements 368 This document is an outcome of RMCAT design team discussion. We 369 would like to thank all participants specially Sergio Mena, Xiaoquing 370 Zhu, Stefan Holmer, David, Ingemar Johansson, Randell Jesup, Ingemar 371 Johansson, and Magnus Westerlund for their valuable contribution to 372 the discussions and to the document. 374 8. IANA Considerations 376 The IANA is requested to register one new RTP/AVPF Transport-Layer 377 Feedback Message in the table for FMT values for RTPFB Payload Types 378 [RFC4585] as defined in Section 3.1: 380 Name: CCFB 381 Long name: RTP Congestion Control Feedback 382 Value: (to be assigned by IANA) 383 Reference: (RFC number of this document, when published) 385 The IANA is also requested to register one new SDP "rtcp-fb" 386 attribute "ack" parameter, "ccfb", in the SDP ("ack" and "nack" 387 Attribute Values) registry: 389 Value name: ccfb 390 Long name: Congestion Control Feedback 391 Usable with: ack 392 Reference: (RFC number of this document, when published) 394 9. Security Considerations 396 The security considerations of the RTP specification [RFC3550], the 397 applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), 398 and the RTP congestion control algorithm that is in use (e.g., 399 [I-D.ietf-rmcat-nada], [RFC8298], [I-D.ietf-rmcat-gcc], or [RFC8382]) 400 apply. 402 A receiver that intentionally generates inaccurate RTCP congestion 403 control feedback reports might be able trick the sender into sending 404 at a greater rate than the path can support, thereby congesting the 405 path. This will negatively impact the quality of experience of that 406 receiver. Since RTP is an unreliable transport, a sender can 407 intentionally leave a gap in the RTP sequence number space without 408 causing harm, to check that the receiver is correctly reporting 409 losses. 411 An on-path attacker that can modify RTCP congestion control feedback 412 packets can change the reports to trick the sender into sending at 413 either an excessively high or excessively low rate, leading to denial 414 of service. The secure RTCP profile [RFC3711] can be used to 415 authenticate RTCP packets to protect against this attack. 417 10. References 419 10.1. Normative References 421 [I-D.ietf-rmcat-rtp-cc-feedback] 422 Perkins, C., "RTP Control Protocol (RTCP) Feedback for 423 Congestion Control in Interactive Multimedia Conferences", 424 draft-ietf-rmcat-rtp-cc-feedback-03 (work in progress), 425 November 2016. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, . 432 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 433 of Explicit Congestion Notification (ECN) to IP", 434 RFC 3168, DOI 10.17487/RFC3168, September 2001, 435 . 437 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 438 Jacobson, "RTP: A Transport Protocol for Real-Time 439 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 440 July 2003, . 442 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 443 Video Conferences with Minimal Control", STD 65, RFC 3551, 444 DOI 10.17487/RFC3551, July 2003, . 447 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 448 "RTP Control Protocol Extended Reports (RTCP XR)", 449 RFC 3611, DOI 10.17487/RFC3611, November 2003, 450 . 452 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 453 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 454 RFC 3711, DOI 10.17487/RFC3711, March 2004, 455 . 457 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 458 "Extended RTP Profile for Real-time Transport Control 459 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 460 DOI 10.17487/RFC4585, July 2006, . 463 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 464 Real-time Transport Control Protocol (RTCP)-Based Feedback 465 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 466 2008, . 468 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 469 Real-Time Transport Control Protocol (RTCP): Opportunities 470 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 471 2009, . 473 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 474 and K. Carlberg, "Explicit Congestion Notification (ECN) 475 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 476 2012, . 478 10.2. Informative References 480 [feedback-requirements] 481 "RMCAT Feedback Requirements", 482 <://www.ietf.org/proceedings/95/slides/slides-95-rmcat- 483 1.pdf>. 485 [I-D.ietf-rmcat-gcc] 486 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 487 Mascolo, "A Google Congestion Control Algorithm for Real- 488 Time Communication", draft-ietf-rmcat-gcc-02 (work in 489 progress), July 2016. 491 [I-D.ietf-rmcat-nada] 492 Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, 493 J., and S. D'Aronco, "NADA: A Unified Congestion Control 494 Scheme for Real-Time Media", draft-ietf-rmcat-nada-04 495 (work in progress), March 2017. 497 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 498 "Codec Control Messages in the RTP Audio-Visual Profile 499 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 500 February 2008, . 502 [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol 503 (RTCP) Extended Report (XR) Block for Delay Metric 504 Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, 505 . 507 [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 508 for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 509 2017, . 511 [RFC8382] Hayes, D., Ed., Ferlin, S., Welzl, M., and K. Hiorth, 512 "Shared Bottleneck Detection for Coupled Congestion 513 Control for RTP Media", RFC 8382, DOI 10.17487/RFC8382, 514 June 2018, . 516 Authors' Addresses 518 Zaheduzzaman Sarker 519 Ericsson AB 520 Luleae 521 Sweden 523 Phone: +46107173743 524 Email: zaheduzzaman.sarker@ericsson.com 525 Colin Perkins 526 University of Glasgow 527 School of Computing Science 528 Glasgow G12 8QQ 529 United Kingdom 531 Email: csp@csperkins.org 533 Varun Singh 534 CALLSTATS I/O Oy 535 Annankatu 31-33 C 42 536 Helsinki 00100 537 Finland 539 Email: varun.singh@iki.fi 540 URI: http://www.callstats.io/ 542 Michael A. Ramalho 543 Cisco Systems, Inc. 544 6310 Watercrest Way Unit 203 545 Lakewood Ranch, FL 34202 546 USA 548 Phone: +1 919 476 2038 549 Email: mramalho@cisco.com