idnits 2.17.1 draft-ietf-avtcore-cc-feedback-message-00.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 (October 30, 2017) is 2370 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-05 == Outdated reference: A later version (-11) exists of draft-ietf-rmcat-sbd-08 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: May 3, 2018 University of Glasgow 6 V. Singh 7 callstats.io 8 M. Ramalho 9 Cisco Systems 10 October 30, 2017 12 RTP Control Protocol (RTCP) Feedback for Congestion Control 13 draft-ietf-avtcore-cc-feedback-message-00 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 https://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 May 3, 2018. 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 (https://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 Congestion Control Feedback Report . . . . . . . . . 4 65 4. Feedback Frequency and Overhead . . . . . . . . . . . . . . . 6 66 5. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 9.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 For interactive real-time traffic the typical protocol choice is 78 Realtime Transport Protocol (RTP) over User Datagram Protocol (UDP). 79 RTP does not provide any guarantee of Quality of Service (QoS), 80 reliable or timely delivery and expects the underlying transport 81 protocol to do so. UDP alone certainly does not meet that 82 expectation. However, RTP Control Protocol (RTCP) provides a 83 mechanism to periodically send transport and media metrics to the 84 media sender which can be utilized and extended for the purposes of 85 RMCAT congestion control. For a congestion control algorithm which 86 operates at the media sender, RTCP messages can be transmitted from 87 the media receiver back to the media sender to enable congestion 88 control. In the absence of standardized messages for this purpose, 89 the congestion control algorithm designers have designed proprietary 90 RTCP messages that convey only those parameters required for their 91 respective designs. As a direct result, the different congestion 92 control (a.k.a. rate adaptation) designs are not interoperable. To 93 enable algorithm evolution as well as interoperability across designs 94 (e.g., different rate adaptation algorithms), it is highly desirable 95 to have generic congestion control feedback format. 97 To help achieve interoperability for unicast RTP congestion control, 98 this memo proposes a common RTCP feedback format that can be used by 99 NADA [I-D.ietf-rmcat-nada], SCReAM [I-D.ietf-rmcat-scream-cc], Google 100 Congestion Control [I-D.ietf-rmcat-gcc] and Shared Bottleneck 101 Detection [I-D.ietf-rmcat-sbd], and hopefully future RTP congestion 102 control algorithms as well. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 In addition the terminology defined in [RFC3550], [RFC3551], 111 [RFC3611], [RFC4585], and [RFC5506] applies. 113 3. Feedback Message 115 The design team analyzed the feedback requirements from the different 116 proposed candidate in RMCAT WG. The analysis showed some 117 commonalities between the proposed solution candidate and some can be 118 derived from other information. The design team has agreed to have 119 following packet information block in the feedback message to satisfy 120 different requirement analyzed. 122 o Packet Identifier : RTP sequence number. The RTP packet header 123 includes an incremental packet sequence number that the sender 124 needs to correlate packets sent at the sender with packets 125 received at the receiver. 127 o Packet Arrival Time : Arrival time stamp at the receiver of the 128 media. The sender requires the arrival time stamp of the 129 respective packet to determine delay and jitter the packet had 130 experienced during transmission. In a sender based congestion 131 control solution the sender requires to keep track of the sent 132 packets - usually packet sequence number, packet size and packet 133 send time. With the packet arrival time the sender can detect the 134 delay and jitter information. Along with packet loss and delay 135 information the sender can estimate the available bandwidth and 136 thus adapt to the situation. 138 o Packet Explicit Congestion Notification (ECN) Marking : If ECN 139 [RFC3168] is used, it is necessary to report on the 2-bit ECN mark 140 in received packets, indicating for each packet whether it is 141 marked not-ECT, ECT(0), ECT(1), or ECN-CE. If the path on which 142 the media traffic traversing is ECN capable then the sender can 143 use the Congestion Experienced (ECN-CE) marking information for 144 congestion control. It is important that the receiver sends the 145 ECN-CE marking information of the packet back to the sender to 146 take the advantages of ECN marking. Note that how the receiver 147 gets the ECN marking information at application layer is out of 148 the scope of this design team. Additional information for ECN use 149 with RTP can be found at [RFC6679]. 151 The feedback messages can have one or more of the above information 152 blocks. For RTCP based feedback message the packet information block 153 will be grouped by Synchronization Source (SSRC) identifier. 155 As a practical matter, we note that host Operating System (OS) 156 process interruptions can occur at inopportune times. Thus, the 157 recording of the sent times at the sender and arrival times at the 158 receiver should be made with deliberate care. This is because the 159 time duration of host OS interruptions can be significant relative to 160 the precision desired in the one-way delay estimates. Specifically, 161 the send time should be recorded at the latest opportunity prior to 162 outputting the media packet at the sender (e.g., socket or RTP API) 163 and the arrival time at the receiver (e.g., socket or RTP API) should 164 be recorded at the earliest opportunity available to the receiver. 166 3.1. RTCP Congestion Control Feedback Report 168 Congestion control feedback can be sent as part of a regular 169 scheduled RTCP report, or in an RTP/AVPF early feedback packet. If 170 sent as early feedback, congestion control feedback MAY be sent in a 171 non-compound RTCP packet [RFC5506] if the RTP/AVPF profile [RFC4585] 172 or the RTP/SAVPF profile [RFC5124] is used. 174 Irrespective of how it is transported, the congestion control 175 feedback is sent as a Transport Layer Feedback Message (RTCP packet 176 type 205). The format of this RTCP packet is as follows: 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |V=2|P| FMT=CCFB | PT = 205 | length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | SSRC of packet sender | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | SSRC of 1st media source | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | begin_seq | end_seq | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |L|ECN| Arrival time offset | ... . 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Report Timestamp (32bits) | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 The first 8 octets are the RTCP header, with PT=205 and FMT=CCFB 207 specifying the remainder is a congestion control feedback packet, and 208 including the SSRC of the packet sender. (NOTE TO RFC EDITOR: please 209 replace CCFB here and in the above diagram with the IANA assigned 210 RTCP feedback packet type) 212 Section 6.1 of [RFC4585] requires the RTCP header to be followed by 213 the SSRC of the media source being reported upon. Accordingly, the 214 RTCP header is followed by a report for each SSRC received, followed 215 by the Report Timestamp. 217 The report for each SSRC received starts with the SSRC of that media 218 source. Then, each sequence number between the begin_seq and end_seq 219 (both inclusive) is represented by a packet metric block of 16-bits 220 that contains the L, ECN, and ATO fields. If an odd number of 221 reports are included, i.e., end_seq - begin_seq is odd then 16 bits 222 of zero padding MUST be added after the last report, to align the 223 RTCP packet to a four (4) bytes boundary. The L, ECN, and ATO fields 224 are as follows: 226 o L (1 bit): is a boolean to indicate if the packet was received. 0 227 represents that the packet was not yet received and all the 228 subsequent bits (ECN and ATO) are also set to 0. 1 represent the 229 packet was received and the subsequent bits in the block need to 230 be parsed. 232 o ECN (2 bits): is the echoed ECN mark of the packet. These are set 233 to 00 if not received, or if ECN is not used. 235 o Arrival time offset (ATO, 13 bits): is the relative arrival time 236 of the RTP packets at the receiver before this feedback report was 237 generated measured in milliseconds. It is calculated by 238 subtracting the reception timestamp of the RTP packet denoted by 239 this 16bit block and the timestamp (RTS) of this report. If the 240 measured value is greater than 8.189 seconds (the value that would 241 be coded as 0x1FFD), the value 0x1FFE MUST be reported to indicate 242 an over-range positive measurement. If the measurement is 243 unavailable, the value 0x1FFF MUST be reported. 245 Report Timestamp (RTS, 32 bits): represents the timestamp when this 246 report was generated. The sender of the feedback message decides on 247 the wall-clock. Usually, it should be derived from the same wall- 248 clock that is used for timestamping RTP packets arrival . Consistency 249 in the unit and resolution (10th of millisecond should be good enough 250 ) is important here. In addition, the media sender can ask for a 251 specific resolution it wants. 253 4. Feedback Frequency and Overhead 255 There is a trade-off between speed and accuracy of reporting, and the 256 overhead of the reports. [I-D.ietf-rmcat-rtp-cc-feedback] discusses 257 this trade-off, and the possible rates of feedback. 259 It is a general understanding that the congestion control algorithms 260 will work better with more frequent feedback - per packet feedback. 261 However, RTCP bandwidth and transmission rules put some upper limits 262 on how frequently the RTCP feedback messages can be send from the 263 media receiver to the media sender. It has been shown 264 [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases a per frame 265 feedback is a reasonable assumption on how frequent the RTCP feedback 266 messages can be transmitted. The design team also have noted that 267 even if a higher frequency of feedback is desired it is not viable if 268 the feedback messages starts to compete against the media traffic on 269 the feedback path during congestion period. Analyzing the feedback 270 interval requirement [feedback-requirements] it can be seen that the 271 candidate algorithms can perform with a feedback interval range of 272 50-200ms. A value within this range need to be negotiated at session 273 setup. 275 5. Design Rationale 277 The primary function of RTCP Sender Report (SR) / Receiver Report 278 (RR) is to report the reception quality of media. The regular SR / 279 RR reports contain information about observed jitter, fractional 280 packet loss and cumulative packet loss. The original intent of this 281 information was to assist flow and congestion control mechanisms. 282 Even though it is possible to do congestion control based on 283 information provided in the SR/RR reports it is not sufficient to 284 design an efficient congestion control algorithm for interactive 285 real-time communication. An efficient congestion control algorithm 286 requires more fine grain information on per packet (see Section 3) to 287 react to the congestion or to avoid funder congestion on the path. 289 Codec Control Message for AVPF [RFC5104] defines Temporary Maximum 290 Media Bit Rate (TMMBR) message which conveys a temporary maximum 291 bitrate limitation from the receiver of the media to the sender of 292 the media. Even though it is not designed to replace congestion 293 control, TMMBR has been used as a means to do receiver based 294 congestion control where the session bandwidth is high enough to send 295 frequent TMMBR messages especially with reduced sized reports 296 [RFC5506]. This requires the receiver of the media to analyze the 297 data reception, detect congestion level and recommend a maximum 298 bitrate suitable for current available bandwidth on the path with an 299 assumption that the sender of the media always honors the TMMBR 300 message. This requirement is completely opposite of the sender based 301 congestion control approach. Hence, TMMBR cannot be as a signaling 302 means for a sender based congestion control mechanism. However, 303 TMMBR should be viewed a complimentary signaling mechanism to 304 establish receiver's current view of acceptable maximum bitrate which 305 a sender based congestion control should honor. 307 There are number of RTCP eXtended Report (XR) blocks have been 308 defined for reporting of delay, loss and ECN marking. It is possible 309 to combine several XR blocks to report the loss and ECN marking at 310 the cost of overhead and complexity. However, there is no existing 311 RTCP XR block to report packet arrival time. 313 Considering the issues discussed here it is rational to design a new 314 congestion control feedback signaling mechanism for sender based 315 congestion control algorithm. 317 6. Acknowledgements 319 This document is an outcome of RMCAT design team discussion. We 320 would like to thank all participants specially Xiaoquing Zhu, Stefan 321 Holmer, David, Ingemar Johansson and Randell Jesup for their valuable 322 contribution to the discussions and to the document. 324 7. IANA Considerations 326 IANA is requested to assign a new value in the "FMT Values for RTPFB 327 Payload Types" registry for the CCFB transport layer feedback packet 328 described in Section 3.1. 330 8. Security Considerations 332 There is a risk of causing congestion if an on-path attacker modifies 333 the feedback messages in such a manner to make available bandwidth 334 greater than it is in reality. [More on security consideration TBD.] 336 9. References 338 9.1. Normative References 340 [I-D.ietf-rmcat-rtp-cc-feedback] 341 Perkins, C., "RTP Control Protocol (RTCP) Feedback for 342 Congestion Control in Interactive Multimedia Conferences", 343 draft-ietf-rmcat-rtp-cc-feedback-03 (work in progress), 344 November 2016. 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, 348 DOI 10.17487/RFC2119, March 1997, 349 . 351 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 352 of Explicit Congestion Notification (ECN) to IP", 353 RFC 3168, DOI 10.17487/RFC3168, September 2001, 354 . 356 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 357 Jacobson, "RTP: A Transport Protocol for Real-Time 358 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 359 July 2003, . 361 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 362 Video Conferences with Minimal Control", STD 65, RFC 3551, 363 DOI 10.17487/RFC3551, July 2003, 364 . 366 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 367 "RTP Control Protocol Extended Reports (RTCP XR)", 368 RFC 3611, DOI 10.17487/RFC3611, November 2003, 369 . 371 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 372 "Extended RTP Profile for Real-time Transport Control 373 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 374 DOI 10.17487/RFC4585, July 2006, 375 . 377 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 378 Real-time Transport Control Protocol (RTCP)-Based Feedback 379 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 380 2008, . 382 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 383 Real-Time Transport Control Protocol (RTCP): Opportunities 384 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 385 2009, . 387 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 388 and K. Carlberg, "Explicit Congestion Notification (ECN) 389 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 390 2012, . 392 9.2. Informative References 394 [feedback-requirements] 395 "RMCAT Feedback Requirements", 396 <://www.ietf.org/proceedings/95/slides/slides-95-rmcat- 397 1.pdf>. 399 [I-D.ietf-rmcat-gcc] 400 Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. 401 Mascolo, "A Google Congestion Control Algorithm for Real- 402 Time Communication", draft-ietf-rmcat-gcc-02 (work in 403 progress), July 2016. 405 [I-D.ietf-rmcat-nada] 406 Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, 407 J., and S. D'Aronco, "NADA: A Unified Congestion Control 408 Scheme for Real-Time Media", draft-ietf-rmcat-nada-05 409 (work in progress), September 2017. 411 [I-D.ietf-rmcat-sbd] 412 Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared 413 Bottleneck Detection for Coupled Congestion Control for 414 RTP Media.", draft-ietf-rmcat-sbd-08 (work in progress), 415 July 2017. 417 [I-D.ietf-rmcat-scream-cc] 418 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 419 for Multimedia", draft-ietf-rmcat-scream-cc-13 (work in 420 progress), October 2017. 422 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 423 "Codec Control Messages in the RTP Audio-Visual Profile 424 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 425 February 2008, . 427 Authors' Addresses 429 Zaheduzzaman Sarker 430 Ericsson AB 431 Luleae 432 Sweden 434 Phone: +46107173743 435 Email: zaheduzzaman.sarker@ericsson.com 437 Colin Perkins 438 University of Glasgow 439 School of Computing Science 440 Glasgow G12 8QQ 441 United Kingdom 443 Email: csp@csperkins.org 445 Varun Singh 446 Nemu Dialogue Systems Oy 447 Runeberginkatu 4c A 4 448 Helsinki 00100 449 Finland 451 Email: varun.singh@iki.fi 452 URI: http://www.callstats.io/ 454 Michael A. Ramalho 455 Cisco Systems, Inc. 456 6310 Watercrest Way Unit 203 457 Lakewood Ranch, FL 34202 458 USA 460 Phone: +1 919 476 2038 461 Email: mramalho@cisco.com