idnits 2.17.1 draft-dt-rmcat-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 02, 2017) is 2550 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-06 == Outdated reference: A later version (-13) exists of draft-ietf-rmcat-scream-cc-07 Summary: 1 error (**), 0 flaws (~~), 6 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: November 3, 2017 University of Glasgow 6 V. Singh 7 callstats.io 8 M. Ramalho 9 Cisco Systems 10 May 02, 2017 12 RTP Control Protocol (RTCP) Feedback for Congestion Control 13 draft-dt-rmcat-feedback-message-02 15 Abstract 17 This document describes a feedback message intended to enable 18 congestion control for interactive real-time traffic. The RTP Media 19 Congestion Avoidance Techniques (RMCAT) Working Group formed a design 20 team to analyze feedback requirements from various congestion control 21 algorithms and to design a generic feedback message to help ensure 22 interoperability across those algorithms. The feedback message is 23 designed for a sender-based congestion control, which means the 24 receiver of the media will send necessary feedback to the sender of 25 the media to perform the congestion control at the sender. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 3, 2017. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Feedback Message . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. RTCP XR Block for Reporting Congestion Control Feedback . 4 65 3.2. RTP/AVPF Transport Layer Feedback for Congestion Control 6 66 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 7 67 5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 9 71 7.2. RTCP XR Report Blocks . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 For interactive real-time traffic the typical protocol choice is 81 Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP). 82 RTP does not provide any guarantee of Quality of Service (QoS), 83 reliable or timely delivery and expects the underlying transport 84 protocol to do so. UDP alone certainly does not meet that 85 expectation. However, RTP Control Protocol (RTCP) provides a 86 mechanism to periodically send transport and media metrics to the 87 media sender which can be utilized and extended for the purposes of 88 RMCAT congestion control. For a congestion control algorithm which 89 operates at the media sender, RTCP messages can be transmitted from 90 the media receiver back to the media sender to enable congestion 91 control. In the absence of standardized messages for this purpose, 92 the congestion control algorithm designers have designed proprietary 93 RTCP messages that convey only those parameters required for their 94 respective designs. As a direct result, the different congestion 95 control (a.k.a. rate adaptation) designs are not interoperable. To 96 enable algorithm evolution as well as interoperability across designs 97 (e.g., different rate adaptation algorithms), it is highly desirable 98 to have generic congestion control feedback format. 100 To help achieve interoperability for unicast RTP congestion control, 101 this memo proposes a common RTCP feedback format that can be used by 102 NADA [I-D.ietf-rmcat-nada], SCReAM [I-D.ietf-rmcat-scream-cc], Google 103 Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck 104 Detection [I-D.ietf-rmcat-sbd], and hopefully future RTP congestion 105 control algorithms as well. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 In addition the terminology defined in [RFC3550], [RFC3551], 114 [RFC3611], [RFC4585], and [RFC5506] applies. 116 3. Feedback Message 118 The design team analyzed the feedback requirements from the different 119 proposed candidate in RMCAT WG. The analysis showed some 120 commonalities between the proposed solution candidate and some can be 121 derived from other information. The design team has agreed to have 122 following packet information block in the feedback message to satisfy 123 different requirement analyzed. 125 o Packet Identifier : RTP sequence number. The RTP packet header 126 includes an incremental packet sequence number that the sender 127 needs to correlate packets sent at the sender with packets 128 received at the receiver. 130 o Packet Arrival Time : Arrival time stamp at the receiver of the 131 media. The sender requires the arrival time stamp of the 132 respective packet to determine delay and jitter the packet had 133 experienced during transmission. In a sender based congestion 134 control solution the sender requires to keep track of the sent 135 packets - usually packet sequence number, packet size and packet 136 send time. With the packet arrival time the sender can detect the 137 delay and jitter information. Along with packet loss and delay 138 information the sender can estimate the available bandwidth and 139 thus adapt to the situation. 141 o Packet Explicit Congestion Notification (ECN) Marking : If ECN 142 [RFC3168] is used, it is necessary to report on the 2-bit ECN mark 143 in received packets, indicating for each packet whether it is 144 marked not-ECT, ECT(0), ECT(1), or ECN-CE. If the path on which 145 the media traffic traversing is ECN capable then the sender can 146 use the Congestion Experienced (ECN-CE) marking information for 147 congestion control. It is important that the receiver sends the 148 ECN-CE marking information of the packet back to the sender to 149 take the advantages of ECN marking. Note that how the receiver 150 gets the ECN marking information at application layer is out of 151 the scope of this design team. Additional information for ECN use 152 with RTP can be found at [RFC6679]. 154 The feedback messages can have one or more of the above information 155 blocks. For RTCP based feedback message the packet information block 156 will be grouped by Synchronization Source (SSRC) identifier. 158 As a practical matter, we note that host Operating System (OS) 159 process interruptions can occur at inopportune times. Thus, the 160 recording of the sent times at the sender and arrival times at the 161 receiver should be made with deliberate care. This is because the 162 time duration of host OS interruptions can be significant relative to 163 the precision desired in the one-way delay estimates. Specifically, 164 the send time should be recorded at the latest opportunity prior to 165 outputting the media packet at the sender (e.g., socket or RTP API) 166 and the arrival time at the receiver (e.g., socket or RTP API) should 167 be recorded at the earliest opportunity available to the receiver. 169 3.1. RTCP XR Block for Reporting Congestion Control Feedback 171 Congestion control feedback can be sent as part of a scheduled RTCP 172 report, or as RTP/AVPF early feedback. If sent as part of a 173 scheduled RTCP report, the feedback is sent as an XR block, as part 174 of a regular compound RTCP packet. The format of the RTCP XR report 175 block is as follows (this will be preceded in the compound RTCP 176 packet by an RTCP XR header, described in [RFC3611], that includes 177 the SSRC of the report sender): 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | BT=RC2F | Report count | Block Length = TBD | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Report Timestamp (32bits) | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | SSRC of 1st media source | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | begin_seq | end_seq | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 |L|ECN| Arrival time offset | ... . 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 . . 193 . . 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | SSRC of nth media source | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | begin_seq | end_seq | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |L|ECN| Arrival time offset | ... | 200 . . 201 . . 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 The XR Discard RLE report block uses the same format as specified for 205 the loss and duplicate report blocks in [RFC3611]. The fields "block 206 length", "begin_seq", and "end_seq" have the same semantics and 207 representation as defined in [RFC3611] 209 Block Type (BT, 8 bits): The RMCAT congestion control feedback Report 210 Block is identified by the constant RC2F. [Note to RFC Editor: 211 Please replace RC2F with the IANA provided RTCP XR block type for 212 this block.] 214 Report Count (8 bits): field describes the number of SSRCs reported 215 by this report block. The number should at least be 1. 217 Report Timestamp (RTS, 32 bits): represents the timestamp when this 218 report was generated. The sender of the feedback message decides on 219 the wall-clock. Usually, it should be derived from the same wall- 220 clock that is used for timestamping RTP packets arrival . Consistency 221 in the unit and resolution (10th of millisecond should be good enough 222 ) is important here. In addition, the media sender can ask for a 223 specific resolution it wants. 225 Each sequence number between the begin_seq and end_seq (both 226 inclusive) is represented by a packet metric block of 16-bits that 227 contains the L, ECN, and ATO metrics. If an odd number of reports 228 are included, i.e., end_seq - begin_seq is odd then it should be 229 rounded up to four (4) bytes boundary. [FIXME : the solution will 230 depend on the compression used (if any), revisit this if packet 231 format is changed later] 233 L (1 bit): is a boolean to indicate if the packet was received. 0 234 represents that the packet was not yet received and all the 235 subsequent bits (ECN and ATO) are also set to 0. 1 represent the 236 packet was received and the subsequent bits in the block need to be 237 parsed. 239 ECN (2 bits): is the echoed ECN mark of the packet (00 if not 240 received or if ECN is not used). 242 Arrival time offset (ATO, 13 bits): it the relative arrival time of 243 the RTP packets at the receiver before this feedback report was 244 generated measured in milliseconds. It is calculated by subtracting 245 the reception timestamp of the RTP packet denoted by this 16bit block 246 and the timestamp (RTS) of this report. 248 [FIXME: should reserve 0xFFF to mean anything greater than 0xFFE? 249 This needs to wait until we have fixed the packet format ] 251 3.2. RTP/AVPF Transport Layer Feedback for Congestion Control 253 Congestion control feedback can also be sent in a non-compound RTCP 254 packet [RFC5506] if the RTP/AVPF profile [RFC4585] or the RTP/SAVPF 255 profile [RFC5124] is used. In this case, the congestion control 256 feedback is sent as a Transport Layer FB message (RTCP packet type 257 205), with FMT=2 (congestion control feedback). The format of this 258 RTCP packet is as follows: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |V=2|P| FMT = 2 | PT = 205 | length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | SSRC of packet sender | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | SSRC of 1st media source | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | begin_seq | end_seq | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 |L|ECN| Arrival time offset | ... . 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 . . 274 . . 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | SSRC of nth media source | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | begin_seq | end_seq | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |L|ECN| Arrival time offset | ... | 281 . . 282 . . 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Report Timestamp (32bits) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 The first 8 octets are the RTCP header, with PT=205 and FMT=2 288 specifying the remainder is a congestion control feedback packet, and 289 including the SSRC of the packet sender. 291 Section 6.1 of [RFC4585] requires this is followed by the SSRC of the 292 media source being reported upon. Accordingly, the format of the 293 report is changed from that of the RTCP XR report block, to move the 294 timestamp to the end. The meaning of all the fields is a described 295 in Section 3.1. 297 4. Feedback Frequency and Overhead 299 There is a trade-off between speed and accuracy of reporting, and the 300 overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses 301 this trade-off, and the possible rates of feedback. 303 It is a general understanding that the congestion control algorithms 304 will work better with more frequent feedback - per packet feedback. 305 However, RTCP bandwidth and transmission rules put some upper limits 306 on how frequently the RTCP feedback messages can be send from the 307 media receiver to the media sender. It has been shown 308 [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame 309 feedback is a reasonable assumption on how frequent the RTCP feedback 310 messages can be transmitted. The design team also have noted that 311 even if a higher frequency of feedback is desired it is not viable if 312 the feedback messages starts to compete against the media traffic on 313 the feedback path during congestion period. Analyzing the feedback 314 interval requirement [feedback-requirements] it can be seen that the 315 candidate algorithms can perform with a feedback interval range of 316 50-200ms. A value within this range need to be negotiated at session 317 setup. 319 5. Design Rationale 321 The primary function of RTCP Sender Report (SR) / Receiver Report 322 (RR) is to report the reception quality of media. The regular SR / 323 RR reports contain information about observed jitter, fractional 324 packet loss and cumulative packet loss. The original intent of this 325 information was to assist flow and congestion control mechanisms. 326 Even though it is possible to do congestion control based on 327 information provided in the SR/RR reports it is not sufficient to 328 design an efficient congestion control algorithm for interactive 329 real-time communication. An efficient congestion control algorithm 330 requires more fine grain information on per packet (see Section 3) to 331 react to the congestion or to avoid funder congestion on the path. 333 Codec Control Message for AVPF [RFC5104] defines Temporary Maximum 334 Media Bit Rate (TMMBR) message which conveys a temporary maximum 335 bitrate limitation from the receiver of the media to the sender of 336 the media. Even though it is not designed to replace congestion 337 control, TMMBR has been used as a means to do receiver based 338 congestion control where the session bandwidth is high enough to send 339 frequent TMMBR messages especially with reduced sized reports 340 [RFC5506]. This requires the receiver of the media to analyze the 341 data reception, detect congestion level and recommend a maximum 342 bitrate suitable for current available bandwidth on the path with an 343 assumption that the sender of the media always honors the TMMBR 344 message. This requirement is completely opposite of the sender based 345 congestion control approach. Hence, TMMBR cannot be as a signaling 346 means for a sender based congestion control mechanism. However, 347 TMMBR should be viewed a complimentary signaling mechanism to 348 establish receiver's current view of acceptable maximum bitrate which 349 a sender based congestion control should honor. 351 There are number of RTCP eXtended Report (XR) blocks have been 352 defined for reporting of delay, loss and ECN marking. It is possible 353 to combine several XR blocks to report the loss and ECN marking at 354 the cost of overhead and complexity. However, there is no existing 355 RTCP XR block to report packet arrival time. 357 Considering the issues discussed here it is rational to design a new 358 congestion control feedback signaling mechanism for sender based 359 congestion control algorithm. 361 6. Acknowledgements 363 This document is an outcome of RMCAT design team discussion. We 364 would like to thank all participants specially Xiaoquing Zhu, Stefan 365 Holmer, David, Ingemar Johansson and Randell Jesup for their valuable 366 contribution to the discussions and to the document. 368 7. IANA Considerations 370 7.1. RTP/AVPF Transport Layer Feedback Message 372 TBD 374 7.2. RTCP XR Report Blocks 376 TBD 378 8. Security Considerations 380 There is a risk of causing congestion if an on-path attacker modifies 381 the feedback messages in such a manner to make available bandwidth 382 greater than it is in reality. [More on security consideration TBD.] 384 9. References 386 9.1. Normative References 388 [I-D.ietf-rmcat-rtp-cc-feedback] 389 Perkins, C., "RTP Control Protocol (RTCP) Feedback for 390 Congestion Control in Interactive Multimedia Conferences", 391 draft-ietf-rmcat-rtp-cc-feedback-03 (work in progress), 392 November 2016. 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 400 of Explicit Congestion Notification (ECN) to IP", 401 RFC 3168, DOI 10.17487/RFC3168, September 2001, 402 . 404 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 405 Jacobson, "RTP: A Transport Protocol for Real-Time 406 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 407 July 2003, . 409 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 410 Video Conferences with Minimal Control", STD 65, RFC 3551, 411 DOI 10.17487/RFC3551, July 2003, 412 . 414 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 415 "RTP Control Protocol Extended Reports (RTCP XR)", 416 RFC 3611, DOI 10.17487/RFC3611, November 2003, 417 . 419 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 420 "Extended RTP Profile for Real-time Transport Control 421 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 422 DOI 10.17487/RFC4585, July 2006, 423 . 425 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 426 Real-time Transport Control Protocol (RTCP)-Based Feedback 427 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 428 2008, . 430 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 431 Real-Time Transport Control Protocol (RTCP): Opportunities 432 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 433 2009, . 435 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 436 and K. Carlberg, "Explicit Congestion Notification (ECN) 437 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 438 2012, . 440 9.2. Informative References 442 [feedback-requirements] 443 "RMCAT Feedback Requirements", 444 <://www.ietf.org/proceedings/95/slides/slides-95-rmcat- 445 1.pdf>. 447 [I-D.ietf-rmcat-gcc] 448 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 449 Mascolo, "A Google Congestion Control Algorithm for Real- 450 Time Communication", draft-ietf-rmcat-gcc-02 (work in 451 progress), July 2016. 453 [I-D.ietf-rmcat-nada] 454 Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, 455 J., and S. D'Aronco, "NADA: A Unified Congestion Control 456 Scheme for Real-Time Media", draft-ietf-rmcat-nada-04 457 (work in progress), March 2017. 459 [I-D.ietf-rmcat-sbd] 460 Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared 461 Bottleneck Detection for Coupled Congestion Control for 462 RTP Media.", draft-ietf-rmcat-sbd-06 (work in progress), 463 February 2017. 465 [I-D.ietf-rmcat-scream-cc] 466 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 467 for Multimedia", draft-ietf-rmcat-scream-cc-07 (work in 468 progress), November 2016. 470 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 471 "Codec Control Messages in the RTP Audio-Visual Profile 472 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 473 February 2008, . 475 Authors' Addresses 477 Zaheduzzaman Sarker 478 Ericsson AB 479 Luleae 480 Sweden 482 Phone: +46107173743 483 Email: zaheduzzaman.sarker@ericsson.com 485 Colin Perkins 486 University of Glasgow 487 School of Computing Science 488 Glasgow G12 8QQ 489 United Kingdom 491 Email: csp@csperkins.org 492 Varun Singh 493 Nemu Dialogue Systems Oy 494 Runeberginkatu 4c A 4 495 Helsinki 00100 496 Finland 498 Email: varun.singh@iki.fi 499 URI: http://www.callstats.io/ 501 Michael A. Ramalho 502 Cisco Systems, Inc. 503 6310 Watercrest Way Unit 203 504 Lakewood Ranch, FL 34202 505 USA 507 Phone: +1 919 476 2038 508 Email: mramalho@cisco.com