idnits 2.17.1 draft-ietf-rmcat-app-interaction-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 7, 2014) is 3549 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-rmcat-eval-criteria' is defined on line 512, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-05 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-05 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-02 == Outdated reference: A later version (-14) exists of draft-ietf-rmcat-eval-criteria-00 == Outdated reference: A later version (-05) exists of draft-welzl-rmcat-coupled-cc-02 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMCAT WG M. Zanaty 3 Internet-Draft Cisco 4 Intended status: Informational V. Singh 5 Expires: February 8, 2015 Aalto University 6 S. Nandakumar 7 Cisco 8 Z. Sarker 9 Ericsson AB 10 August 7, 2014 12 RTP Application Interaction with Congestion Control 13 draft-ietf-rmcat-app-interaction-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, including the RTP layer, the higher-level 23 media codec control layer, and the lower-level transport interface, 24 as well as components dedicated to congestion control functions. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on February 8, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Key Words for Requirements . . . . . . . . . . . . . . . . . 3 62 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Implementation Model . . . . . . . . . . . . . . . . . . . . 5 64 5. Interfaces and Interactions . . . . . . . . . . . . . . . . . 6 65 5.1. Config - Codec Interactions . . . . . . . . . . . . . . . 6 66 5.2. Config - RTP/RTCP Interactions . . . . . . . . . . . . . 6 67 5.3. Codec - RTP Interactions . . . . . . . . . . . . . . . . 6 68 5.4. Codec - CC Interactions . . . . . . . . . . . . . . . . . 7 69 5.5. RTP - CC Interactions . . . . . . . . . . . . . . . . . . 9 70 5.6. CC - UDP Interactions . . . . . . . . . . . . . . . . . . 9 71 5.7. CC - Shared State Interactions . . . . . . . . . . . . . 10 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 1. 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 2. Some applications have no explicit congestion control, despite 97 the clear requirements in RTP and its profiles AVP [RFC3551] and 98 AVPF [RFC4585], under the expectation that users will terminate 99 media flows that are significantly impaired by congestion (in 100 essence, human circuit breakers). 102 3. For media with substantially higher packet rates and bit rates, 103 such as many video codecs, various non-standard congestion 104 control techniques are often used to adapt transmission rate 105 based on receiver feedback. 107 4. Some experimental applications use standardized techniques such 108 as TCP-Friendly Rate Control (TFRC) [RFC5348]. However, for 109 various 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 OS UDP stack. This memo discusses 129 these interactions, presents a conceptual model of the required 130 interfaces based on a simplified application decomposition, and 131 proposes specific information exchange across these interfaces along 132 with corresponding component behavior. 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 | OS UDP | 166 +----------------------------+ 168 Figure 1 170 o APP: Application containing one or more RTP streams and the 171 corresponding media codecs and congestion controllers. For 172 example, a WebRTC browser. 174 o Config: Configuration specified by the application that provides 175 the media and transport parameters, RTP and RTCP parameters and 176 extensions, and congestion control parameters. For example, a 177 WebRTC Javascript application may use the 'constraints' API to 178 affect the media configuration, and SDP applications may negotiate 179 the media and transport parameters with the remote peer. This 180 determines the initial static configuration negotiated in session 181 establishment. The dynamic state may differ due to congestion or 182 other factors, but still must conform to limits established in the 183 config. 185 o Codec: Media encoder/decoder or other source/sink for the RTP 186 payload. The codec may be, for example, a simple monaural audio 187 format, a complex scalable video codec with several dependent 188 layers, or a source/sink with no live encoding/decoding such as a 189 mixer which selectively switches and forwards streams rather than 190 mixes media. 192 o RTP: Standard RTP stack functions, including media packetization / 193 depacketization and header processing, but excluding existing 194 extensions and possible new extensions specific to congestion 195 control (CC) such as absolute timestamps or relative transmission 196 time offsets in RTP header extensions. RTCP: Standard RTCP 197 functions, including sender reports, receiver reports, extended 198 reports, circuit breakers [I-D.ietf-avtcore-rtp-circuit-breakers], 199 feedback messages such as NACK [RFC4585] and codec control 200 messages such as TMMBR [RFC5104], but excluding existing 201 extensions and possible new extensions specific to congestion 202 control (CC) such as REMB [I-D.alvestrand-rmcat-remb] (for 203 receiver-side CC), ACK (for sender-side CC), absolute and/or 204 relative timestamps (for sender-side or receiver-side CC), etc. 206 o Congestion Control: All functions directly responsible for 207 congestion control, including possible new RTP/RTCP extensions, 208 send rate computation (for sender-side CC), receive rate 209 computation (for receiver-side CC), other statistics, and control 210 of the UDP sockets including packet scheduling for traffic shaping 211 /pacing. 213 o Shared State: Storage and exchange of congestion control state for 214 multiple flows within the application and beyond it. 216 o OS: Operating System containing the UDP socket interface and other 217 network functions such as ECN, DSCP, physical interface events, 218 interface-level traffic shaping and packet scheduling, etc. 220 4. Implementation Model 222 There are advantages and drawbacks to implementing congestion control 223 in the application layer. It avoids OS dependencies and allows for 224 rapid experimentation, evolution and optimization for each 225 application. However, it also puts the burden on all applications, 226 which raises the risks of improper or divergent implementations. One 227 motivation of this memo is to mitigate such risks by giving proper 228 guidance on how the application components relating to congestion 229 control should interact. 231 Another drawback of congestion control in the application layer is 232 that any decomposition, including the one presented in Figure 1, is 233 purely conceptual and illustrative, since implementations have 234 differing designs and decompositions. Conversely, this can be viewed 235 as an advantage to distribute congestion control functions wherever 236 expedient without rigid interfaces. For example, they may be 237 distributed within the RTP/RTCP stack itself, so the separate 238 components in Figure 1 are combined into a single RTP+RTCP+CC 239 component as shown in Figure 2. 241 +----------------------------+ 242 | +-----Config | 243 | | | | 244 | | Codec | 245 | APP | | | 246 | +---RTP+RTCP+CC------|---Shared 247 +----------------------------+ State 248 | 249 +----------------------------+ 250 | OS UDP | 251 +----------------------------+ 253 Figure 2 255 The conceptual model in Figure 1 will be used throughout this memo to 256 establish clearer boundaries between functions. But actual 257 implementations may be closer to the looser model in [Singh12]. 259 5. Interfaces and Interactions 261 5.1. Config - Codec Interactions 263 The primary interactions between the config and the codec that are 264 relevant to congestion control are the multiplexing of media streams 265 [I-D.ietf-mmusic-sdp-bundle-negotiation] and RTP/RTCP [RFC5761] on 266 the same UDP port. 268 The config also establishes limits for the codec such as maximum bit 269 rate and other codec-specific parameters. For example, a video codec 270 config often sets limits on maximum resolution and frame rate as well 271 as bit rate. 273 5.2. Config - RTP/RTCP Interactions 275 The config establishes the negotiated RTP and RTCP attributes and 276 extensions such as Extended Reports (XR), reduced size [RFC5506], 277 codec control [RFC5104], transmission time [RFC5450], etc. 279 5.3. Codec - RTP Interactions 281 Packetization of codec frames into RTP packets can be an important 282 interaction. Some network interfaces may benefit from small packet 283 sizes well below the MTU, while others may benefit from large packets 284 approaching the MTU. Equalizing packet sizes of a frame may also be 285 beneficial in some cases, rather than a combination of large and 286 small packets. For example, in some FEC schemes, the FEC bandwidth 287 overhead depends on the largest source packet size. Equalizing the 288 source packet sizes can yield lower overhead than a combination of 289 large and small packets. 291 5.4. Codec - CC Interactions 293 Allowed Rate (from CC to Codec): The max transmit rate allowed over 294 the next time interval. The time interval may be specified or may 295 use a default, for example, one second. The rate may be specified in 296 bytes or packets or both. The rate must never exceed permanent 297 limits established in session signaling such as the SDP bandwidth 298 attribute [RFC4566] nor temporary limits in RTCP such as TMMBR 299 [RFC5104] or REMB [I-D.alvestrand-rmcat-remb]. This is the most 300 important interface among all components, and is always required in 301 any RMCAT solution. In the simplest possible solution, it may be the 302 only CC interface required. 304 Media Elasticity (from Codec to CC): Many live media encoders are 305 highly elastic, often able to achieve any target bit rate within a 306 wide range, by adapting the media quality. For example, a video 307 encoder may support any bit rate within a range of a few tens or 308 hundreds of kbps up to several Mbps, with rate changes registering as 309 fast as the next video frame, although there may be limitations in 310 the frequency of changes. Other encoders may be less elastic, 311 supporting a narrower rate range, coarser granularity of rate steps, 312 slower reaction to rate changes, etc. Other media, particularly some 313 audio codecs, may be fully inelastic with a single fixed rate. CC 314 can beneficially use codec elasticity, if provided, to plan Allowed 315 Rate changes, especially when there are multiple flows sharing CC 316 state and bandwidth. 318 Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an 319 important moment in a conversation. Rapid rate adaptation during 320 startup is therefore important. The codec should minimize its 321 startup media rate as much as possible without adversely impacting 322 the user experience, and support a strategy for rapid rate ramp. The 323 CC should allow the highest startup media rate as possible without 324 adversely impacting network conditions, and also support rapid rate 325 ramp until stabilizing on the available bandwidth. Startup can be 326 viewed as a negotiation between the codec and the CC. The codec 327 requests a startup rate and ramp, and the CC responds with the 328 allowable parameters which may be lower/slower. The RMCAT 329 requirements also include the possibility of bandwidth history to 330 further accelerate or even eliminate startup ramp time. While this 331 is highly desirable from an application viewpoint, it may be less 332 acceptable to network operators, since it is in essence a gamble on 333 current congestion state matching historical state, with the 334 potential for significant congestion contribution if the gamble was 335 wrong. Note that startup can often commence before user interaction 336 or conversation to reduce the chance of clipped media. 338 Delay Tolerance (from Codec to CC): An ideal CC will always minimize 339 delay and target zero. However, real solutions often need a real 340 non-zero delay tolerance. The codec should provide an absolute delay 341 tolerance, perhaps expressed as an impairment factor to mix with 342 other metrics. 344 Loss Tolerance (from Codec to CC): An ideal CC will always minimize 345 packet loss and target zero. However, real solutions often need a 346 real non-zero loss tolerance. The codec should provide an absolute 347 loss tolerance, perhaps expressed as an impairment factor to mix with 348 other metrics. Note this is unrecoverable post-repair loss after 349 retransmission or forward error correction. 351 Throughput Sensitivity (from Codec to CC): An ideal CC will always 352 maximize throughput. However, real solutions often need a trade-off 353 between throughput and other metrics such as delay or loss. The 354 codec should provide throughput sensitivity, perhaps expressed as an 355 impairment factor (for low throughputs) to mix with other metrics. 357 Rate Stability (from Codec to CC): The CC algorithm must strike a 358 balance between rate stability and fast reaction to changes in 359 available bandwidth. The codec should provide its preference for 360 rate stability versus fast and frequent reaction to rate changes, 361 perhaps expressed as an impairment factor (for high rate variance 362 over short timescales) to mix with other metrics. 364 Forward Error Correction (FEC): Simple FEC schemes like XOR Parity 365 codes [RFC5109] may not handle consecutive or burst loss well. More 366 complex FEC schemes like Reed-Solomon [RFC6865] or Raptor [RFC6330] 367 codes are more effective at handling bursty loss. The sensitivity to 368 packet loss therefore depends on the media (source) encoding as well 369 as the FEC (channel) encoding, and this sensitivity may differ for 370 different loss patterns like random, periodic, or consecutive loss. 371 Expressing this sensitivity to the congestion controller may help it 372 choose the right balance between optimizing for throughput versus low 373 loss. 375 Probing for Available Bandwidth: FEC can also be used to probe for 376 additional available bandwidth, if the application desires a higher 377 target rate than the current rate. FEC is preferable to synthetic 378 probes since any contribution to congestion by the FEC probe will not 379 impact the post-repair loss rate of the source media flow while 380 synthetic probes may adversely affect the loss rate [Nagy14]. Note 381 that any use of FEC or retransmission must ensure that the total flow 382 of all packets including FEC, retransmission and original media never 383 exceeds the Allowed Rate. 385 5.5. RTP - CC Interactions 387 RTP Circuit Breakers: The intent behind RTP circuit breakers 388 [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch 389 of last resort, not true congestion control. The breakers should 390 never trip when an effective congestion control is operating. This 391 may impose some boundaries on RMCAT solutions to ensure the 392 congestion control never approaches situations which may trigger the 393 breakers. 395 RTCP Feedback: The primary method of communicating CC information is 396 RTCP. 398 RTP Header Extensions: While RTCP is likely to be the primary carrier 399 of CC feedback, the RMCAT requirements also include the possibility 400 of using RTP header extensions in bidirectional flows for CC 401 feedback. Transmission time [RFC5450], or possibly absolute time, 402 also use header extensions, as would any per packet priority markings 403 expected to survive across different networks and administrative 404 domains. 406 5.6. CC - UDP Interactions 408 Pacing / Shaping: Simple pacing / shaping strategies delay the 409 transmission of packets to equalize inter-packet time intervals, 410 assuming the bottleneck is most sensitive to packet rate. More 411 complex pacing strategies may go beyond simple even distribution of 412 transmission times. For example, Sprout [Winstein13] attempts to 413 predict the optimal transmission time (and rate) with the highest 414 probability of success for each packet based on channel statistics. 415 Pacing may be always on, or adaptively enabled / disabled based on 416 congestion state to minimize delay. Pacing may be performed within 417 the CC for a single flow or across multiple flows. It may also be 418 performed across all or selective traffic over the network interface 419 if the OS supports interface-level traffic shaping. 421 Detection of Transport Capabilities: The CC can query the OS for 422 useful transport capabilities such as ECN, DSCP, traffic shaping, 423 etc. This may also aid upper layers in making better decisions such 424 as whether or not to multiplex media streams. For example, if audio 425 can be given differentiated network treatment from video when using 426 separate ports. 428 ECN: If the OS and transport path support ECN, the CC can react 429 faster than a loss-based CC and more reliably to congestion onset and 430 abatement. 432 DSCP: If the OS and transport path support DSCP, the CC can map per- 433 packet priority from RTP header extensions to DSCP (and layer 2 QoS 434 if available) for better network handling under congestion. 436 AQM: If AQM is present in the bottleneck, and working effectively, 437 there should be little or no excess delay observed when varying the 438 transmission rate. The loss of such delay signals may hinder the 439 performance of congestion control algorithms that are highly 440 dependent on delay variation for adapting transmission rate. If the 441 application has knowledge of the presence of AQM, through any means 442 which are beyond the scope of this memo, it should communicate this 443 to the CC. The CC may use this to alter its signal collection and 444 rate adaptation strategies. The CC must not rely solely on this as a 445 reliable indicator. It must continue to monitor statistics to 446 validate this application hint, and react appropriately if the 447 statistics suggest different network behavior. 449 5.7. CC - Shared State Interactions 451 Multiple Flows: Sharing state across multiple flows within the 452 application can yield better CC decisions. Sharing state across even 453 more flows beyond the application can yield even better CC decisions. 454 The actual benefits and mechanisms of state sharing and coupled CC 455 are described in [I-D.welzl-rmcat-coupled-cc]. 457 Weighted Fairness: An important consideration in CC of multiple flows 458 is their relative application-specified weights. Within an 459 application, it is likely the different flows have different rate 460 requirements, so equal bandwidth sharing may not be fair nor 461 desirable, and weighted fairness may be required. 463 6. Acknowledgements 465 The RMCAT design team discussions contributed to this memo. 467 7. IANA Considerations 469 This memo includes no request to IANA. 471 8. Security Considerations 473 Amplification attacks often use UDP traffic to launch denial of 474 service attacks. Attackers may attempt to subvert congestion control 475 protocols in UDP applications to launch amplification attacks by 476 signaling more bandwidth than is actually available. For example, 477 sending a victim a forged REMB or a few fast ACKs may result in the 478 victim sending a high rate RTP stream. Attacks on conference servers 479 could lead to further amplification if it distributes the streams to 480 many others. One mitigation is to use SRTCP for congestion control 481 messages where supported. Even if SRTCP is only authenticated not 482 encrypted, SRTCP packets should always pass authentication checks 483 before any message contents are interpreted. Non-secure RTCP should 484 be avoided where possible. 486 9. References 488 9.1. Normative References 490 [I-D.alvestrand-rmcat-remb] 491 Alvestrand, H., "RTCP message for Receiver Estimated 492 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 493 progress), October 2013. 495 [I-D.ietf-avtcore-rtp-circuit-breakers] 496 Perkins, C. and V. Singh, "Multimedia Congestion Control: 497 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 498 avtcore-rtp-circuit-breakers-05 (work in progress), 499 February 2014. 501 [I-D.ietf-mmusic-sdp-bundle-negotiation] 502 Holmberg, C., Alvestrand, H., and C. Jennings, 503 "Multiplexing Negotiation Using Session Description 504 Protocol (SDP) Port Numbers", draft-ietf-mmusic-sdp- 505 bundle-negotiation-05 (work in progress), October 2013. 507 [I-D.ietf-rmcat-cc-requirements] 508 Jesup, R., "Congestion Control Requirements For RMCAT", 509 draft-ietf-rmcat-cc-requirements-02 (work in progress), 510 February 2014. 512 [I-D.ietf-rmcat-eval-criteria] 513 Singh, V. and J. Ott, "Evaluating Congestion Control for 514 Interactive Real-time Media", draft-ietf-rmcat-eval- 515 criteria-00 (work in progress), January 2014. 517 [I-D.welzl-rmcat-coupled-cc] 518 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 519 control for RTP media", draft-welzl-rmcat-coupled-cc-02 520 (work in progress), October 2013. 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 526 Jacobson, "RTP: A Transport Protocol for Real-Time 527 Applications", STD 64, RFC 3550, July 2003. 529 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 530 Video Conferences with Minimal Control", STD 65, RFC 3551, 531 July 2003. 533 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 534 Description Protocol", RFC 4566, July 2006. 536 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 537 "Extended RTP Profile for Real-time Transport Control 538 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 539 2006. 541 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 542 "Codec Control Messages in the RTP Audio-Visual Profile 543 with Feedback (AVPF)", RFC 5104, February 2008. 545 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 546 RTP Streams", RFC 5450, March 2009. 548 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 549 Real-Time Transport Control Protocol (RTCP): Opportunities 550 and Consequences", RFC 5506, April 2009. 552 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 553 Control Packets on a Single Port", RFC 5761, April 2010. 555 9.2. Informative References 557 [Nagy14] Nagy, M., Singh, V., Ott, J., and L. Eggert, "Congestion 558 Control using FEC for Conversational Multimedia 559 Communication", Proc. of 5th ACM Internation Conference on 560 Multimedia Systems , 3 2014. 562 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 563 August 1980. 565 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 566 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 568 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 569 Correction", RFC 5109, December 2007. 571 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 572 Friendly Rate Control (TFRC): Protocol Specification", RFC 573 5348, September 2008. 575 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 576 Control", RFC 5681, September 2009. 578 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 579 and L. Minder, "RaptorQ Forward Error Correction Scheme 580 for Object Delivery", RFC 6330, August 2011. 582 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 583 Matsuzono, "Simple Reed-Solomon Forward Error Correction 584 (FEC) Scheme for FECFRAME", RFC 6865, February 2013. 586 [Singh12] Singh, V., Ott, J., and C. Perkins, "Congestion Control 587 for Interactive Media: Control Loops & APIs", Proc. of IAB 588 /IRTF Workshop on Congestion Control for Interactive RTC , 589 7 2012. 591 [Winstein13] 592 Winstein,, K., Sivaraman,, A., and H. Balakrishnan, 593 "Stochastic Forecasts Achieve High Throughput and Low 594 Delay over Cellular Networks", Proc. of the 10th USENIX 595 Symposium on Networked Systems Design and Implementation , 596 4 2013. 598 Authors' Addresses 600 Mo Zanaty 601 Cisco 602 Raleigh, NC 603 USA 605 Email: mzanaty@cisco.com 607 Varun Singh 608 Aalto University 609 Espoo, FIN 610 Finland 612 Email: varun@comnet.tkk.fi 613 Suhas Nandakumar 614 Cisco 615 San Jose, CA 616 USA 618 Email: snandaku@cisco.com 620 Zaheduzzaman Sarker 621 Ericsson AB 622 Luleae 623 Sweden 625 Email: zaheduzzaman.sarker@ericsson.com