idnits 2.17.1 draft-ietf-rmcat-app-interaction-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2014) is 3462 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 583, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-06 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-12 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-06 == Outdated reference: A later version (-14) exists of draft-ietf-rmcat-eval-criteria-02 == Outdated reference: A later version (-05) exists of draft-welzl-rmcat-coupled-cc-04 ** 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: April 30, 2015 Aalto University 6 S. Nandakumar 7 Cisco 8 Z. Sarker 9 Ericsson AB 10 October 27, 2014 12 RTP Application Interaction with Congestion Control 13 draft-ietf-rmcat-app-interaction-01 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 April 30, 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 . . . . . . . . . . . . . . . . . 4 62 3. Conceptual Model . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Implementation Model . . . . . . . . . . . . . . . . . . . . 5 64 5. Interfaces and Interactions . . . . . . . . . . . . . . . . . 6 65 5.1. Config - Codec Interactions . . . . . . . . . . . . . . . 7 66 5.2. Config - RTP/RTCP Interactions . . . . . . . . . . . . . 7 67 5.3. Codec - RTP Interactions . . . . . . . . . . . . . . . . 8 68 5.4. Codec - CC Interactions . . . . . . . . . . . . . . . . . 8 69 5.4.1. Allowed Rate . . . . . . . . . . . . . . . . . . . . 8 70 5.4.2. Media Elasticity . . . . . . . . . . . . . . . . . . 8 71 5.4.3. Startup Ramp . . . . . . . . . . . . . . . . . . . . 8 72 5.4.4. Delay Tolerance . . . . . . . . . . . . . . . . . . . 9 73 5.4.5. Loss Tolerance . . . . . . . . . . . . . . . . . . . 9 74 5.4.6. Throughput Sensitivity . . . . . . . . . . . . . . . 10 75 5.4.7. Rate Stability . . . . . . . . . . . . . . . . . . . 10 76 5.5. RTP - CC Interactions . . . . . . . . . . . . . . . . . . 10 77 5.6. CC - UDP Interactions . . . . . . . . . . . . . . . . . . 11 78 5.7. CC - Shared State Interactions . . . . . . . . . . . . . 12 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 9.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 87 1. Introduction 89 Interactive real-time media applications most commonly use RTP 90 [RFC3550] over UDP [RFC0768]. Since UDP provides no form of 91 congestion control, which is essential for any application deployed 92 on the Internet, these RTP applications have historically implemented 93 one of the following options at the application layer to address 94 their congestion control requirements. 96 1. For media with relatively low packet rates and bit rates, such as 97 many speech codecs, some applications use a simple form of 98 congestion control that stops transmission permanently or 99 temporarily after observing significant packet loss over a 100 significant period of time, similar to the RTP circuit breakers 101 [I-D.ietf-avtcore-rtp-circuit-breakers]. 103 2. Some applications have no explicit congestion control, despite 104 the clear requirements in RTP and its profiles AVP [RFC3551] and 105 AVPF [RFC4585], under the expectation that users will terminate 106 media flows that are significantly impaired by congestion (in 107 essence, human circuit breakers). 109 3. For media with substantially higher packet rates and bit rates, 110 such as many video codecs, various non-standard congestion 111 control techniques are often used to adapt transmission rate 112 based on receiver feedback. 114 4. Some experimental applications use standardized techniques such 115 as TCP-Friendly Rate Control (TFRC) [RFC5348]. However, for 116 various reasons, these have not been widely deployed. 118 The RTP Media Congestion Avoidance Techniques (RMCAT) working group 119 was chartered to standardize appropriate and effective congestion 120 control for RTP applications. It is expected such applications will 121 migrate from the above historical solutions to the RMCAT solution(s). 123 The RMCAT requirements [I-D.ietf-rmcat-cc-requirements] include low 124 delay, reasonably high throughput, fast reaction to capacity changes 125 including routing or interface changes, stability without over- 126 reaction or oscillation, fair bandwidth sharing with other instances 127 of itself and TCP flows, sharing information across multiple flows 128 when possible [I-D.welzl-rmcat-coupled-cc], and performing as well or 129 better in networks which support Active Queue Management (AQM), 130 Explicit Congestion Notification (ECN), or Differentiated Services 131 Code Points (DSCP). 133 In order to meet these requirements, interactions are necessary 134 between the application's congestion controller, the RTP layer, media 135 codecs, other components, and the underlying UDP/IP network stack. 136 This memo discusses these interactions, presents a conceptual model 137 of the required interfaces based on a simplified application 138 decomposition, and proposes specific information exchange across 139 these interfaces along with corresponding component behavior. 141 Note that RTP can also operate over other transports with integrated 142 congestion control such as TCP [RFC5681] and DCCP [RFC4340], but that 143 is beyond the scope of RMCAT and this memo. 145 2. Key Words for Requirements 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 3. Conceptual Model 153 It is useful to decompose an RTP application into several components 154 to facilitate understanding and discussion of where congestion 155 control functions operate, and how they interface with the other 156 components. The conceptual model in Figure 1 consists of the 157 following components. 159 +----------------------------+ 160 | +-----Config-----+ | 161 | | | | | 162 | | Codec | | 163 | | | | | | | 164 | APP +---RTP | RTCP---+ | 165 | | | | | | 166 | | | | | | 167 | +---Congestion-------|---Shared 168 | Control | State 169 +----------------------------+ 170 | 171 +----------------------------+ 172 | Network UDP | 173 | Stack | | 174 | IP | 175 +----------------------------+ 177 Figure 1 179 o APP: Application containing one or more RTP streams and the 180 corresponding media codecs and congestion controllers. For 181 example, a WebRTC browser. 183 o Config: Configuration specified by the application that provides 184 the media and transport parameters, RTP and RTCP parameters and 185 extensions, and congestion control parameters. For example, a 186 WebRTC Javascript application may use the 'constraints' API to 187 affect the media configuration, and SDP applications may negotiate 188 the media and transport parameters with the remote peer. This 189 determines the initial static configuration negotiated in session 190 establishment. The dynamic state may differ due to congestion or 191 other factors, but still must conform to limits established in the 192 config. 194 o Codec: Media encoder/decoder or other source/sink for the RTP 195 payload. The codec may be, for example, a simple monaural audio 196 format, a complex scalable video codec with several dependent 197 layers, or a source/sink with no live encoding/decoding such as a 198 mixer which selectively switches and forwards streams rather than 199 mixes media. 201 o RTP: Standard RTP stack functions, including media packetization / 202 depacketization and header processing, but excluding existing 203 extensions and possible new extensions specific to congestion 204 control (CC) such as absolute timestamps or relative transmission 205 time offsets in RTP header extensions. RTCP: Standard RTCP 206 functions, including sender reports, receiver reports, extended 207 reports, circuit breakers [I-D.ietf-avtcore-rtp-circuit-breakers], 208 feedback messages such as NACK [RFC4585] and codec control 209 messages such as TMMBR [RFC5104], but excluding existing 210 extensions and possible new extensions specific to congestion 211 control (CC) such as REMB [I-D.alvestrand-rmcat-remb] (for 212 receiver-side CC), ACK (for sender-side CC), absolute and/or 213 relative timestamps (for sender-side or receiver-side CC), etc. 215 o Congestion Control: All functions directly responsible for 216 congestion control, including possible new RTP/RTCP extensions, 217 send rate computation (for sender-side CC), receive rate 218 computation (for receiver-side CC), other statistics, and control 219 of the UDP sockets including packet scheduling for traffic 220 shaping/pacing. 222 o Shared State: Storage and exchange of congestion control state for 223 multiple flows within the application and beyond it. 225 o Network Stack: The platform's underlying network functions, 226 usually part of the Operating System (OS), containing the UDP 227 socket interface and other network functions such as ECN, DSCP, 228 physical interface events, interface-level traffic shaping and 229 packet scheduling, etc. This is usually part of the Operating 230 System, often within the kernel; however, user-space network 231 stacks and components are also possible. 233 4. Implementation Model 235 There are advantages and drawbacks to implementing congestion control 236 in the application layer. It avoids platform dependencies and allows 237 for rapid experimentation, evolution and optimization for each 238 application. However, it also puts the burden on all applications, 239 which raises the risks of improper or divergent implementations. One 240 motivation of this memo is to mitigate such risks by giving proper 241 guidance on how the application components relating to congestion 242 control should interact. 244 Another drawback of congestion control in the application layer is 245 that any decomposition, including the one presented in Figure 1, is 246 purely conceptual and illustrative, since implementations have 247 differing designs and decompositions. Conversely, this can be viewed 248 as an advantage to distribute congestion control functions wherever 249 expedient without rigid interfaces. For example, they may be 250 distributed within the RTP/RTCP stack itself, so the separate 251 components in Figure 1 are combined into a single RTP+RTCP+CC 252 component as shown in Figure 2. 254 +----------------------------+ 255 | +-----Config | 256 | | | | 257 | | Codec | 258 | APP | | | 259 | +---RTP+RTCP+CC------|---Shared 260 +----------------------------+ State 261 | 262 +----------------------------+ 263 | Network UDP | 264 | Stack | | 265 | IP | 266 +----------------------------+ 268 Figure 2 270 The conceptual model in Figure 1 will be used throughout this memo to 271 establish clearer boundaries between functions. But actual 272 implementations may be closer to the looser model in Figure 2 and 273 [Singh12]. 275 5. Interfaces and Interactions 277 The following subsections describe the interfaces and interactions 278 between each of the interfaces in the conceptual model. Within each 279 subsection, the most important interfaces and interactions are listed 280 first. This overview provides an overall priority for all 281 subsections, listing the top 5 interactions that CC designers and 282 application developers must consider. 284 o Allowed Rate (CC-Codec): This is the critical interface to close 285 the feedback loop between sender and receiver, so codec output 286 adapts rapidly to receiver feedback. See Section 5.4.1 for 287 details. 289 o Startup Ramp (CC-Codec): Initial rate (or number of packets in 290 window-based CC proposals) and strategy for increasing the rate 291 (or window) during media startup, similar to TCP intial congestion 292 window and slow start. See Section 5.4.3 for details. 294 o Delay Tolerance (CC-Codec): See Section 5.4.4 for details. 296 o Loss Tolerance (CC-Codec): See Section 5.4.5 for details. 298 o Priority / Weight (Config-CC-UDP): If the application has multiple 299 media flows, and can configure relative priority or weight among 300 them, the config can interact with shared state if coupled CC is 301 used (Section 5.7), or interact directly with a CC designed with 302 intrinsic distributed weighted fairness such as NADA. Priority 303 can also interact with the underlying network stack if it supports 304 layer 2/3 prioritization (Section 5.6). 306 5.1. Config - Codec Interactions 308 The primary interactions between the config and the codec that are 309 relevant to congestion control are the multiplexing of media streams 310 [I-D.ietf-mmusic-sdp-bundle-negotiation] and RTP/RTCP [RFC5761] on 311 the same UDP port. 313 The config also establishes limits for the codec such as maximum bit 314 rate and other codec-specific parameters. For example, a video codec 315 config often sets limits on maximum resolution and frame rate as well 316 as bit rate. 318 Editor To-do: The W3C WebRTC Working Group is discussing the Media 319 Constraints API and the Object RTC (ORTC) Capabilities API. Once 320 finalized, these may impact the Config-related interactions for 321 WebRTC applications. Potential interactions include application 322 priority of media streams and application control of bandwidth, FEC, 323 and other parameters affecting media quality. 325 5.2. Config - RTP/RTCP Interactions 327 The config establishes the negotiated RTP and RTCP attributes and 328 extensions such as Extended Reports (XR), reduced size [RFC5506], 329 codec control [RFC5104], transmission time [RFC5450], etc. 331 Editor To-do: The W3C WebRTC Working Group is discussing the Stats 332 API. Once finalized, this may impact the RTP/RTCP-related 333 interactions for WebRTC applications. 335 5.3. Codec - RTP Interactions 337 Packetization of codec frames into RTP packets can be an important 338 interaction. Some network interfaces may benefit from small packet 339 sizes well below the MTU, while others may benefit from large packets 340 approaching the MTU. Equalizing packet sizes of a frame may also be 341 beneficial in some cases, rather than a combination of large and 342 small packets. For example, in some FEC schemes, the FEC bandwidth 343 overhead depends on the largest source packet size. Equalizing the 344 source packet sizes can yield lower overhead than a combination of 345 large and small packets. 347 5.4. Codec - CC Interactions 349 5.4.1. Allowed Rate 351 Allowed Rate (from CC to Codec): The max transmit rate allowed over 352 the next time interval. The time interval may be specified or may 353 use a default. The rate may be specified in bytes or packets or 354 both. The rate must never exceed permanent limits established in 355 session signaling such as the SDP bandwidth attribute [RFC4566] nor 356 temporary limits in RTCP such as TMMBR [RFC5104] or REMB 357 [I-D.alvestrand-rmcat-remb]. This is the most important interface 358 among all components, and is always required in any RMCAT solution. 359 In the simplest possible solution, it may be the only CC interface 360 required. 362 5.4.2. Media Elasticity 364 Media Elasticity (from Codec to CC): Many live media encoders are 365 highly elastic, often able to achieve any target bit rate within a 366 wide range, by adapting the media quality. For example, a video 367 encoder may support any bit rate within a range of a few tens or 368 hundreds of kbps up to several Mbps, with rate changes registering as 369 fast as the next video frame, although there may be limitations in 370 the frequency of changes. Other encoders may be less elastic, 371 supporting a narrower rate range, coarser granularity of rate steps, 372 slower reaction to rate changes, etc. Other media, particularly some 373 audio codecs, may be fully inelastic with a single fixed rate. CC 374 can beneficially use codec elasticity, if provided, to plan Allowed 375 Rate changes, especially when there are multiple flows sharing CC 376 state and bandwidth. 378 5.4.3. Startup Ramp 380 Startup Ramp (from Codec to CC, and from CC to Codec): Startup is an 381 important moment in a conversation. Rapid rate adaptation during 382 startup is therefore important. The codec should minimize its 383 startup media rate as much as possible without adversely impacting 384 the user experience, and support a strategy for rapid rate ramp. The 385 CC should allow the highest startup media rate as possible without 386 adversely impacting network conditions, and also support rapid rate 387 ramp until stabilizing on the available bandwidth. Startup can be 388 viewed as a negotiation between the codec and the CC. The codec 389 requests a startup rate and ramp, and the CC responds with the 390 allowable parameters which may be lower/slower. The RMCAT 391 requirements also include the possibility of bandwidth history to 392 further accelerate or even eliminate startup ramp time. While this 393 is highly desirable from an application viewpoint, it may be less 394 acceptable to network operators, since it is in essence a gamble on 395 current congestion state matching historical state, with the 396 potential for significant congestion contribution if the gamble was 397 wrong. Note that startup can often commence before user interaction 398 or conversation to reduce the chance of clipped media. 400 5.4.4. Delay Tolerance 402 Delay Tolerance (from Codec to CC): An ideal CC will always minimize 403 delay and target zero. However, real solutions often need a real 404 non-zero delay tolerance. The codec should provide an absolute delay 405 tolerance, perhaps expressed as an impairment factor to mix with 406 other metrics. 408 5.4.5. Loss Tolerance 410 Loss Tolerance (from Codec to CC): An ideal CC will always minimize 411 packet loss and target zero. However, real solutions often need a 412 real non-zero loss tolerance. The codec should provide an absolute 413 loss tolerance, perhaps expressed as an impairment factor to mix with 414 other metrics. Note this is unrecoverable post-repair loss after 415 retransmission or forward error correction. 417 Forward Error Correction (FEC): Simple FEC schemes like XOR Parity 418 codes [RFC5109] may not handle consecutive or burst loss well. More 419 complex FEC schemes like Reed-Solomon [RFC6865] or Raptor [RFC6330] 420 codes are more effective at handling bursty loss. The sensitivity to 421 packet loss therefore depends on the media (source) encoding as well 422 as the FEC (channel) encoding, and this sensitivity may differ for 423 different loss patterns like random, periodic, or consecutive loss. 424 Expressing this sensitivity to the congestion controller may help it 425 choose the right balance between optimizing for throughput versus low 426 loss. 428 Probing for Available Bandwidth: FEC can also be used to probe for 429 additional available bandwidth, if the application desires a higher 430 target rate than the current rate. FEC is preferable to synthetic 431 probes since any contribution to congestion by the FEC probe will not 432 impact the post-repair loss rate of the source media flow while 433 synthetic probes may adversely affect the loss rate [Nagy14]. Note 434 that any use of FEC or retransmission must ensure that the total flow 435 of all packets including FEC, retransmission and original media never 436 exceeds the Allowed Rate. 438 5.4.6. Throughput Sensitivity 440 Throughput Sensitivity (from Codec to CC): An ideal CC will always 441 maximize throughput. However, real solutions often need a trade-off 442 between throughput and other metrics such as delay or loss. The 443 codec should provide throughput sensitivity, perhaps expressed as an 444 impairment factor (for low throughputs) to mix with other metrics. 446 5.4.7. Rate Stability 448 Rate Stability (from Codec to CC): The CC algorithm must strike a 449 balance between rate stability and fast reaction to changes in 450 available bandwidth. The codec should provide its preference for 451 rate stability versus fast and frequent reaction to rate changes, 452 perhaps expressed as an impairment factor (for high rate variance 453 over short timescales) to mix with other metrics. 455 5.5. RTP - CC Interactions 457 RTP Circuit Breakers: The intent behind RTP circuit breakers 458 [I-D.ietf-avtcore-rtp-circuit-breakers] is to provide a kill switch 459 of last resort, not true congestion control. The breakers should 460 never trip when an effective congestion control is operating. This 461 may impose some boundaries on RMCAT solutions to ensure the 462 congestion control never approaches situations which may trigger the 463 breakers. 465 RTCP Feedback: The primary method of communicating CC information is 466 RTCP. 468 RTP Header Extensions: While RTCP is likely to be the primary carrier 469 of CC feedback, the RMCAT requirements also include the possibility 470 of using RTP header extensions in bidirectional flows for CC 471 feedback. Transmission time [RFC5450], or possibly absolute time, 472 also use header extensions, as would any per packet priority markings 473 expected to survive across different networks and administrative 474 domains. 476 5.6. CC - UDP Interactions 478 Pacing / Shaping: Simple pacing / shaping strategies delay the 479 transmission of packets to equalize inter-packet time intervals, 480 assuming the bottleneck is most sensitive to packet rate. More 481 complex pacing strategies may go beyond simple even distribution of 482 transmission times. For example, Sprout [Winstein13] attempts to 483 predict the optimal transmission time (and rate) with the highest 484 probability of success for each packet based on channel statistics. 485 Pacing may be always on, or adaptively enabled / disabled based on 486 congestion state to minimize delay. Pacing may be performed within 487 the CC for a single flow or across multiple flows. It may also be 488 performed across all or selective traffic over the network interface 489 if the network stack supports interface-level traffic shaping. 491 Detection of Transport Capabilities: The CC can query the network 492 stack for useful transport capabilities such as ECN, DSCP, traffic 493 shaping, etc. This may also aid upper layers in making better 494 decisions such as whether or not to multiplex media streams. For 495 example, if audio can be given differentiated network treatment from 496 video when using separate ports. 498 ECN: If the network stack and transport path support ECN, the CC can 499 react faster than a loss-based CC and more reliably to congestion 500 onset and abatement. 502 DSCP: If the network stack and transport path support DSCP, the CC 503 can map per-packet priority from RTP header extensions to DSCP (and 504 layer 2 QoS if available) for better network handling under 505 congestion. 507 AQM: If AQM is present in the bottleneck, and working effectively, 508 there should be little or no excess delay observed when varying the 509 transmission rate. The loss of such delay signals may hinder the 510 performance of congestion control algorithms that are highly 511 dependent on delay variation for adapting transmission rate. If the 512 application has knowledge of the presence of AQM, through any means 513 which are beyond the scope of this memo, it should communicate this 514 to the CC. The CC may use this to alter its signal collection and 515 rate adaptation strategies. The CC must not rely solely on this as a 516 reliable indicator. It must continue to monitor statistics to 517 validate this application hint, and react appropriately if the 518 statistics suggest different network behavior. 520 5.7. CC - Shared State Interactions 522 Multiple Flows: Sharing state across multiple flows within the 523 application can yield better CC decisions. Sharing state across even 524 more flows beyond the application can yield even better CC decisions. 525 The actual benefits and mechanisms of state sharing and coupled CC 526 are described in [I-D.welzl-rmcat-coupled-cc]. 528 Weighted Fairness: An important consideration in CC of multiple flows 529 is their relative application-specified weights. Within an 530 application, it is likely the different flows have different rate 531 requirements, so equal bandwidth sharing may not be fair nor 532 desirable, and weighted fairness may be required. 534 6. Acknowledgements 536 The RMCAT design team discussions contributed to this memo. 538 7. IANA Considerations 540 This memo includes no request to IANA. 542 8. Security Considerations 544 Amplification attacks often use UDP traffic to launch denial of 545 service attacks. Attackers may attempt to subvert congestion control 546 protocols in UDP applications to launch amplification attacks by 547 signaling more bandwidth than is actually available. For example, 548 sending a victim a forged REMB or a few fast ACKs may result in the 549 victim sending a high rate RTP stream. Attacks on conference servers 550 could lead to further amplification if it distributes the streams to 551 many others. One mitigation is to use SRTCP for congestion control 552 messages where supported. Even if SRTCP is only authenticated not 553 encrypted, SRTCP packets should always pass authentication checks 554 before any message contents are interpreted. Non-secure RTCP should 555 be avoided where possible. 557 9. References 559 9.1. Normative References 561 [I-D.alvestrand-rmcat-remb] 562 Alvestrand, H., "RTCP message for Receiver Estimated 563 Maximum Bitrate", draft-alvestrand-rmcat-remb-03 (work in 564 progress), October 2013. 566 [I-D.ietf-avtcore-rtp-circuit-breakers] 567 Perkins, C. and V. Singh, "Multimedia Congestion Control: 568 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 569 avtcore-rtp-circuit-breakers-06 (work in progress), July 570 2014. 572 [I-D.ietf-mmusic-sdp-bundle-negotiation] 573 Holmberg, C., Alvestrand, H., and C. Jennings, 574 "Negotiating Media Multiplexing Using the Session 575 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 576 negotiation-12 (work in progress), October 2014. 578 [I-D.ietf-rmcat-cc-requirements] 579 Jesup, R., "Congestion Control Requirements For RMCAT", 580 draft-ietf-rmcat-cc-requirements-06 (work in progress), 581 October 2014. 583 [I-D.ietf-rmcat-eval-criteria] 584 Singh, V. and J. Ott, "Evaluating Congestion Control for 585 Interactive Real-time Media", draft-ietf-rmcat-eval- 586 criteria-02 (work in progress), July 2014. 588 [I-D.welzl-rmcat-coupled-cc] 589 Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion 590 control for RTP media", draft-welzl-rmcat-coupled-cc-04 591 (work in progress), October 2014. 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 597 Jacobson, "RTP: A Transport Protocol for Real-Time 598 Applications", STD 64, RFC 3550, July 2003. 600 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 601 Video Conferences with Minimal Control", STD 65, RFC 3551, 602 July 2003. 604 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 605 Description Protocol", RFC 4566, July 2006. 607 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 608 "Extended RTP Profile for Real-time Transport Control 609 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 610 2006. 612 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 613 "Codec Control Messages in the RTP Audio-Visual Profile 614 with Feedback (AVPF)", RFC 5104, February 2008. 616 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 617 RTP Streams", RFC 5450, March 2009. 619 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 620 Real-Time Transport Control Protocol (RTCP): Opportunities 621 and Consequences", RFC 5506, April 2009. 623 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 624 Control Packets on a Single Port", RFC 5761, April 2010. 626 9.2. Informative References 628 [Nagy14] Nagy, M., Singh, V., Ott, J., and L. Eggert, "Congestion 629 Control using FEC for Conversational Multimedia 630 Communication", Proc. of 5th ACM Internation Conference on 631 Multimedia Systems , 3 2014. 633 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 634 August 1980. 636 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 637 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 639 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 640 Correction", RFC 5109, December 2007. 642 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 643 Friendly Rate Control (TFRC): Protocol Specification", RFC 644 5348, September 2008. 646 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 647 Control", RFC 5681, September 2009. 649 [RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., 650 and L. Minder, "RaptorQ Forward Error Correction Scheme 651 for Object Delivery", RFC 6330, August 2011. 653 [RFC6865] Roca, V., Cunche, M., Lacan, J., Bouabdallah, A., and K. 654 Matsuzono, "Simple Reed-Solomon Forward Error Correction 655 (FEC) Scheme for FECFRAME", RFC 6865, February 2013. 657 [Singh12] Singh, V., Ott, J., and C. Perkins, "Congestion Control 658 for Interactive Media: Control Loops & APIs", Proc. of 659 IAB/IRTF Workshop on Congestion Control for Interactive 660 RTC , 7 2012. 662 [Winstein13] 663 Winstein,, K., Sivaraman,, A., and H. Balakrishnan, 664 "Stochastic Forecasts Achieve High Throughput and Low 665 Delay over Cellular Networks", Proc. of the 10th USENIX 666 Symposium on Networked Systems Design and Implementation , 667 4 2013. 669 Authors' Addresses 671 Mo Zanaty 672 Cisco 673 Raleigh, NC 674 USA 676 Email: mzanaty@cisco.com 678 Varun Singh 679 Aalto University 680 Espoo, FIN 681 Finland 683 Email: varun@comnet.tkk.fi 685 Suhas Nandakumar 686 Cisco 687 San Jose, CA 688 USA 690 Email: snandaku@cisco.com 692 Zaheduzzaman Sarker 693 Ericsson AB 694 Luleae 695 Sweden 697 Email: zaheduzzaman.sarker@ericsson.com