idnits 2.17.1 draft-singh-rmcat-adaptive-fec-02.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 (April 30, 2015) is 3283 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-09 == Outdated reference: A later version (-20) exists of draft-ietf-payload-flexible-fec-scheme-00 == Outdated reference: A later version (-03) exists of draft-alvestrand-rmcat-congestion-02 == Outdated reference: A later version (-10) exists of draft-ietf-rmcat-eval-test-00 Summary: 0 errors (**), 0 flaws (~~), 5 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: November 1, 2015 Aalto University 6 L. Eggert 7 NetApp 8 April 30, 2015 10 Congestion Control Using FEC for Conversational Media 11 draft-singh-rmcat-adaptive-fec-02 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 November 1, 2015. 44 Copyright Notice 46 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Framework . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. Applicability to other RMCAT Schemes . . . . . . . . . . 9 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 7.2. Informative References . . . . . . . . . . . . . . . . . 11 74 Appendix A. Simulations . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 Figure 2 shows the timeline of enabling and disabling FEC. The main 153 idea behind using FEC for congestion control is as follows: the 154 sending endpoint chooses a high FEC rate to aggressively probe for 155 available capacity and conversely chooses a low FEC rate to 156 conservatively probe for available capacity. During the ramp up, if 157 a packet is lost and the FEC packet arrives in time for decoding, the 158 receiver is be able to recover the lost packet; if no packet is lost, 159 the sender is able to increase the media encoding rate by swapping 160 out a part of the FEC rate. This method can be especially useful 161 when the transmission rate is close to the bottleneck link rate: by 162 choosing an appropriate FEC rate, the endpoint is able to probe for 163 available capacity without changing the target media rate and 164 therefore not affecting the user-experience. 166 Hence, the congestion control algorithm is always able to probe for 167 available capacity, as improved reliability compensates for possible 168 errors resulting from probing for additional capacity (i.e., increase 169 in observed latency and/or losses). 171 ^ ......... 172 | / \ / 173 t |/ \ / 174 h | +===+===+=\=+ / 175 r | | F | | \| +===+ +==/+ 176 o +===+---+ | \...........|.F.|...|./F|===+ 177 u | | | | | +===+===+---+===+---+---+ 178 g | | | | | | F | | | | | | 179 h | | | | |===+---+ | | | | | 180 p | | | | | | | | | | | | 181 u | | | | | | | | | | | | 182 t | | | | | | | | | | | | 183 | s | p | i | s | d | p | i | p | s | p | i | 184 +---+---+---+---+---+---+---+---+---+---+---+--> 185 time 187 Key: 188 +===+ Media with minimal FEC for error protection 190 +===+ 191 | F | Media with FEC for probing and error protection 192 +---+ 194 .... 195 / \ Available capacity 197 d,s,p,i: are the states: Decrease, Stay, Probe, Increase 199 Figure 2: Congestion Control enabling FEC. 201 +------------+ (B) Good conditions +-----------+ 202 | |------------------------------------>| | 203 | STEADY | | PROBE | 204 | |<------------------------------------| | 205 +------------+ Probed, but Loss recovered +-----------+ 206 /\ | | /\ | 207 | |(A) | | | 208 | |_______________________________________________| | |(C) 209 (B) | | (A) | | 210 | \/ (B) | \/ 211 +------------+ +------------+ 212 | | (A) Unstable conditions | | 213 | REDUCE |<------------------------------------| INCREASE | 214 | | | | 215 +------------+ +------------+ 217 Figure 3: State machine of a Congestion Control enabling FEC. 219 3.1. States 221 The Figure 3 illustrates the the state machine of a congestion 222 control algorithm incorporating FEC for probing. The state 223 transitions occur based on the information reported in the feedback 224 packet. In Figure 3 (A) indicates congestion, i.e., the congestion 225 control observes increasing delay and/or packet loss, or any other 226 congestion metric, and in response the congestion control reduces the 227 transmission rate. In Figure 3 (B) occurs when the congestion cues 228 report improvement in congestion metrics, and in response the 229 congestion cue increases the transmission rate. For probing using 230 FEC, the congestion control needs to map to the following 4 states: 231 STEADY, PROBE, INCREASE, and REDUCE. 233 o STEADY state: The congestion control keeps the same target media 234 rate and no additional FEC packets are generated for probing. 235 This is a transient state, after which the congestion control 236 either attempts to increase the transmission rate, or observes 237 congestion and reduces the transmission rate. 239 o REDUCE state: The congestion control reduces the transmission rate 240 based on the observed congestion cues, and generated no additional 241 FEC packets than the minimum required for error-resilience. If in 242 subsequent reports the conditions improve, the congestion control 243 can directly transition to the PROBE state. 245 o PROBE state: The congestion control observes no congestion for two 246 reporting intervals (i.e., the transmission rate should be 247 increased). The endpoint maintains the same target media bit 248 rate, and instead increases the amount of FEC packets, therby 249 increasing the transmission rate. 251 o INCREASE state: The endpoint is sending FEC packets and the 252 congestion control observes no congestion (as reported in RTCP 253 feedback), the media transmission rate is increased while 254 maintaining minimal amount of FEC for error protection. In this 255 case, the combined transmission rate (FEC+media) may remain the 256 same as in the PROBE state. If the feedback reports packet loss, 257 but some of these lost packets are recovered by the FEC packets, 258 the congestion control can keep the same media bit rate and adjust 259 the amount of FEC (compared to the previous PROBE state). If 260 congestion is observed (the target rate calculated by the 261 congestion control is much lower than the current media rate), the 262 congestion control can transition to the REDUCE state and decrease 263 the transmission rate. 265 3.2. Framework 267 The Figure 4 shows the interaction between the rate control module, 268 the RTP and the FEC module. 270 At the sender, the rate control module calculates the new bit rate. 271 If the new bit rate is higher than the previous than the previous bit 272 rate indicates to the FEC module that the congestion control intends 273 to probe. The FEC module depending on its internal state machine 274 decides to add FEC for probing or not. Thereafter it indicates to 275 the rate control module the bit rate remaining for the RTP media 276 stream, which may be less than equal to the calculated bit rate. 278 At the reciver, the FEC module reconstructs lost packets in the 279 primary stream from the packets received in the repair stream. If 280 packets are repair it generates the post-repair loss report 281 (discussed in Section 3.3) for the corresponding RTP packets. 283 At the sender, The FEC module also receives the RTCP Feedback related 284 to the primary stream and any post-repair loss report. It uses the 285 information from these RTCP reports to calculate the effectiveness of 286 FEC for congestion control and is also the basis for changing its 287 internal state. 289 + - - - - - - - - - - - - - - - - - - - - - - - -+ 290 | +--------------------------------------------+ | 291 | Media Encoder/Decoder | 292 | +--------------------------------------------+ | 293 | | 294 | +- -- -- -- -- -- -- -+ +- -- -- -- -+ | 295 | Rate Control | | RTP | 296 | | Module | | | | 297 +- -- -- -- -- -- -- -+ +- -- -- -- -+ 298 | ^ | | | 299 | | | Source 300 | | R +--------------------+ | RTP | 301 | T | | 302 | | C | | | 303 | P | | 304 | | +----------+ +----------------+ | 305 | F | FEC Code |<--->| FEC Module | 306 | | B +----------+ +----------------+ | 307 | | | | 308 | |------------------------+ | | | 309 | RTCP FB Repair | | Source 310 | | RTP | | RTP | 311 | | | 312 | +--------------------------------------------+ | 313 | RTP Processing Layer | 314 | | (Queue) | | 315 +--------------------------------------------+ 316 | | | 317 +--------------------------------------------+ 318 | | Transport Layer (UDP) | | 319 +--------------------------------------------+ 320 | | | 321 +--------------------------------------------+ 322 | | IP | | 323 +--------------------------------------------+ 324 | | 325 | Endpoint | 326 + - - - - - - - - - - - - - - - - - - - - - - - + 328 Figure 4: Interaction of Congestion Control and FEC Module. 330 3.3. FEC Scheme 332 [RFC6363] describes a framework for using Forward Error Correction 333 (FEC) codes with RTP and allows any FEC code to be used with the 334 framework. For this proposal, the FEC packets are created by XORing 335 RTP media packets, the resulting redundant RTP packets are encoded 336 using the scheme defined in [I-D.ietf-payload-flexible-fec-scheme]. 338 The endpoint MAY use a single-frame FEC (1-dimensional) or a multi- 339 frame FEC (2-dimensional) for protecting the primary RTP stream. A 340 single-frame FEC protects against a single packet loss and fails when 341 burst loss occurs. Using multi-frame FEC helps mitigate these issues 342 at the cost of higher overhead and latency in recovering lost 343 packets. [Holmer13] shows examples of using a single- and multi- 344 frame FEC. 346 The receiving endpoint may report the post-repair loss (or residual 347 loss) using either the report block defined in [RFC5725] (Run-length 348 encoding of packets repaired) or in 349 [I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count] (packet count of 350 repaired packets). 352 Additionally, the receiving may report the occurance of losses and 353 discards via a run-length encoding (RLE) of lost [RFC3611] 354 (Section 4.1), which enables the sender to detect the burst loss 355 length and apply appropriate FEC scheme. 357 Packet that arrive too late to be played out by the receiver are 358 discarded by the de-jitter buffer. Typically, the de-jitter buffer 359 adjust the playout delay based on the observed frame inter-arrival 360 delay, so that packets are played out smoothly. Reporting RLE of 361 discarded packets [RFC7097] may further enable a sender to detect 362 losses that occur after packet discards. 364 3.4. Applicability to other RMCAT Schemes 366 [Open issue: The current implementation is delay based and is 367 documented in [Nagy14]. However, we would like to generalize the 368 concept and apply it to different RMCAT algorithms for e.g., Google's 369 Congestion Control algorithm [I-D.alvestrand-rmcat-congestion], 370 SCReaM [I-D.johansson-rmcat-scream-cc], etc.] 372 4. Security Considerations 374 The security considerations of [RFC3550], RTP/AVPF profile for rapid 375 RTCP feedback [RFC4585], circuit breaker 376 [I-D.ietf-avtcore-rtp-circuit-breakers], and Generic Forward Error 377 Correction [RFC5109] apply. 379 If non-authenticated RTCP reports are used, an on-path attacker can 380 send forged RTCP feedback packets that can disrupt the operation of 381 the underlying congestion control. Additionally, the forged packets 382 can either indicate no packet loss causing the congestion control to 383 ramp-up quickly, or indicate high packet loss or RTT causing the 384 circuit breaker to trigger. 386 5. IANA Considerations 388 There are no IANA impacts in this memo. 390 6. Acknowledgements 392 This document is based on the results published in [Nagy14]. 394 The work of Varun Singh, and Joerg Ott has been partially supported 395 by the European Institute of Innovation and Technology (EIT) ICT Labs 396 activity RCLD 11882. The views expressed here are those of the 397 author(s) only. Neither the European Commission nor the EITICT labs 398 is liable for any use that may be made of the information in this 399 document. 401 7. References 403 7.1. Normative References 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 409 Jacobson, "RTP: A Transport Protocol for Real-Time 410 Applications", STD 64, RFC 3550, July 2003. 412 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 413 Video Conferences with Minimal Control", STD 65, RFC 3551, 414 July 2003. 416 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 417 Protocol Extended Reports (RTCP XR)", RFC 3611, November 418 2003. 420 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 421 "Extended RTP Profile for Real-time Transport Control 422 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 423 2006. 425 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 426 Real-Time Transport Control Protocol (RTCP): Opportunities 427 and Consequences", RFC 5506, April 2009. 429 [I-D.ietf-avtcore-rtp-circuit-breakers] 430 Perkins, C. and V. Singh, "Multimedia Congestion Control: 431 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 432 avtcore-rtp-circuit-breakers-09 (work in progress), March 433 2015. 435 [I-D.ietf-payload-flexible-fec-scheme] 436 Singh, V., Begen, A., and M. Zanaty, "RTP Payload Format 437 for Non-Interleaved and Interleaved Parity Forward Error 438 Correction (FEC)", draft-ietf-payload-flexible-fec- 439 scheme-00 (work in progress), February 2015. 441 [I-D.ietf-xrblock-rtcp-xr-post-repair-loss-count] 442 Huang, R. and V. Singh, "RTP Control Protocol (RTCP) 443 Extended Report (XR) for Post-Repair Loss Count Metrics", 444 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11 (work 445 in progress), February 2015. 447 7.2. Informative References 449 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 450 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 451 July 2006. 453 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 454 Correction (FEC) Framework", RFC 6363, October 2011. 456 [I-D.ietf-rmcat-cc-requirements] 457 Jesup, R. and Z. Sarker, "Congestion Control Requirements 458 for Interactive Real-Time Media", draft-ietf-rmcat-cc- 459 requirements-09 (work in progress), December 2014. 461 [I-D.alvestrand-rmcat-congestion] 462 Holmer, S., Cicco, L., Mascolo, S., and H. Alvestrand, "A 463 Google Congestion Control Algorithm for Real-Time 464 Communication", draft-alvestrand-rmcat-congestion-02 (work 465 in progress), February 2014. 467 [I-D.johansson-rmcat-scream-cc] 468 Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 469 for Multimedia", draft-johansson-rmcat-scream-cc-05 (work 470 in progress), March 2015. 472 [I-D.ietf-rmcat-eval-test] 473 Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test 474 Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- 475 eval-test-00 (work in progress), August 2014. 477 [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error 478 Correction", RFC 5109, December 2007. 480 [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE 481 Report Block Type for RTP Control Protocol (RTCP) Extended 482 Reports (XRs)", RFC 5725, February 2010. 484 [RFC7097] Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol 485 (RTCP) Extended Report (XR) for RLE of Discarded Packets", 486 RFC 7097, January 2014. 488 [Nagy14] Nagy, M., Singh, V., Ott, J., and L. Eggert, "Congestion 489 Control using FEC for Conversational Multimedia 490 Communication", Proc. of 5th ACM Internation Conference on 491 Multimedia Systems (MMSys 2014) , 3 2014. 493 [Devadoss08] 494 Devadoss, J., Singh, V., Ott, J., Liu, C., Wang, Y-K., and 495 I. Curcio, "Evaluation of Error Resilience Mechanisms for 496 3G Conversational Video", Proc. of IEEE International 497 Symposium on Multimedia (ISM 2008) , 3 2014. 499 [Holmer13] 500 Holmer, S., Shemer, M., and M. Paniconi, "Handling Packet 501 Loss in WebRTC", Proc. of IEEE International Conference on 502 Image Processing (ICIP 2013) , 9 2013. 504 Appendix A. Simulations 506 This document is based on the results published in [Nagy14]. See the 507 paper for ns-2 and testbed results; more results based on the 508 scenarios listed in [I-D.ietf-rmcat-eval-test] will be published 509 shorty. 511 Authors' Addresses 513 Varun Singh 514 Aalto University 515 School of Electrical Engineering 516 Otakaari 5 A 517 Espoo, FIN 02150 518 Finland 520 Email: varun@comnet.tkk.fi 521 URI: http://www.netlab.tkk.fi/~varun/ 523 Marcin Nagy 524 Aalto University 525 School of Electrical Engineering 526 Otakaari 5 A 527 Espoo, FIN 02150 528 Finland 530 Email: marcin.nagy@aalto.fi 531 Joerg Ott 532 Aalto University 533 School of Electrical Engineering 534 Otakaari 5 A 535 Espoo, FIN 02150 536 Finland 538 Email: jo@comnet.tkk.fi 540 Lars Eggert 541 NetApp 542 Sonnenallee 1 543 Kirchheim 85551 544 Germany 546 Phone: +49 151 12055791 547 Email: lars@netapp.com 548 URI: http://eggert.org/