idnits 2.17.1 draft-singh-rmcat-adaptive-fec-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 (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-05 == Outdated reference: A later version (-11) exists of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-05 == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-cc-requirements-02 == Outdated reference: A later version (-03) exists of draft-alvestrand-rmcat-congestion-02 == Outdated reference: A later version (-05) exists of draft-johansson-rmcat-scream-cc-02 == Outdated reference: A later version (-01) exists of draft-sarker-rmcat-eval-test-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMCAT WG V. Singh 3 Internet-Draft M. Nagy 4 Intended status: Experimental J. Ott 5 Expires: January 5, 2015 Aalto University 6 L. Eggert 7 NetApp 8 July 4, 2014 10 Congestion Control Using FEC for Conversational Media 11 draft-singh-rmcat-adaptive-fec-00 13 Abstract 15 This document describes a new mechanism for conversational multimedia 16 flows. The proposed mechanism uses Forward Error Correction (FEC) 17 encoded RTP packets (redundant packets) along side the media packets 18 to probe for available network capacity. A straightforward 19 interpretation is, the sending endpoint increases the transmission 20 rate by keeping the media rate constant but increases the amount of 21 FEC. If no losses and discards occur, the endpoint can then increase 22 the media rate. If losses occur, the redundant FEC packets help in 23 recovering the lost packets. Consequently, the endpoint can vary the 24 FEC bit rate to conservatively (by a small amount) or aggressively 25 (by a large amount) probe for available network capacity. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 5, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Concept: FEC for Congestion Control . . . . . . . . . . . . . 4 64 3.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Framework . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.4. Applicability to other RMCAT Schemes . . . . . . . . . . 7 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. Simulations . . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Real-time Transport Protocol (RTP) [RFC3550] is widely used in 80 voice telephony and video conferencing systems. Many of these 81 systems run over best-effort UDP/IP networks, and are required to 82 implement congestion to adapt the transmission rate of the RTP 83 streams to match the available network capacity, while maintaing the 84 user-experience [I-D.ietf-rmcat-cc-requirements]. The circuit 85 breakers [I-D.ietf-avtcore-rtp-circuit-breakers] describe a minimal 86 set of conditions when an RTP stream is causing severe congestion and 87 should cease transmission. Consequently, the congestion control 88 algorithm are expected to avoid triggering these conditions. 90 Conversational multimedia systems use Negative Acknowlegment (NACK), 91 Forward Error Correction (FEC), and Reference Picture Selection (RPS) 92 to protect against packet loss. These are used in addition to the 93 codec-dependent resilience methods (for e.g., full intra-refresh and 94 error-concealment). In this way, the multimedia system is anyway 95 trading off part of the transmission rate for redundancy or 96 retransmissions to reduce the effects of packet loss. An endpoint 97 often prefers using FEC in high latency networks where 98 retransmissions may arrive later than the playout time of the packet 99 (due to the size of the dejitter buffer) [Holmer13]. Therefore, the 100 endpoint needs to adapt the transmission rate to best fit the 101 changing network capacity and the amount of redundancy based on the 102 observed/expected loss rate and network latency. Figure 1 shows the 103 applicatbility of different error-resilience schemes based on the 104 end-to-end latency and the observed packet loss [Devadoss08]. 106 ^ 107 | .__________. 108 | | | 109 | | UEP/FEC | 110 l |____________|____. | 111 a | | | | 112 t | RPS | | | 113 e |_______. | | | 114 n | | | | | 115 c | | |____|_____| 116 y | NACK | | 117 | | | 118 +-------------------------------> 119 Packet loss 121 Figure 1: Applicability of Error Resilience Schemes based on the 122 network delay and observed packet loss 124 In this document, we describe the use of FEC packets not only for 125 error-resilience but also as a probing mechanism for congestion 126 control (ramping up the transmission rate). 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in BCP 14, [RFC2119] and 133 indicate requirement levels for compliant implementations. 135 The terminology defined in RTP [RFC3550], RTP Profile for Audio and 136 Video Conferences with Minimal Control [RFC3551], RTCP Extended 137 Report (XR) [RFC3611], Extended RTP Profile for RTCP-based Feedback 138 (RTP/AVPF) [RFC4585], RTP Retransmission Payload Format [RFC4588], 139 Forward Error Correction (FEC) Framework [RFC6363], and Support for 140 Reduced-Size RTCP [RFC5506] apply. 142 3. Concept: FEC for Congestion Control 144 FEC is one method for providing error-resilience, it improves 145 reliability by adding redundant data to the primary media flow, which 146 is used by received to recover packets that have been lost due to 147 congestion or bit-errors. The congestion control algorithm on the 148 other hand aims at maximizing the network path utilization, but risks 149 over-estimating the avaiable end-to-end network capacity leading to 150 congestion (and therefore losses). 152 The main idea behind using FEC for congestion control is as follows: 153 the sending endpoint chooses a high FEC rate to aggressively probe 154 for available capacity and conversely chooses a low FEC rate to 155 conservatively probe for available capacity. During the ramp up, if 156 a packet is lost and the FEC packet arrives in time for decoding, the 157 receiver is be able to recover the lost packet; if no packet is lost, 158 the sender is able to increase the media encoding rate by swapping 159 out a part of the FEC rate. This method can be especially useful 160 when the transmission rate is close to the bottleneck link rate: by 161 choosing an appropriate FEC rate, the endpoint is able to probe for 162 available capacity without changing the target media rate and 163 therefore not affecting the user-experience. Therefore, the 164 congestion control algorithm is always able to probe for available 165 capacity, as improved reliability compensates for possible errors 166 resulting from overuse (i.e., increase in observed latency and/or 167 losses). 169 +------------+ (B) Good conditions +-----------+ 170 | |------------------------------------>| | 171 | STEADY | | PROBE | 172 | |<------------------------------------| | 173 +------------+ Probed, but Loss recovered +-----------+ 174 /\ | | /\ | 175 | |(A) | | | 176 | |_______________________________________________| | |(C) 177 (B) | | (A) | | 178 | \/ (B) | \/ 179 +------------+ +------------+ 180 | | (A) Unstable conditions | | 181 | REDUCE |<------------------------------------| INCREASE | 182 | | | | 183 +------------+ +------------+ 185 Figure 2: State machine of a Congestion Control enabling FEC. 187 3.1. States 189 The Figure 2 illustrates the the state machine of a congestion 190 control algorithm incorporating FEC for probing. The state-machine 191 includes 4 states: STEADY, PROBE, INCREASE, and REDUCE. 193 o STEADY state: The congestion control keeps the same target media 194 rate and no additional FEC packets are generated for probing. 195 This is a transient state, after which the congestion control 196 attempts to increase the transmission rate. 198 o REDUCE state: The congestion control reduces the transmission rate 199 based on the observed congestion cues, and generated no additional 200 FEC packets than the minimum required for error-resilience. If in 201 subsequent reports the conditions improve, the congestion control 202 can directly transition to the probe state. 204 o PROBE state: The congestion control observes no congestion (i.e., 205 the transmission rate should be increased). The endpoint 206 maintains the same target media bit rate, and instead increases 207 the amount of FEC. 209 o INCREASE state: Depending on the congestion feedback, i.e., if no 210 congestion is observed, the media transmission rate can be 211 increased while maintaining minimal amount of FEC for error 212 protection. If packets are lost, but the lost packets are 213 recovered by the FEC packets, the congestion control can keep the 214 same media bit rate and reduce the amount of FEC (compared to the 215 previous PROBE state). If congestion is observed, the congestion 216 control can transition to the REDUCE state and decrease the 217 transmission rate. 219 3.2. Framework 221 The Figure 3 shows the interaction between the rate control module, 222 the RTP and the FEC module. 224 At the sender, the rate control module calculates the new bit rate. 225 If the new bit rate is higher than the previous than the previous bit 226 rate indicates to the FEC module that the congestion control intends 227 to probe. The FEC module depending on its internal state machine 228 decides to add FEC for probing or not. Thereafter it indicates to 229 the rate control module the bit rate remaining for the RTP media 230 stream, which may be less than equal to the calculated bit rate. 232 At the reciver, the FEC module reconstructs lost packets in the 233 primary stream from the packets received in the repair stream. If 234 packets are repair it generates the post-repair loss report 235 (discussed in Section 3.3) for the corresponding RTP packets. 237 At the sender, The FEC module also receives the RTCP Feedback related 238 to the primary stream and any post-repair loss report. It uses the 239 information from these RTCP reports to calculate the effectiveness of 240 FEC for congestion control and is also the basis for changing its 241 internal state. 243 + - - - - - - - - - - - - - - - - - - - - - - - -+ 244 | +--------------------------------------------+ | 245 | Media Encoder/Decoder | 246 | +--------------------------------------------+ | 247 | | 248 | +- -- -- -- -- -- -- -+ +- -- -- -- -+ | 249 | Rate Control | | RTP | 250 | | Module | | Queue | | 251 +- -- -- -- -- -- -- -+ +- -- -- -- -+ 252 | ^ | | | 253 | | | Source 254 | | R +--------------------+ | RTP | 255 | T | | 256 | | C | | | 257 | P | | 258 | | +----------+ +----------------+ | 259 | F | FEC Code |<--->| FEC Module | 260 | | B +----------+ +----------------+ | 261 | | | | 262 | |------------------------+ | | | 263 | RTCP FB Repair | | Source 264 | | RTP | | RTP | 265 | | | 266 | +--------------------------------------------+ | 267 | Transport Layer (UDP) | 268 | +--------------------------------------------+ | 269 | 270 | +--------------------------------------------+ | 271 | IP | 272 | +--------------------------------------------+ | 274 | Endpoint | 275 + - - - - - - - - - - - - - - - - - - - - - - - + 277 Figure 3: Interaction of Congestion Control and FEC Module. 279 3.3. FEC Scheme 281 [RFC6363] describes a framework for using Forward Error Correction 282 (FEC) codes with RTP and allows any FEC code to be used with the 283 framework. For this proposal, the FEC packets are created by XORing 284 RTP media packets, the resulting redundant RTP packets are encoded 285 using the scheme defined in [RFC5109]. 287 The endpoint MAY use a single-frame FEC or a multi-frame FEC for 288 protecting the primary RTP stream. A single-frame FEC protects 289 against a single packet loss and fails when burst loss occurs. Using 290 multi-frame FEC helps mitigate these issues at the cost of higher 291 overhead and latency in recovering lost packets. [Holmer13] shows 292 examples of using a single- and multi-frame FEC. 294 The receiving endpoint may report the post-repair loss (or residual 295 loss) using either the report block defined in [RFC5725] (Run-length 296 encoding of packets repaired) or in 297 [I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count] (packet count of 298 repaired packets). 300 3.4. Applicability to other RMCAT Schemes 302 [Open issue: The current implementation is delay based and is 303 documented in [Nagy14]. However, we would like to generalize the 304 concept and apply it to different RMCAT algorithms for e.g., Google's 305 Congestion Control algorithm [I-D.alvestrand-rmcat-congestion], 306 SCReaM [I-D.johansson-rmcat-scream-cc], etc.] 308 4. Security Considerations 310 The security considerations of [RFC3550], RTP/AVPF profile for rapid 311 RTCP feedback [RFC4585], circuit breaker 312 [I-D.ietf-avtcore-rtp-circuit-breakers], and Generic Forward Error 313 Correction [RFC5109] apply. 315 If non-authenticated RTCP reports are used, an on-path attacker can 316 send forged RTCP feedback packets that can disrupt the operation of 317 the underlying congestion control. Additionally, the forged packets 318 can either indicate no packet loss causing the congestion control to 319 ramp-up quickly, or indicate high packet loss or RTT causing the 320 circuit breaker to trigger. 322 5. IANA Considerations 324 There are no IANA impacts in this memo. 326 6. Acknowledgements 328 This document is based on the results published in [Nagy14]. 330 The work of Varun Singh, and Joerg Ott has been partially supported 331 by the European Institute of Innovation and Technology (EIT) ICT Labs 332 activity RCLD 11882. The views expressed here are those of the 333 author(s) only. Neither the European Commission nor the EITICT labs 334 is liable for any use that may be made of the information in this 335 document. 337 7. References 339 7.1. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997. 344 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 345 Jacobson, "RTP: A Transport Protocol for Real-Time 346 Applications", STD 64, RFC 3550, July 2003. 348 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 349 Video Conferences with Minimal Control", STD 65, RFC 3551, 350 July 2003. 352 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 353 Protocol Extended Reports (RTCP XR)", RFC 3611, November 354 2003. 356 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 357 "Extended RTP Profile for Real-time Transport Control 358 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 359 2006. 361 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 362 Real-Time Transport Control Protocol (RTCP): Opportunities 363 and Consequences", RFC 5506, April 2009. 365 [I-D.ietf-avtcore-rtp-circuit-breakers] 366 Perkins, C. and V. Singh, "Multimedia Congestion Control: 367 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 368 avtcore-rtp-circuit-breakers-05 (work in progress), 369 February 2014. 371 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 372 Correction", RFC 5109, December 2007. 374 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 375 Report Block Type for RTP Control Protocol (RTCP) Extended 376 Reports (XRs)", RFC 5725, February 2010. 378 [I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count] 379 Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 380 Extended Report (XR) for Post-Repair Loss Count Metrics", 381 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-05 (work 382 in progress), June 2014. 384 7.2. Informative References 386 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 387 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 388 July 2006. 390 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 391 Correction (FEC) Framework", RFC 6363, October 2011. 393 [I-D.ietf-rmcat-cc-requirements] 394 Jesup, R., "Congestion Control Requirements For RMCAT", 395 draft-ietf-rmcat-cc-requirements-02 (work in progress), 396 February 2014. 398 [I-D.alvestrand-rmcat-congestion] 399 Holmer, S., Cicco, L., Mascolo, S., and H. Alvestrand, "A 400 Google Congestion Control Algorithm for Real-Time 401 Communication", draft-alvestrand-rmcat-congestion-02 (work 402 in progress), February 2014. 404 [I-D.johansson-rmcat-scream-cc] 405 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 406 for Multimedia", draft-johansson-rmcat-scream-cc-02 (work 407 in progress), June 2014. 409 [I-D.sarker-rmcat-eval-test] 410 Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test 411 Cases for Evaluating RMCAT Proposals", draft-sarker-rmcat- 412 eval-test-00 (work in progress), February 2014. 414 [Nagy14] Nagy, M., Singh, V., Ott, J., and L. Eggert, "Congestion 415 Control using FEC for Conversational Multimedia 416 Communication", Proc. of 5th ACM Internation Conference on 417 Multimedia Systems (MMSys 2014) , 3 2014. 419 [Devadoss08] 420 Devadoss, J., Singh, V., Ott, J., Liu, C., Wang, Y-K., and 421 I. Curcio, "Evaluation of Error Resilience Mechanisms for 422 3G Conversational Video", Proc. of IEEE International 423 Symposium on Multimedia (ISM 2008) , 3 2014. 425 [Holmer13] 426 Holmer, S., Shemer, M., and M. Paniconi, "Handling Packet 427 Loss in WebRTC", Proc. of IEEE International Conference on 428 Image Processing (ICIP 2013) , 9 2013. 430 Appendix A. Simulations 432 This document is based on the results published in [Nagy14]. See the 433 paper for ns-2 and testbed results; more results based on the 434 scenarios listed in [I-D.sarker-rmcat-eval-test] will be published 435 shorty. 437 Authors' Addresses 439 Varun Singh 440 Aalto University 441 School of Electrical Engineering 442 Otakaari 5 A 443 Espoo, FIN 02150 444 Finland 446 Email: varun@comnet.tkk.fi 447 URI: http://www.netlab.tkk.fi/~varun/ 449 Marcin Nagy 450 Aalto University 451 School of Electrical Engineering 452 Otakaari 5 A 453 Espoo, FIN 02150 454 Finland 456 Email: marcin.nagy@aalto.fi 457 Joerg Ott 458 Aalto University 459 School of Electrical Engineering 460 Otakaari 5 A 461 Espoo, FIN 02150 462 Finland 464 Email: jo@comnet.tkk.fi 466 Lars Eggert 467 NetApp 468 Sonnenallee 1 469 Kirchheim 85551 470 Germany 472 Phone: +49 151 12055791 473 Email: lars@netapp.com 474 URI: http://eggert.org/