idnits 2.17.1 draft-ietf-avtcore-cc-feedback-message-01.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 (March 2, 2018) is 2247 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 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-sbd-08 == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-scream-cc-10 Summary: 1 error (**), 0 flaws (~~), 5 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: September 3, 2018 University of Glasgow 6 V. Singh 7 callstats.io 8 M. Ramalho 9 Cisco Systems 10 March 2, 2018 12 RTP Control Protocol (RTCP) Feedback for Congestion Control 13 draft-ietf-avtcore-cc-feedback-message-01 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 September 3, 2018. 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. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 9.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 For interactive real-time traffic, such as video conferencing flows, 75 the typical protocol choice is the Real-time Transport Protocol (RTP) 76 running over the User Datagram Protocol (UDP). RTP does not provide 77 any guarantee of Quality of Service (QoS), reliability, or timely 78 delivery, and expects the underlying transport protocol to do so. 79 UDP alone certainly does not meet that expectation. However, the RTP 80 Control Protocol (RTCP) provides a mechanism by which the receiver of 81 an RTP flow can periodically send transport and media quality metrics 82 to the sender of that RTP flow. This information can be used by the 83 sender to perform congestion control. In the absence of standardized 84 messages for this purpose, designers of congestion control algorithms 85 have developed proprietary RTCP messages that convey only those 86 parameters needed for their respective designs. As a direct result, 87 the different congestion control (i.e., rate adaptation) designs are 88 not interoperable. To enable algorithm evolution as well as 89 interoperability across designs (e.g., different rate adaptation 90 algorithms), it is highly desirable to have generic congestion 91 control feedback format. 93 To help achieve interoperability for unicast RTP congestion control, 94 this memo proposes a common RTCP feedback packet format that can be 95 used by NADA [I-D.ietf-rmcat-nada], SCReAM 96 [I-D.ietf-rmcat-scream-cc], Google Congestion Control 98 [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection 99 [I-D.ietf-rmcat-sbd], 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 114 [I-D.ietf-rmcat-scream-cc], Google Congestion Control 115 [I-D.ietf-rmcat-gcc] and Shared Bottleneck Detection 116 [I-D.ietf-rmcat-sbd], 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 | end_seq | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |L|ECN| Arrival time offset | ... . 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 . . 179 . . 180 . . 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | SSRC of nth RTP Stream | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | begin_seq | end_seq | 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, each sequence number between 209 the begin_seq and end_seq (both inclusive; modulo 65535 to account 210 for possible sequence number wrap-around) is represented by a 16-bit 211 packet metric block that contains the L, ECN, and ATO fields. If the 212 number of 16-bit packet metric blocks included in the report block is 213 not a multiple of two, then 16 bits of zero padding MUST be added 214 after the last packet metric block, to align the end of the packet 215 metric blocks with the next 32 bit boundary. In each packet metric 216 block, the L, ECN, and ATO fields are as follows: 218 o L (1 bit): is a boolean to indicate if the packet was received. 0 219 represents that the packet was not yet received and all the 220 subsequent bits (ECN and ATO) are also set to 0. 1 represent the 221 packet was received and the subsequent bits in the block need to 222 be parsed. 224 o ECN (2 bits): is the echoed ECN mark of the packet. These are set 225 to 00 if not received, or if ECN is not used. 227 o Arrival time offset (ATO, 13 bits): is the arrival time of the RTP 228 packet at the receiver. It is measured as an offset from the time 229 at which the RTCP congestion control feedback report packet is 230 sent. The arrival time offset is calculated by subtracting the 231 reception time of the RTP packet denoted by this 16 bit packet 232 metric block from the Report Timestamp (RTS) field of the RTCP 233 congestion control feedback report packet in which the packet 234 metric report block is contained. The arrival time offset is 235 measured in units of 1/1024 seconds (this unit is chosen to give 236 exact offsets from the RTS field). If the measured value is 237 greater than 8189/1024 seconds (the value that would be coded as 238 0x1FFD), the value 0x1FFE MUST be reported to indicate an over- 239 range positive measurement. If the measurement is unavailable, 240 the value 0x1FFF MUST be reported. 242 The RTCP congestion control feedback report packet concludes with the 243 Report Timestamp field (RTS, 32 bits). This represents the time 244 instant when the report packet was generated. The value of RTS field 245 is derived from the same wallclock used to generate the NTP timestamp 246 field in RTCP Sender Report (SR) and Receiver Report (RR) packets. 247 It is formatted as the middle 32 bits of an NTP format timestamp, as 248 described in Section 4 of [RFC3550]. 250 RTCP congestion control feedback packets SHOULD include a report 251 block for each SSRC that is being congestion controlled. The 252 sequence number ranges reported on in consecutive reports for an SSRC 253 SHOULD be consecutive and SHOULD NOT overlap (i.e., begin_seq for a 254 report is expected to be one greater, modulo 65535, than end_seq of 255 the previous report for that SSRC). If overlapping reports are sent, 256 the information in the later report updates that in any previous 257 reports for packets included in both reports (although note that such 258 updated information will likely arrive too late to affect congestion 259 control decisions at the sender). Reports that cover RTP sequence 260 number ranges that are more than 16384 (i.e., one quarter of the 261 sequence number space) ahead of the last end_seq received from an 262 SSRC, or behind the last begin_seq received from an SSRC, modulo 263 65535 to account for wrap-around, MUST be ignored. 265 If no packets are received from an SSRC in a reporting interval, then 266 no report block is sent for that SSRC. A regular SR/RR packet SHOULD 267 be sent instead, since the non-increased extended highest sequence 268 number received field of that SR/RR packet will inform the sender 269 that no packets have been received. 271 4. Feedback Frequency and Overhead 273 There is a trade-off between speed and accuracy of reporting, and the 274 overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses 275 this trade-off, suggests desirable RTCP feedback rates, and provides 276 guidance on how to configure the RTCP bandwidth fraction, etc., to 277 make appropriate use of the reporting block described in this memo. 278 Specifications for RTP congestion control algorithms can also provide 279 guidance. 281 It is a general understanding that the congestion control algorithms 282 will work better with more frequent feedback - per packet feedback. 283 However, RTCP bandwidth and transmission rules put some upper limits 284 on how frequently the RTCP feedback messages can be send from the RTP 285 receiver to the RTP sender. It has been shown 286 [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame 287 feedback is a reasonable assumption on how frequent the RTCP feedback 288 messages can be transmitted. It has also been noted that even if a 289 higher frequency of feedback is desired it is not viable if the 290 feedback messages starts to compete against the RTP traffic on the 291 feedback path during congestion period. Analyzing the feedback 292 interval requirement [feedback-requirements] it can be seen that the 293 candidate algorithms can perform with a feedback interval range of 294 50-200ms. A value within this range need to be negotiated at session 295 setup. 297 5. Design Rationale 299 The primary function of RTCP SR/RR packets is to report statistics on 300 the reception of RTP packets. The reception report blocks sent in 301 these packets contain information about observed jitter, fractional 302 packet loss, and cumulative packet loss. It was intended that this 303 information could be used to support congestion control algorithms, 304 but experience has shown that it is not sufficient for that purpose. 305 An efficient congestion control algorithm requires more fine grained 306 information on per packet reception quality than is provided by SR/RR 307 packets to react effectively. 309 The Codec Control Messages for the RTP/AVPF profile [RFC5104] include 310 a Temporary Maximum Media Bit Rate (TMMBR) message. This is used to 311 convey a temporary maximum bit rate limitation from a receiver of RTP 312 packets to their sender. Even though it was not designed to replace 313 congestion control, TMMBR has been used as a means to do receiver 314 based congestion control where the session bandwidth is high enough 315 to send frequent TMMBR messages, especially when used with non- 316 compound RTCP packets [RFC5506]. This approach requires the receiver 317 of the RTP packets to monitor their reception, determine the level of 318 congestion, and recommend a maximum bit rate suitable for current 319 available bandwidth on the path; it also assumes that the RTP sender 320 can/will respect that bit rate. This is the opposite of the sender 321 based congestion control approach suggested in this memo, so TMMBR 322 cannot be used to convey the information needed for a sender based 323 congestion control. TMMBR could, however, be viewed a complementary 324 mechanism that can inform the sender of the receiver's current view 325 of acceptable maximum bit rate. 327 A number of RTCP eXtended Report (XR) blocks have previously been 328 defined to report details of packet loss, arrival times [RFC3611], 329 delay [RFC6843], and ECN marking [RFC6679]. It is possible to 330 combine several such XR blocks to report the detailed loss, arrival 331 time, and ECN marking marking information needed for effective 332 sender-based congestion control. However, the result has high 333 overhead both in terms of bandwidth and complexity, due to the need 334 to stack multiple reports. 336 Considering these issues, we believe it appropriate to design a new 337 RTCP feedback mechanism to convey information for sender based 338 congestion control algorithms. The new congestion control feedback 339 RTCP packet described in Section 3 provides such a mechanism. 341 6. Acknowledgements 343 This document is an outcome of RMCAT design team discussion. We 344 would like to thank all participants specially Xiaoquing Zhu, Stefan 345 Holmer, David, Ingemar Johansson, Randell Jesup, Ingemar Johansson, 346 and Magnus Westerlund for their valuable contribution to the 347 discussions and to the document. 349 7. IANA Considerations 351 IANA is requested to assign a new value in the "FMT Values for RTPFB 352 Payload Types" registry for the CCFB transport layer feedback packet 353 described in Section 3.1. 355 8. Security Considerations 357 The security considerations of the RTP specification [RFC3550], the 358 applicable RTP profile (e.g., [RFC3551], [RFC3711], or [RFC4585]), 359 and the RTP congestion control algorithm that is in use (e.g., 360 [I-D.ietf-rmcat-nada], [I-D.ietf-rmcat-scream-cc], 361 [I-D.ietf-rmcat-gcc], or [I-D.ietf-rmcat-sbd]) apply. 363 A receiver that intentionally generates inaccurate RTCP congestion 364 control feedback reports might be able trick the sender into sending 365 at a greater rate than the path can support, thereby congesting the 366 path. This will negatively impact the quality of experience of that 367 receiver. Since RTP is an unreliable transport, a sender can 368 intentionally leave a gap in the RTP sequence number space without 369 causing harm, to check that the receiver is correctly reporting 370 losses. 372 An on-path attacker that can modify RTCP congestion control feedback 373 packets can change the reports to trick the sender into sending at 374 either an excessively high or excessively low rate, leading to denial 375 of service. The secure RTCP profile [RFC3711] can be used to 376 authenticate RTCP packets to protect against this attack. 378 9. References 380 9.1. Normative References 382 [I-D.ietf-rmcat-rtp-cc-feedback] 383 Perkins, C., "RTP Control Protocol (RTCP) Feedback for 384 Congestion Control in Interactive Multimedia Conferences", 385 draft-ietf-rmcat-rtp-cc-feedback-03 (work in progress), 386 November 2016. 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, 390 DOI 10.17487/RFC2119, March 1997, . 393 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 394 of Explicit Congestion Notification (ECN) to IP", 395 RFC 3168, DOI 10.17487/RFC3168, September 2001, 396 . 398 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 399 Jacobson, "RTP: A Transport Protocol for Real-Time 400 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 401 July 2003, . 403 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 404 Video Conferences with Minimal Control", STD 65, RFC 3551, 405 DOI 10.17487/RFC3551, July 2003, . 408 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 409 "RTP Control Protocol Extended Reports (RTCP XR)", 410 RFC 3611, DOI 10.17487/RFC3611, November 2003, 411 . 413 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 414 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 415 RFC 3711, DOI 10.17487/RFC3711, March 2004, 416 . 418 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 419 "Extended RTP Profile for Real-time Transport Control 420 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 421 DOI 10.17487/RFC4585, July 2006, . 424 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 425 Real-time Transport Control Protocol (RTCP)-Based Feedback 426 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 427 2008, . 429 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 430 Real-Time Transport Control Protocol (RTCP): Opportunities 431 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 432 2009, . 434 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 435 and K. Carlberg, "Explicit Congestion Notification (ECN) 436 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 437 2012, . 439 9.2. Informative References 441 [feedback-requirements] 442 "RMCAT Feedback Requirements", 443 <://www.ietf.org/proceedings/95/slides/slides-95-rmcat- 444 1.pdf>. 446 [I-D.ietf-rmcat-gcc] 447 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 448 Mascolo, "A Google Congestion Control Algorithm for Real- 449 Time Communication", draft-ietf-rmcat-gcc-02 (work in 450 progress), July 2016. 452 [I-D.ietf-rmcat-nada] 453 Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, 454 J., and S. D'Aronco, "NADA: A Unified Congestion Control 455 Scheme for Real-Time Media", draft-ietf-rmcat-nada-04 456 (work in progress), March 2017. 458 [I-D.ietf-rmcat-sbd] 459 Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared 460 Bottleneck Detection for Coupled Congestion Control for 461 RTP Media.", draft-ietf-rmcat-sbd-08 (work in progress), 462 July 2017. 464 [I-D.ietf-rmcat-scream-cc] 465 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 466 for Multimedia", draft-ietf-rmcat-scream-cc-10 (work in 467 progress), July 2017. 469 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 470 "Codec Control Messages in the RTP Audio-Visual Profile 471 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 472 February 2008, . 474 [RFC6843] Clark, A., Gross, K., and Q. Wu, "RTP Control Protocol 475 (RTCP) Extended Report (XR) Block for Delay Metric 476 Reporting", RFC 6843, DOI 10.17487/RFC6843, January 2013, 477 . 479 Authors' Addresses 481 Zaheduzzaman Sarker 482 Ericsson AB 483 Luleae 484 Sweden 486 Phone: +46107173743 487 Email: zaheduzzaman.sarker@ericsson.com 489 Colin Perkins 490 University of Glasgow 491 School of Computing Science 492 Glasgow G12 8QQ 493 United Kingdom 495 Email: csp@csperkins.org 497 Varun Singh 498 CALLSTATS I/O Oy 499 Annankatu 31-33 C 42 500 Helsinki 00100 501 Finland 503 Email: varun.singh@iki.fi 504 URI: http://www.callstats.io/ 506 Michael A. Ramalho 507 Cisco Systems, Inc. 508 6310 Watercrest Way Unit 203 509 Lakewood Ranch, FL 34202 510 USA 512 Phone: +1 919 476 2038 513 Email: mramalho@cisco.com