idnits 2.17.1 draft-ietf-rtcweb-fec-06.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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 3, 2017) is 2482 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-payload-flexible-fec-scheme-05 == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-38 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Uberti 3 Internet-Draft Google 4 Intended status: Standards Track July 3, 2017 5 Expires: January 4, 2018 7 WebRTC Forward Error Correction Requirements 8 draft-ietf-rtcweb-fec-06 10 Abstract 12 This document provides information and requirements for how Forward 13 Error Correction (FEC) should be used by WebRTC implementations. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 4, 2018. 32 Copyright Notice 34 Copyright (c) 2017 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Types of FEC . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3.1. Separate FEC Stream . . . . . . . . . . . . . . . . . . . 3 53 3.2. Redundant Encoding . . . . . . . . . . . . . . . . . . . 3 54 3.3. Codec-Specific In-band FEC . . . . . . . . . . . . . . . 3 55 4. FEC for Audio Content . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 4 57 4.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 5 58 5. FEC for Video Content . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 5 60 5.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 6 61 6. FEC for Application Content . . . . . . . . . . . . . . . . . 6 62 7. Implementation Requirements . . . . . . . . . . . . . . . . . 6 63 8. Adaptive Use of FEC . . . . . . . . . . . . . . . . . . . . . 7 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 12.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 In situations where packet loss is high, or perfect media quality is 76 essential, Forward Error Correction (FEC) can be used to proactively 77 recover from packet losses. This specification provides guidance on 78 which FEC mechanisms to use, and how to use them, for WebRTC 79 implementations. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. Types of FEC 89 FEC describes the sending of redundant information in an outgoing 90 packet stream so that information can still be recovered even in the 91 face of packet loss. There are multiple ways in which this can be 92 accomplished; this section enumerates the various mechanisms and 93 describes their tradeoffs. 95 3.1. Separate FEC Stream 97 This approach, as described in [RFC5956], Section 4.3, sends FEC 98 packets as an independent SSRC-multiplexed stream, with its own SSRC 99 and payload type. While this approach can protect multiple packets 100 of the primary encoding with a single FEC packet, each FEC packet 101 will have its own IP+UDP+RTP+FEC header, and this overhead can be 102 excessive in some cases, e.g., when protecting each primary packet 103 with a FEC packet. 105 This approach allows for recovery of entire RTP packets, including 106 the full RTP header. 108 3.2. Redundant Encoding 110 This approach, as descibed in [RFC2198], allows for redundant data to 111 be piggybacked on an existing primary encoding, all in a single 112 packet. This redundant data may be an exact copy of a previous 113 packet, or for codecs that support variable-bitrate encodings, 114 possibly a smaller, lower-quality representation. In certain cases, 115 the redundant data could include multiple prior packets. 117 Since there is only a single set of packet headers, this approach 118 allows for a very efficient representation of primary + redundant 119 data. However, this savings is only realized when the data all fits 120 into a single packet (i.e. the size is less than a MTU). As a 121 result, this approach is generally not useful for video content. 123 As described in [RFC2198], Section 4, this approach cannot recover 124 certain parts of the RTP header, including the marker bit, CSRC 125 information, and header extensions. 127 3.3. Codec-Specific In-band FEC 129 Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867] support 130 their own in-band FEC mechanism, where redundant data is included in 131 the codec payload. 133 For Opus, packets deemed as important are re-encoded at a lower 134 bitrate and added to the subsequent packet, allowing partial recovery 135 of a lost packet. This scheme is fairly efficient; experiments 136 performed indicate that when Opus FEC is used, the overhead imposed 137 is about 20-30%, depending on the amount of protection needed. Note 138 that this mechanism can only carry redundancy information for the 139 immediately preceding packet; as such the decoder cannot fully 140 recover multiple consecutive lost packets, which can be a problem on 141 wireless networks. See [RFC6716], Section 2.1.7 for complete 142 details. 144 For AMR/AMR-WB, packets can contain copies or lower-quality encodings 145 of multiple prior audio frames. This mechanism is similar to the 146 [RFC2198] mechanism described above, but as it adds no additional 147 framing, it can be slightly more efficient. See [RFC4867], 148 Section 3.7.1 for details on this mechanism. 150 In-band FEC mechanisms cannot recover any of the RTP header. 152 4. FEC for Audio Content 154 The following section provides guidance on how to best use FEC for 155 transmitting audio data. As indicated in Section 8 below, FEC should 156 only be activated if network conditions warrant it, or upon explicit 157 application request. 159 4.1. Recommended Mechanism 161 When using variable-bitrate codecs without an internal FEC, [RFC2198] 162 redundant encoding with lower-fidelity version(s) of the previous 163 packet(s) is RECOMMENDED. This provides reasonable protection of the 164 payload with only moderate bitrate increase, as the redundant 165 encodings can be significantly smaller than the primary encoding. 167 When using the Opus codec, use of the built-in Opus FEC mechanism is 168 RECOMMENDED. This provides reasonable protection of the audio stream 169 against individual losses, with minimal overhead. Note that as 170 indicated above the built-in Opus FEC only provides single-frame 171 redundancy; if multi-packet protection is needed, the aforementioned 172 [RFC2198] redundancy with reduced-bitrate Opus encodings SHOULD be 173 used instead. 175 When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism 176 is RECOMMENDED. This provides slightly more efficient protection of 177 the audio stream than [RFC2198]. 179 When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198] 180 redundant encoding MAY be used, but note that this will result in a 181 potentially significant bitrate increase, and that suddenly 182 increasing bitrate to deal with losses from congestion may actually 183 make things worse. 185 Because of the lower packet rate of audio encodings, usually a single 186 packet per frame, use of a separate FEC stream comes with a higher 187 overhead than other mechanisms, and therefore is NOT RECOMMENDED. 189 As mentioned above, the recommended mechanisms do not allow recovery 190 of parts of the RTP header that may be important in certain audio 191 applications, e.g., CSRCs and RTP header extensions like those 192 specified in [RFC6464] and [RFC6465]. Implementations SHOULD account 193 for this and attempt to approximate this information, using an 194 approach similar to those described in [RFC2198], Section 4, and 195 [RFC6464], Section 5. 197 4.2. Negotiating Support 199 Support for redundant encoding of a given RTP stream SHOULD be 200 indicated by including audio/red [RFC2198] as an additional supported 201 media type for the associated m= section in the SDP offer [RFC3264]. 202 Answerers can reject the use of redundant encoding by not including 203 the audio/red media type in the corresponding m= section in the SDP 204 answer. 206 Support for codec-specific FEC mechanisms are typically indicated via 207 "a=fmtp" parameters. 209 For Opus, a receiver MUST indicate that it is prepared to use 210 incoming FEC data with the "useinbandfec=1" parameter, as specified 211 in [RFC7587]. This parameter is declarative and can be negotiated 212 separately for either media direction. 214 For AMR/AMR-WB, support for redundant encoding, and the maximum 215 supported depth, are controlled by the 'max-red' parameter, as 216 specified in [RFC4867], Section 8.1. Receivers MUST include this 217 parameter, and set it to an appropriate value, as specified in 218 [TS.26114], Table 6.3. 220 5. FEC for Video Content 222 The following section provides guidance on how to best use FEC for 223 transmitting video data. As indicated in Section 8 below, FEC should 224 only be activated if network conditions warrant it, or upon explicit 225 application request. 227 5.1. Recommended Mechanism 229 Video frames, due to their size, often require multiple RTP packets. 230 As discussed above, a separate FEC stream can protect multiple 231 packets with a single FEC packet. In addition, the "flexfec" FEC 232 mechanism described in [I-D.ietf-payload-flexible-fec-scheme] is also 233 capable of protecting multiple RTP streams via a single FEC stream, 234 including all the streams that are part of a BUNDLE 235 [I-D.ietf-mmusic-sdp-bundle-negotiation] group. As a result, for 236 video content, use of a separate FEC stream with the flexfec RTP 237 payload format is RECOMMENDED. 239 To process the incoming FEC stream, the receiver can demultiplex it 240 by SSRC, and then correlate it with the appropriate primary stream(s) 241 via the CSRC(s) present in the RTP header of flexfec repair packets, 242 or the SSRC field present in the FEC header of flexfec retransmission 243 packets. 245 5.2. Negotiating Support 247 Support for a SSRC-multiplexed flexfec stream to protect a given RTP 248 stream SHOULD be indicated by including one of the formats described 249 in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an 250 additional supported media type for the associated m= section in the 251 SDP offer [RFC3264]. As mentioned above, when BUNDLE is used, only a 252 single flexfec repair stream will be created for each BUNDLE group, 253 even if flexfec is negotiated for each primary stream. 255 Answerers can reject the use of SSRC-multiplexed FEC, by not 256 including the offered FEC formats in the corresponding m= section in 257 the SDP answer. 259 Use of FEC-only m-lines, and grouping using the SDP group mechanism 260 as described in [RFC5956], Section 4.1 is not currently defined for 261 WebRTC, and SHOULD NOT be offered. 263 Answerers SHOULD reject any FEC-only m-lines, unless they 264 specifically know how to handle such a thing in a WebRTC context 265 (perhaps defined by a future version of the WebRTC specifications). 267 6. FEC for Application Content 269 WebRTC also supports the ability to send generic application data, 270 and provides transport-level retransmission mechanisms to support 271 full and partial (e.g. timed) reliability. See 272 [I-D.ietf-rtcweb-data-channel] for details. 274 Because the application can control exactly what data to send, it has 275 the ability to monitor packet statistics and perform its own 276 application-level FEC, if necessary. 278 As a result, this document makes no recommendations regarding FEC for 279 the underlying data transport. 281 7. Implementation Requirements 283 To support the functionality recommended above, implementations MUST 284 be able to receive and make use of the relevant FEC formats for their 285 supported audio codecs, and MUST indicate this support, as described 286 in Section 4. Use of these formats when sending, as mentioned above, 287 is RECOMMENDED. 289 The general FEC mechanism described in 290 [I-D.ietf-payload-flexible-fec-scheme] SHOULD also be supported, as 291 mentioned in Section 5. 293 Implementations MAY support additional FEC mechanisms if desired, 294 e.g. [RFC5109]. 296 8. Adaptive Use of FEC 298 Since use of FEC always causes redundant data to be transmitted, this 299 will lead to less bandwidth available for the primary encoding when 300 in a bandwidth-constrained environment. This is in contrast to 301 methods like RTX [RFC4588] or flexfec 302 [I-D.ietf-payload-flexible-fec-scheme] retransmissions, which only 303 transmit redundant data when necessary, at the cost of an extra 304 roundtrip. 306 Given this, WebRTC implementations SHOULD consider using RTX or 307 flexfec retransmissions instead of FEC when RTT is low, and SHOULD 308 only transmit the amount of FEC needed to protect against the 309 observed packet loss (which can be determined, e.g., by monitoring 310 transmit packet loss data from RTCP Receiver Reports [RFC3550]), 311 unless the application indicates it is willing to pay a quality 312 penalty to proactively avoid losses. 314 Note that when probing bandwidth, i.e., speculatively sending extra 315 data to determine if additional link capacity exists, FEC SHOULD be 316 used in all cases. Given that extra data is going to be sent 317 regardless, it makes sense to have that data protect the primary 318 payload; in addition, FEC can be applied in a way that increases 319 bandwidth only modestly, which is necessary when probing. 321 When using FEC with layered codecs, e.g., [RFC6386], where only base 322 layer frames are critical to the decoding of future frames, 323 implementations SHOULD only apply FEC to these base layer frames. 325 9. Security Considerations 327 This document makes recommendations regarding the use of FEC. 328 Generally, it should be noted that although applying redundancy is 329 often useful in protecting a stream against packet loss, if the loss 330 is caused by network congestion, the additional bandwidth used by the 331 redundant data may actually make the situation worse, and can lead to 332 significant degradation of the network. 334 As described in [RFC3711], Section 10, the default processing when 335 using FEC with SRTP is to perform FEC followed by SRTP at the sender, 336 and SRTP followed by FEC at the receiver. This ordering is used for 337 all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as 338 described in [RFC5764], Section 4.1.2. 340 Additional security considerations for each individual FEC mechanism 341 are enumerated in their respective documents. 343 10. IANA Considerations 345 This document requires no actions from IANA. 347 11. Acknowledgements 349 Several people provided significant input into this document, 350 including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, 351 Tim Terriberry, Magnus Westerlund, and Mo Zanaty. 353 12. References 355 12.1. Normative References 357 [I-D.ietf-payload-flexible-fec-scheme] 358 Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP 359 Payload Format for Flexible Forward Error Correction 360 (FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in 361 progress), July 2017. 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 369 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 370 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 371 DOI 10.17487/RFC2198, September 1997, 372 . 374 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 375 with Session Description Protocol (SDP)", RFC 3264, 376 DOI 10.17487/RFC3264, June 2002, 377 . 379 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 380 "RTP Payload Format and File Storage Format for the 381 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 382 (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, 383 April 2007, . 385 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 386 the Session Description Protocol", RFC 5956, 387 DOI 10.17487/RFC5956, September 2010, 388 . 390 [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format 391 for the Opus Speech and Audio Codec", RFC 7587, 392 DOI 10.17487/RFC7587, June 2015, 393 . 395 12.2. Informative References 397 [I-D.ietf-mmusic-sdp-bundle-negotiation] 398 Holmberg, C., Alvestrand, H., and C. Jennings, 399 "Negotiating Media Multiplexing Using the Session 400 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 401 negotiation-38 (work in progress), April 2017. 403 [I-D.ietf-rtcweb-data-channel] 404 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 405 Channels", draft-ietf-rtcweb-data-channel-13 (work in 406 progress), January 2015. 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, DOI 10.17487/RFC3550, 411 July 2003, . 413 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 414 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 415 RFC 3711, DOI 10.17487/RFC3711, March 2004, 416 . 418 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 419 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 420 DOI 10.17487/RFC4588, July 2006, 421 . 423 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 424 Correction", RFC 5109, DOI 10.17487/RFC5109, December 425 2007, . 427 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 428 for Establishing a Secure Real-time Transport Protocol 429 (SRTP) Security Context Using Datagram Transport Layer 430 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 431 2010, . 433 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 434 Security (DTLS) Extension to Establish Keys for the Secure 435 Real-time Transport Protocol (SRTP)", RFC 5764, 436 DOI 10.17487/RFC5764, May 2010, 437 . 439 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 440 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 441 Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, 442 . 444 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 445 Transport Protocol (RTP) Header Extension for Client-to- 446 Mixer Audio Level Indication", RFC 6464, 447 DOI 10.17487/RFC6464, December 2011, 448 . 450 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 451 time Transport Protocol (RTP) Header Extension for Mixer- 452 to-Client Audio Level Indication", RFC 6465, 453 DOI 10.17487/RFC6465, December 2011, 454 . 456 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 457 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 458 September 2012, . 460 [TS.26114] 461 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 462 telephony; Media handling and interaction", 3GPP TS 26.114 463 13.3.0, March 2016. 465 Appendix A. Change log 467 Changes in draft -06: 469 o Discuss how multiple streams can be protected by a single FlexFEC 470 stream. 472 o Discuss FEC for bandwidth probing. 474 o Add note about recovery of RTP headers and header extensions. 476 o Add note about FEC/SRTP ordering. 478 o Clarify flexfec demux text, and mention retransmits. 480 o Clarify text regarding offers/answers. 482 o Make RFC2198 support SHOULD strength. 484 o Clean up references. 486 Changes in draft -05: 488 o No changes. 490 Changes in draft -04: 492 o Discussion of layered codecs. 494 o Discussion of RTX. 496 o Clarified implementation requirements. 498 o FlexFEC MUST -> SHOULD. 500 o Clarified AMR max-red handling. 502 o Updated references. 504 Changes in draft -03: 506 o Added overhead stats for Opus. 508 o Expanded discussion of multi-packet FEC for Opus. 510 o Added discussion of AMR/AMR-WB. 512 o Removed discussion of ssrc-group. 514 o Referenced the data channel doc. 516 o Referenced the RTP/RTCP RFC. 518 o Several small edits based on feedback from Magnus. 520 Changes in draft -02: 522 o Expanded discussion of FEC-only m-lines, and how they should be 523 handled in offers and answers. 525 Changes in draft -01: 527 o Tweaked abstract/intro text that was ambiguously normative. 529 o Removed text on FEC for Opus in CELT mode. 531 o Changed RFC 2198 recommendation for PCMU to be MAY instead of NOT 532 RECOMMENDED, based on list feedback. 534 o Explicitly called out application data as something not addressed 535 in this document. 537 o Updated flexible-fec reference. 539 Changes in draft -00: 541 o Initial version, from sidebar conversation at IETF 90. 543 Author's Address 545 Justin Uberti 546 Google 547 747 6th St S 548 Kirkland, WA 98033 549 USA 551 Email: justin@uberti.name