idnits 2.17.1 draft-ietf-rmcat-cc-codec-interactions-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. 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 (September 17, 2015) is 3137 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) == Unused Reference: 'I-D.ietf-mmusic-sdp-bundle-negotiation' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC5450' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC5506' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC5761' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC2818' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 500, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental draft: draft-alvestrand-rmcat-remb (ref. 'I-D.alvestrand-rmcat-remb') == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-10 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-23 ** Downref: Normative reference to an Informational draft: draft-ietf-rmcat-cc-requirements (ref. 'I-D.ietf-rmcat-cc-requirements') ** Downref: Normative reference to an Experimental draft: draft-welzl-rmcat-coupled-cc (ref. 'I-D.welzl-rmcat-coupled-cc') ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Zanaty 3 Internet-Draft Cisco 4 Intended status: Standards Track V. Singh 5 Expires: March 20, 2016 Aalto University 6 S. Nandakumar 7 Cisco 8 Z. Sarkar 9 Ericsson AB 10 September 17, 2015 12 Congestion Control and Codec interactions in RTP Applications 13 draft-ietf-rmcat-cc-codec-interactions-00 15 Abstract 17 Interactive real-time media applications that use the Real-time 18 Transport Protocol (RTP) over the User Datagram Protocol (UDP) must 19 use congestion control techniques above the UDP layer since it 20 provides none. This memo describes the interactions and conceptual 21 interfaces necessary between the application components that relate 22 to congestion control, specifically the media codec control layer, 23 and the components dedicated to congestion control functions. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 20, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 3 61 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Implementation Model . . . . . . . . . . . . . . . . . . . . 5 63 5. Codec - CC Interactions . . . . . . . . . . . . . . . . . . . 6 64 5.1. Allowed Rate . . . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Media Elasticity . . . . . . . . . . . . . . . . . . . . 7 66 5.3. Startup Ramp . . . . . . . . . . . . . . . . . . . . . . 7 67 5.4. Delay Tolerance . . . . . . . . . . . . . . . . . . . . . 7 68 5.5. Loss Tolerance . . . . . . . . . . . . . . . . . . . . . 8 69 5.6. Forward Error Correction . . . . . . . . . . . . . . . . 8 70 5.7. Probing for Available Bandwidth . . . . . . . . . . . . . 8 71 5.8. Throughput Sensitivity . . . . . . . . . . . . . . . . . 8 72 5.9. Rate Stability . . . . . . . . . . . . . . . . . . . . . 8 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 8.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Interactive real-time media applications most commonly use RTP 83 [RFC3550] over UDP [RFC0768]. Since UDP provides no form of 84 congestion control, which is essential for any application deployed 85 on the Internet, these RTP applications have historically implemented 86 one of the following options at the application layer to address 87 their congestion control requirements. 89 o For media with relatively low packet rates and bit rates, such as 90 many speech codecs, some applications use a simple form of 91 congestion control that stops transmission permanently or 92 temporarily after observing significant packet loss over a 93 significant period of time, similar to the RTP circuit breakers 94 [I-D.ietf-avtcore-rtp-circuit-breakers]. 96 o Some applications have no explicit congestion control, despite the 97 clear requirements in RTP and its profiles AVP [RFC3551] and AVPF 98 [RFC4585], under the expectation that users will terminate media 99 flows that are significantly impaired by congestion (in essence, 100 human circuit breakers). 102 o For media with substantially higher packet rates and bit rates, 103 such as many video codecs, various non-standard congestion control 104 techniques are often used to adapt transmission rate based on 105 receiver feedback. 107 o Some experimental applications use standardized techniques such as 108 TCP-Friendly Rate Control (TFRC) [RFC5348]. However, for various 109 reasons, these have not been widely deployed. 111 The RTP Media Congestion Avoidance Techniques (RMCAT) working group 112 was chartered to standardize appropriate and effective congestion 113 control for RTP applications. It is expected such applications will 114 migrate from the above historical solutions to the RMCAT solution(s). 116 The RMCAT requirements [I-D.ietf-rmcat-cc-requirements] include low 117 delay, reasonably high throughput, fast reaction to capacity changes 118 including routing or interface changes, stability without over- 119 reaction or oscillation, fair bandwidth sharing with other instances 120 of itself and TCP flows, sharing information across multiple flows 121 when possible [I-D.welzl-rmcat-coupled-cc], and performing as well or 122 better in networks which support Active Queue Management (AQM), 123 Explicit Congestion Notification (ECN), or Differentiated Services 124 Code Points (DSCP). 126 In order to meet these requirements, interactions are necessary 127 between the application's congestion controller, the RTP layer, media 128 codecs, other components, and the underlying UDP/IP network stack. 129 This memo attempts to present a conceptual model of the various 130 interfaces based on a simplified application decomposition. This 131 memo discusses interactions between the congestion control and codec 132 control layer in a typical RTP Application. 134 Note that RTP can also operate over other transports with integrated 135 congestion control such as TCP [RFC5681] and DCCP [RFC4340], but that 136 is beyond the scope of RMCAT and this memo. 138 2. Key Words for Requirements 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Conceptual Model 146 It is useful to decompose an RTP application into several components 147 to facilitate understanding and discussion of where congestion 148 control functions operate, and how they interface with the other 149 components. The conceptual model in Figure 1 consists of the 150 following components. 152 +----------------------------+ 153 | +-----Config-----+ | 154 | | | | | 155 | | Codec | | 156 | | | | | | | 157 | APP +---RTP | RTCP---+ | 158 | | | | | | 159 | | | | | | 160 | +---Congestion-------|---Shared 161 | Control | State 162 +----------------------------+ 163 | 164 +----------------------------+ 165 | Network UDP | 166 | Stack | | 167 | IP | 168 +----------------------------+ 170 Figure 1 172 o APP: Application containing one or more RTP streams and the 173 corresponding media codecs and congestion controllers. For 174 example, a WebRTC browser. 176 o Config: Configuration specified by the application that provides 177 the media and transport parameters, RTP and RTCP parameters and 178 extensions, and congestion control parameters. For example, a 179 WebRTC Javascript application may use the 'constraints' API to 180 affect the media configuration, and SDP applications may negotiate 181 the media and transport parameters with the remote peer. This 182 determines the initial static configuration negotiated in session 183 establishment. The dynamic state may differ due to congestion or 184 other factors, but still must conform to limits established in the 185 config. 187 o Codec: Media encoder/decoder or other source/sink for the RTP 188 payload. The codec may be, for example, a simple monaural audio 189 format, a complex scalable video codec with several dependent 190 layers, or a source/sink with no live encoding/decoding such as a 191 mixer which selectively switches and forwards streams rather than 192 mixes media. 194 o RTP: Standard RTP stack functions, including media packetization / 195 de-packetization and header processing, but excluding existing 196 extensions and possible new extensions specific to congestion 197 control (CC) such as absolute timestamps or relative transmission 198 time offsets in RTP header extensions. RTCP: Standard RTCP 199 functions, including sender reports, receiver reports, extended 200 reports, circuit breakers [I-D.ietf-avtcore-rtp-circuit-breakers], 201 feedback messages such as NACK [RFC4585] and codec control 202 messages such as TMMBR [RFC5104], but excluding existing 203 extensions and possible new extensions specific to congestion 204 control (CC) such as REMB [I-D.alvestrand-rmcat-remb] (for 205 receiver-side CC), ACK (for sender-side CC), absolute and/or 206 relative timestamps (for sender-side or receiver-side CC), etc. 208 o Congestion Control: All functions directly responsible for 209 congestion control, including possible new RTP/RTCP extensions, 210 send rate computation (for sender-side CC), receive rate 211 computation (for receiver-side CC), other statistics, and control 212 of the UDP sockets including packet scheduling for traffic 213 shaping/pacing. 215 o Shared State: Storage and exchange of congestion control state for 216 multiple flows within the application and beyond it. 218 o Network Stack: The platform's underlying network functions, 219 usually part of the Operating System (OS), containing the UDP 220 socket interface and other network functions such as ECN, DSCP, 221 physical interface events, interface-level traffic shaping and 222 packet scheduling, etc. This is usually part of the Operating 223 System, often within the kernel; however, user-space network 224 stacks and components are also possible. 226 4. Implementation Model 228 There are advantages and drawbacks to implementing congestion control 229 in the application layer. It avoids platform dependencies and allows 230 for rapid experimentation, evolution and optimization for each 231 application. However, it also puts the burden on all applications, 232 which raises the risks of improper or divergent implementations. One 233 motivation of this memo is to mitigate such risks by giving proper 234 guidance on how the application components relating to congestion 235 control should interact. 237 Another drawback of congestion control in the application layer is 238 that any decomposition, including the one presented in Figure 1, is 239 purely conceptual and illustrative, since implementations have 240 differing designs and decompositions. Conversely, this can be viewed 241 as an advantage to distribute congestion control functions wherever 242 expedient without rigid interfaces. For example, they may be 243 distributed within the RTP/RTCP stack itself, so the separate 244 components in Figure 1 are combined into a single RTP+RTCP+CC 245 component as shown in Figure 2. 247 +----------------------------+ 248 | +-----Config | 249 | | | | 250 | | Codec | 251 | APP | | | 252 | +---RTP+RTCP+CC------|---Shared 253 +----------------------------+ State 254 | 255 +----------------------------+ 256 | Network UDP | 257 | Stack | | 258 | IP | 259 +----------------------------+ 261 Figure 2 263 5. Codec - CC Interactions 265 The following subsections identify the necessary interactions between 266 the Codec and congestion control layer interfaces that needs to be 267 considered important 269 5.1. Allowed Rate 271 Allowed Rate (from CC to Codec): The max transmit rate allowed over 272 the next time interval. The time interval may be specified or may 273 use a default. The rate may be specified in bytes or packets or 274 both. The rate must never exceed permanent limits established in 275 session signaling such as the SDP bandwidth attribute [RFC4566] nor 276 temporary limits in RTCP such as TMMBR [RFC5104] or REMB 277 [I-D.alvestrand-rmcat-remb]. This is the most important interface 278 among all components, and is always required in any RMCAT solution. 279 In the simplest possible solution, it may be the only CC interface 280 required. 282 5.2. Media Elasticity 284 Media Elasticity (from Codec to CC): Many live media encoders are 285 highly elastic, often able to achieve any target bit rate within a 286 wide range, by adapting the media quality. For example, a video 287 encoder may support any bit rate within a range of a few tens or 288 hundreds of kbps up to several Mbps, with rate changes registering as 289 fast as the next video frame, although there may be limitations in 290 the frequency of changes. Other encoders may be less elastic, 291 supporting a narrower rate range, coarser granularity of rate steps, 292 slower reaction to rate changes, etc. Other media, particularly some 293 audio codecs, may be fully inelastic with a single fixed rate. CC 294 can beneficially use codec elasticity, if provided, to plan Allowed 295 Rate changes, especially when there are multiple flows sharing CC 296 state and bandwidth. 298 5.3. Startup Ramp 300 Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an 301 important moment in a conversation. Rapid rate adaptation during 302 startup is therefore important. The codec should minimize its 303 startup media rate as much as possible without adversely impacting 304 the user experience, and support a strategy for rapid rate ramp. The 305 CC should allow the highest startup media rate as possible without 306 adversely impacting network conditions, and also support rapid rate 307 ramp until stabilizing on the available bandwidth. Startup can be 308 viewed as a negotiation between the codec and the CC. The codec 309 requests a startup rate and ramp, and the CC responds with the 310 allowable parameters which may be lower/slower. The RMCAT 311 requirements also include the possibility of bandwidth history to 312 further accelerate or even eliminate startup ramp time. While this 313 is highly desirable from an application viewpoint, it may be less 314 acceptable to network operators, since it is in essence a gamble on 315 current congestion state matching historical state, with the 316 potential for significant congestion contribution if the gamble was 317 wrong. Note that startup can often commence before user interaction 318 or conversation to reduce the chance of clipped media. 320 5.4. Delay Tolerance 322 Delay Tolerance (from Codec to CC): An ideal CC will always minimize 323 delay and target zero. However, real solutions often need a real 324 non-zero delay tolerance. The codec should provide an absolute delay 325 tolerance, perhaps expressed as an impairment factor to mix with 326 other metrics. 328 5.5. Loss Tolerance 330 Loss Tolerance (from Codec to CC): An ideal CC will always minimize 331 packet loss and target zero. However, real solutions often need a 332 real non-zero loss tolerance. The codec should provide an absolute 333 loss tolerance, perhaps expressed as an impairment factor to mix with 334 other metrics. Note this is unrecoverable post-repair loss after 335 retransmission or forward error correction. 337 5.6. Forward Error Correction 339 Forward Error Correction (FEC): Simple FEC schemes like XOR Parity 340 codes [RFC5109] may not handle consecutive or burst loss well. More 341 complex FEC schemes like Reed-Solomon [RFC6865] or Raptor [RFC6330] 342 codes are more effective at handling bursty loss. The sensitivity to 343 packet loss therefore depends on the media (source) encoding as well 344 as the FEC (channel) encoding, and this sensitivity may differ for 345 different loss patterns like random, periodic, or consecutive loss. 346 Expressing this sensitivity to the congestion controller may help it 347 choose the right balance between optimizing for throughput versus low 348 loss. 350 5.7. Probing for Available Bandwidth 352 FEC can also be used to probe for additional available bandwidth, if 353 the application desires a higher target rate than the current rate. 354 FEC is preferable to synthetic probes since any contribution to 355 congestion by the FEC probe will not impact the post-repair loss rate 356 of the source media flow while synthetic probes may adversely affect 357 the loss rate. Note that any use of FEC or retransmission must 358 ensure that the total flow of all packets including FEC, 359 retransmission and original media never exceeds the Allowed Rate. 361 5.8. Throughput Sensitivity 363 Throughput Sensitivity (from Codec to CC): An ideal CC will always 364 maximize throughput. However, real solutions often need a trade-off 365 between throughput and other metrics such as delay or loss. The 366 codec should provide throughput sensitivity, perhaps expressed as an 367 impairment factor (for low throughputs) to mix with other metrics. 369 5.9. Rate Stability 371 Rate Stability (from Codec to CC): The CC algorithm must strike a 372 balance between rate stability and fast reaction to changes in 373 available bandwidth. The codec should provide its preference for 374 rate stability versus fast and frequent reaction to rate changes, 375 perhaps expressed as an impairment factor (for high rate variance 376 over short timescales) to mix with other metrics. 378 6. Acknowledgements 380 The RMCAT design team discussions contributed to this memo. 382 7. IANA Considerations 384 This memo includes no request to IANA. 386 8. References 388 8.1. Normative References 390 [I-D.alvestrand-rmcat-remb] 391 Alvestrand, H., "RTCP message for Receiver Estimated 392 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 393 progress), October 2013. 395 [I-D.ietf-avtcore-rtp-circuit-breakers] 396 Perkins, C. and V. Singh, "Multimedia Congestion Control: 397 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 398 avtcore-rtp-circuit-breakers-10 (work in progress), March 399 2015. 401 [I-D.ietf-mmusic-sdp-bundle-negotiation] 402 Holmberg, C., Alvestrand, H., and C. Jennings, 403 "Negotiating Media Multiplexing Using the Session 404 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 405 negotiation-23 (work in progress), July 2015. 407 [I-D.ietf-rmcat-cc-requirements] 408 Jesup, R. and Z. Sarker, "Congestion Control Requirements 409 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 410 requirements-09 (work in progress), December 2014. 412 [I-D.welzl-rmcat-coupled-cc] 413 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 414 control for RTP media", draft-welzl-rmcat-coupled-cc-05 415 (work in progress), June 2015. 417 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 418 10.17487/RFC0768, August 1980, 419 . 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 423 RFC2119, March 1997, 424 . 426 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 427 Jacobson, "RTP: A Transport Protocol for Real-Time 428 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 429 July 2003, . 431 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 432 Video Conferences with Minimal Control", STD 65, RFC 3551, 433 DOI 10.17487/RFC3551, July 2003, 434 . 436 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 437 Congestion Control Protocol (DCCP)", RFC 4340, DOI 438 10.17487/RFC4340, March 2006, 439 . 441 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 442 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 443 July 2006, . 445 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 446 "Extended RTP Profile for Real-time Transport Control 447 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 448 10.17487/RFC4585, July 2006, 449 . 451 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 452 "Codec Control Messages in the RTP Audio-Visual Profile 453 with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, 454 February 2008, . 456 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 457 Correction", RFC 5109, DOI 10.17487/RFC5109, December 458 2007, . 460 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 461 Friendly Rate Control (TFRC): Protocol Specification", RFC 462 5348, DOI 10.17487/RFC5348, September 2008, 463 . 465 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 466 RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009, 467 . 469 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 470 Real-Time Transport Control Protocol (RTCP): Opportunities 471 and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 472 2009, . 474 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 475 Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, 476 . 478 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 479 Control Packets on a Single Port", RFC 5761, DOI 10.17487/ 480 RFC5761, April 2010, 481 . 483 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 484 and L. Minder, "RaptorQ Forward Error Correction Scheme 485 for Object Delivery", RFC 6330, DOI 10.17487/RFC6330, 486 August 2011, . 488 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 489 Matsuzono, "Simple Reed-Solomon Forward Error Correction 490 (FEC) Scheme for FECFRAME", RFC 6865, DOI 10.17487/ 491 RFC6865, February 2013, 492 . 494 8.2. Informative References 496 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 497 RFC2818, May 2000, 498 . 500 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 501 Text on Security Considerations", BCP 72, RFC 3552, DOI 502 10.17487/RFC3552, July 2003, 503 . 505 Authors' Addresses 507 Mo Zanaty 508 Cisco 510 Email: mzanaty@cisco.com 512 Varun Singh 513 Aalto University 515 Email: varun@comnet.tkk.fi 516 Suhas Nandakumar 517 Cisco 519 Email: snandaku@cisco.com 521 Zaheduzzaman Sarker 522 Ericsson AB 524 Email: zaheduzzaman.sarker@ericsson.com