idnits 2.17.1 draft-ietf-rtcweb-fec-05.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 (May 23, 2017) is 2530 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-04 Summary: 0 errors (**), 0 flaws (~~), 3 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 May 23, 2017 5 Expires: November 24, 2017 7 WebRTC Forward Error Correction Requirements 8 draft-ietf-rtcweb-fec-05 10 Abstract 12 This document provides information and requirements for how Forward 13 Error Correction (FEC) should be used by WebRTC applications. 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 November 24, 2017. 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 . . . . . . . . . . . . . . . . . . . 4 58 5. FEC for Video Content . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 5 60 5.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 5 61 6. FEC for Application Content . . . . . . . . . . . . . . . . . 6 62 7. Implementation Requirements . . . . . . . . . . . . . . . . . 6 63 8. Adaptive Use of FEC . . . . . . . . . . . . . . . . . . . . . 6 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 12.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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 client 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 By its name, FEC describes the sending of redundant information in an 90 outgoing packet stream so that information can still be recovered 91 even in the face of packet loss. There are multiple ways in which 92 this can be accomplished; this section enumerates the various 93 mechanisms and 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 by far the most flexible, each FEC packet 100 will have its own IP+UDP+RTP+FEC header, leading to additional 101 overhead of the FEC stream. 103 3.2. Redundant Encoding 105 This approach, as descibed in [RFC2198], allows for redundant data to 106 be piggybacked on an existing primary encoding, all in a single 107 packet. This redundant data may be an exact copy of a previous 108 packet, or for codecs that support variable-bitrate encodings, 109 possibly a smaller, lower-quality representation. In certain cases, 110 the redundant data could include multiple prior packets. 112 Since there is only a single set of packet headers, this approach 113 allows for a very efficient representation of primary + redundant 114 data. However, this savings is only realized when the data all fits 115 into a single packet (i.e. the size is less than a MTU). As a 116 result, this approach is generally not useful for video content. 118 3.3. Codec-Specific In-band FEC 120 Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867] support 121 their own in-band FEC mechanism, where redundant data is included in 122 the codec payload. 124 For Opus, packets deemed as important are re-encoded at a lower 125 bitrate and added to the subsequent packet, allowing partial recovery 126 of a lost packet. This scheme is fairly efficient; experiments 127 performed indicate that when Opus FEC is used, the overhead imposed 128 is about 20-30%, depending on the amount of protection needed. Note 129 that this mechanism can only carry redundancy information for the 130 immediately preceding packet; as such the decoder cannot fully 131 recover multiple consecutive lost packets, which can be a problem on 132 wireless networks. See [RFC6716], Section 2.1.7 for complete 133 details. 135 For AMR/AMR-WB, packets can contain copies or lower-quality encodings 136 of multiple prior audio frames. This mechanism is similar to the 137 [RFC2198] mechanism described above, but as it adds no additional 138 framing, it can be slightly more efficient. See [RFC4867], 139 Section 3.7.1 for details on this mechanism. 141 4. FEC for Audio Content 143 The following section provides guidance on how to best use FEC for 144 transmitting audio data. As indicated in Section 8 below, FEC should 145 only be activated if network conditions warrant it, or upon explicit 146 application request. 148 4.1. Recommended Mechanism 150 When using the Opus codec, use of the built-in Opus FEC mechanism is 151 RECOMMENDED. This provides reasonable protection of the audio stream 152 against typical losses, with modest overhead. Note that as indicated 153 above the built-in Opus FEC only provides single-frame redundancy; if 154 multi-packet protection is needed, the built-in FEC should be 155 combined with [RFC2198] redundancy to protect the N-2th, N-3rd, etc. 156 packets. 158 When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism 159 is RECOMMENDED. This provides slightly more efficient protection of 160 the audio stream than [RFC2198]. 162 When using variable-bitrate codecs without an internal FEC, [RFC2198] 163 redundant encoding with lower-fidelity version(s) of previous 164 packet(s) is RECOMMENDED. This provides reasonable protection of the 165 payload with moderate overhead. 167 When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198] 168 redundant encoding MAY be used, but note that this will result in a 169 potentially significant bitrate increase, and that suddenly 170 increasing bitrate to deal with losses from congestion may actually 171 make things worse. 173 Because of the lower packet rate of audio encodings, usually a single 174 packet per frame, use of a separate FEC stream comes with a higher 175 overhead than other mechanisms, and therefore is NOT RECOMMENDED. 177 4.2. Negotiating Support 179 Support for redundant encoding MUST be indicated by offering "red" as 180 a supported payload type in the offer. Answerers can reject the use 181 of redundant encoding by not including "red" as a supported payload 182 type in the answer. 184 Support for codec-specific FEC mechanisms are typically indicated via 185 "a=fmtp" parameters. 187 For Opus, a receiver MUST indicate that it is prepared to use 188 incoming FEC data with the "useinbandfec=1" parameter, as specified 189 in [RFC7587]. This parameter is declarative and can be negotiated 190 separately for either media direction. 192 For AMR/AMR-WB, support for redundant encoding, and the maximum 193 supported depth, are controlled by the 'max-red' parameter, as 194 specified in [RFC4867], Section 8.1. Receivers MUST include this 195 parameter, and set it to an appropriate value, as specified in 196 [3GPP.26.114], Table 6.3. 198 5. FEC for Video Content 200 The following section provides guidance on how to best use FEC for 201 transmitting video data. As indicated in Section 8 below, FEC should 202 only be activated if network conditions warrant it, or upon explicit 203 application request. 205 5.1. Recommended Mechanism 207 For video content, use of a separate FEC stream with the RTP payload 208 format described in [I-D.ietf-payload-flexible-fec-scheme] is 209 RECOMMENDED. The receiver can demultiplex the incoming FEC stream by 210 SSRC and correlate it with the primary stream via the SSRC field 211 present in the FEC header. 213 Support for protecting multiple primary streams with a single FEC 214 stream is complicated by WebRTC's 1-m-line-per-stream policy, which 215 does not allow for a m-line dedicated specifically to FEC. 217 5.2. Negotiating Support 219 To offer support for a SSRC-multiplexed FEC stream that is associated 220 with a given primary stream, the offerer MUST offer the formats 221 supported for the primary stream, as well as one of the formats 222 described in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1. 224 Use of FEC-only m-lines, and grouping using the SDP group mechanism 225 as described in [RFC5956], Section 4.1 is not currently defined for 226 WebRTC, and SHOULD NOT be offered. 228 Answerers can reject the use of SSRC-multiplexed FEC, by not 229 including FEC formats in the answer. 231 Answerers SHOULD reject any FEC-only m-lines, unless they 232 specifically know how to handle such a thing in a WebRTC context 233 (perhaps defined by a future version of the WebRTC specifications). 234 This ensures that implementations will not malfunction when said 235 future version of WebRTC enables offers of FEC-only m-lines. 237 6. FEC for Application Content 239 WebRTC also supports the ability to send generic application data, 240 and provides transport-level retransmission mechanisms to support 241 full and partial (e.g. timed) reliability. See 242 [I-D.ietf-rtcweb-data-channel] for details. 244 Because the application can control exactly what data to send, it has 245 the ability to monitor packet statistics and perform its own 246 application-level FEC, if necessary. 248 As a result, this document makes no recommendations regarding FEC for 249 the underlying data transport. 251 7. Implementation Requirements 253 To support the functionality recommended above, implementations MUST 254 be able to receive and make use of the relevant FEC formats for their 255 supported audio codecs, and MUST indicate this support, as described 256 in Section 4. Use of these formats when sending, as mentioned above, 257 is RECOMMENDED. 259 The general FEC mechanism described in 260 [I-D.ietf-payload-flexible-fec-scheme] SHOULD also be supported, as 261 mentioned in Section 5. 263 Implementations MAY support additional FEC mechanisms if desired, 264 e.g. [RFC5109]. 266 8. Adaptive Use of FEC 268 Since use of FEC always causes redundant data to be transmitted, this 269 will lead to less bandwidth available for the primary encoding when 270 in a bandwidth-constrained environment. This is in contrast to 271 methods like RTX [RFC4588], which only transmits redundant data when 272 necessary, at the cost of an extra roundtrip. 274 Given this, WebRTC implementations SHOULD consider using RTX instead 275 of FEC when RTT is low, and SHOULD only transmit the amount of FEC 276 needed to protect against the observed packet loss (which can be 277 determined, e.g., by monitoring transmit packet loss data from RTCP 278 Receiver Reports [RFC3550]), unless the application indicates it is 279 willing to pay a quality penalty to proactively avoid losses. 281 When using FEC with layered codecs, e.g., [RFC6386], where only base 282 layer frames are critical to the decoding of future frames, 283 implementations SHOULD only apply FEC to these base layer frames. 285 9. Security Considerations 287 This document makes recommendations regarding the use of FEC. 288 Generally, it should be noted that although applying redundancy is 289 often useful in protecting a stream against packet loss, if the loss 290 is caused by network congestion, the additional bandwidth used by the 291 redundant data may actually make the situation worse, and can lead to 292 significant degradation of the network. 294 Additional security considerations for each individual FEC mechanism 295 are enumerated in their respective documents. 297 10. IANA Considerations 299 This document requires no actions from IANA. 301 11. Acknowledgements 303 Several people provided significant input into this document, 304 including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, 305 Tim Terriberry, Magnus Westerlund, and Mo Zanaty. 307 12. References 309 12.1. Normative References 311 [I-D.ietf-payload-flexible-fec-scheme] 312 Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP 313 Payload Format for Flexible Forward Error Correction 314 (FEC)", draft-ietf-payload-flexible-fec-scheme-04 (work in 315 progress), March 2017. 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 323 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 324 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 325 DOI 10.17487/RFC2198, September 1997, 326 . 328 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 329 the Session Description Protocol", RFC 5956, 330 DOI 10.17487/RFC5956, September 2010, 331 . 333 12.2. Informative References 335 [I-D.ietf-rtcweb-data-channel] 336 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 337 Channels", draft-ietf-rtcweb-data-channel-13 (work in 338 progress), January 2015. 340 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 341 Jacobson, "RTP: A Transport Protocol for Real-Time 342 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 343 July 2003, . 345 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 346 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 347 DOI 10.17487/RFC4588, July 2006, 348 . 350 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 351 "RTP Payload Format and File Storage Format for the 352 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 353 (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, 354 April 2007, . 356 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 357 Correction", RFC 5109, DOI 10.17487/RFC5109, December 358 2007, . 360 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 361 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 362 Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, 363 . 365 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 366 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 367 September 2012, . 369 [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format 370 for the Opus Speech and Audio Codec", RFC 7587, 371 DOI 10.17487/RFC7587, June 2015, 372 . 374 Appendix A. Change log 376 Changes in draft -04: 378 o Discussion of layered codecs. 380 o Discussion of RTX. 382 o Clarified implementation requirements. 384 o FlexFEC MUST -> SHOULD. 386 o Clarified AMR max-red handling. 388 o Updated references. 390 Changes in draft -03: 392 o Added overhead stats for Opus. 394 o Expanded discussion of multi-packet FEC for Opus. 396 o Added discussion of AMR/AMR-WB. 398 o Removed discussion of ssrc-group. 400 o Referenced the data channel doc. 402 o Referenced the RTP/RTCP RFC. 404 o Several small edits based on feedback from Magnus. 406 Changes in draft -02: 408 o Expanded discussion of FEC-only m-lines, and how they should be 409 handled in offers and answers. 411 Changes in draft -01: 413 o Tweaked abstract/intro text that was ambiguously normative. 415 o Removed text on FEC for Opus in CELT mode. 417 o Changed RFC 2198 recommendation for PCMU to be MAY instead of NOT 418 RECOMMENDED, based on list feedback. 420 o Explicitly called out application data as something not addressed 421 in this document. 423 o Updated flexible-fec reference. 425 Changes in draft -00: 427 o Initial version, from sidebar conversation at IETF 90. 429 Author's Address 431 Justin Uberti 432 Google 433 747 6th St S 434 Kirkland, WA 98033 435 USA 437 Email: justin@uberti.name