idnits 2.17.1 draft-ietf-rtcweb-fec-08.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 (March 2, 2018) is 2247 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-48 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 March 2, 2018 5 Expires: September 3, 2018 7 WebRTC Forward Error Correction Requirements 8 draft-ietf-rtcweb-fec-08 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 https://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 September 3, 2018. 32 Copyright Notice 34 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . 7 63 8. Adaptive Use of FEC . . . . . . . . . . . . . . . . . . . . . 7 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . 11 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", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in BCP 86 14 [RFC2119] [RFC8174] when, and only when, they appear in all 87 capitals, as shown here. 89 3. Types of FEC 91 FEC describes the sending of redundant information in an outgoing 92 packet stream so that information can still be recovered even in the 93 face of packet loss. There are multiple ways in which this can be 94 accomplished; this section enumerates the various mechanisms and 95 describes their tradeoffs. 97 3.1. Separate FEC Stream 99 This approach, as described in [RFC5956], Section 4.3, sends FEC 100 packets as an independent SSRC-multiplexed stream, with its own SSRC 101 and payload type. While this approach can protect multiple packets 102 of the primary encoding with a single FEC packet, each FEC packet 103 will have its own IP+UDP+RTP+FEC header, and this overhead can be 104 excessive in some cases, e.g., when protecting each primary packet 105 with a FEC packet. 107 This approach allows for recovery of entire RTP packets, including 108 the full RTP header. 110 3.2. Redundant Encoding 112 This approach, as descibed in [RFC2198], allows for redundant data to 113 be piggybacked on an existing primary encoding, all in a single 114 packet. This redundant data may be an exact copy of a previous 115 packet, or for codecs that support variable-bitrate encodings, 116 possibly a smaller, lower-quality representation. In certain cases, 117 the redundant data could include multiple prior packets. 119 Since there is only a single set of packet headers, this approach 120 allows for a very efficient representation of primary + redundant 121 data. However, this savings is only realized when the data all fits 122 into a single packet (i.e. the size is less than a MTU). As a 123 result, this approach is generally not useful for video content. 125 As described in [RFC2198], Section 4, this approach cannot recover 126 certain parts of the RTP header, including the marker bit, CSRC 127 information, and header extensions. 129 3.3. Codec-Specific In-band FEC 131 Some audio codecs, notably Opus [RFC6716] and AMR [RFC4867], support 132 their own in-band FEC mechanism, where redundant data is included in 133 the codec payload. 135 For Opus, packets deemed as important are re-encoded at a lower 136 bitrate and added to the subsequent packet, allowing partial recovery 137 of a lost packet. This scheme is fairly efficient; experiments 138 performed indicate that when Opus FEC is used, the overhead imposed 139 is about 20-30%, depending on the amount of protection needed. Note 140 that this mechanism can only carry redundancy information for the 141 immediately preceding packet; as such the decoder cannot fully 142 recover multiple consecutive lost packets, which can be a problem on 143 wireless networks. See [RFC6716], Section 2.1.7 for complete 144 details. 146 For AMR/AMR-WB, packets can contain copies or lower-quality encodings 147 of multiple prior audio frames. This mechanism is similar to the 148 [RFC2198] mechanism described above, but as it adds no additional 149 framing, it can be slightly more efficient. See [RFC4867], 150 Section 3.7.1 for details on this mechanism. 152 In-band FEC mechanisms cannot recover any of the RTP header. 154 4. FEC for Audio Content 156 The following section provides guidance on how to best use FEC for 157 transmitting audio data. As indicated in Section 8 below, FEC should 158 only be activated if network conditions warrant it, or upon explicit 159 application request. 161 4.1. Recommended Mechanism 163 When using variable-bitrate codecs without an internal FEC, [RFC2198] 164 redundant encoding with lower-fidelity version(s) of the previous 165 packet(s) is RECOMMENDED. This provides reasonable protection of the 166 payload with only moderate bitrate increase, as the redundant 167 encodings can be significantly smaller than the primary encoding. 169 When using the Opus codec, use of the built-in Opus FEC mechanism is 170 RECOMMENDED. This provides reasonable protection of the audio stream 171 against individual losses, with minimal overhead. Note that, as 172 indicated above, the built-in Opus FEC only provides single-frame 173 redundancy; if multi-packet protection is needed, the aforementioned 174 [RFC2198] redundancy with reduced-bitrate Opus encodings SHOULD be 175 used instead. 177 When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism 178 is RECOMMENDED. This provides slightly more efficient protection of 179 the audio stream than [RFC2198]. 181 When using constant-bitrate codecs, e.g. PCMU, use of [RFC2198] 182 redundant encoding MAY be used, but note that this will result in a 183 potentially significant bitrate increase, and that suddenly 184 increasing bitrate to deal with losses from congestion may actually 185 make things worse. 187 Because of the lower packet rate of audio encodings, usually a single 188 packet per frame, use of a separate FEC stream comes with a higher 189 overhead than other mechanisms, and therefore is NOT RECOMMENDED. 191 As mentioned above, the recommended mechanisms do not allow recovery 192 of parts of the RTP header that may be important in certain audio 193 applications, e.g., CSRCs and RTP header extensions like those 194 specified in [RFC6464] and [RFC6465]. Implementations SHOULD account 195 for this and attempt to approximate this information, using an 196 approach similar to those described in [RFC2198], Section 4, and 197 [RFC6464], Section 5. 199 4.2. Negotiating Support 201 Support for redundant encoding of a given RTP stream SHOULD be 202 indicated by including audio/red [RFC2198] as an additional supported 203 media type for the associated m= section in the SDP offer [RFC3264]. 204 Answerers can reject the use of redundant encoding by not including 205 the audio/red media type in the corresponding m= section in the SDP 206 answer. 208 Support for codec-specific FEC mechanisms are typically indicated via 209 "a=fmtp" parameters. 211 For Opus, a receiver MUST indicate that it is prepared to use 212 incoming FEC data with the "useinbandfec=1" parameter, as specified 213 in [RFC7587]. This parameter is declarative and can be negotiated 214 separately for either media direction. 216 For AMR/AMR-WB, support for redundant encoding, and the maximum 217 supported depth, are controlled by the 'max-red' parameter, as 218 specified in [RFC4867], Section 8.1. Receivers MUST include this 219 parameter, and set it to an appropriate value, as specified in 220 [TS.26114], Table 6.3. 222 5. FEC for Video Content 224 The following section provides guidance on how to best use FEC for 225 transmitting video data. As indicated in Section 8 below, FEC should 226 only be activated if network conditions warrant it, or upon explicit 227 application request. 229 5.1. Recommended Mechanism 231 Video frames, due to their size, often require multiple RTP packets. 232 As discussed above, a separate FEC stream can protect multiple 233 packets with a single FEC packet. In addition, the "flexfec" FEC 234 mechanism described in [I-D.ietf-payload-flexible-fec-scheme] is also 235 capable of protecting multiple RTP streams via a single FEC stream, 236 including all the streams that are part of a BUNDLE 237 [I-D.ietf-mmusic-sdp-bundle-negotiation] group. As a result, for 238 video content, use of a separate FEC stream with the flexfec RTP 239 payload format is RECOMMENDED. 241 To process the incoming FEC stream, the receiver can demultiplex it 242 by SSRC, and then correlate it with the appropriate primary stream(s) 243 via the CSRC(s) present in the RTP header of flexfec repair packets, 244 or the SSRC field present in the FEC header of flexfec retransmission 245 packets. 247 5.2. Negotiating Support 249 Support for a SSRC-multiplexed flexfec stream to protect a given RTP 250 stream SHOULD be indicated by including one of the formats described 251 in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an 252 additional supported media type for the associated m= section in the 253 SDP offer [RFC3264]. As mentioned above, when BUNDLE is used, only a 254 single flexfec repair stream will be created for each BUNDLE group, 255 even if flexfec is negotiated for each primary stream. 257 Answerers can reject the use of SSRC-multiplexed FEC, by not 258 including the offered FEC formats in the corresponding m= section in 259 the SDP answer. 261 Use of FEC-only m-lines, and grouping using the SDP group mechanism 262 as described in [RFC5956], Section 4.1 is not currently defined for 263 WebRTC, and SHOULD NOT be offered. 265 Answerers SHOULD reject any FEC-only m-lines, unless they 266 specifically know how to handle such a thing in a WebRTC context 267 (perhaps defined by a future version of the WebRTC specifications). 269 6. FEC for Application Content 271 WebRTC also supports the ability to send generic application data, 272 and provides transport-level retransmission mechanisms to support 273 full and partial (e.g. timed) reliability. See 274 [I-D.ietf-rtcweb-data-channel] for details. 276 Because the application can control exactly what data to send, it has 277 the ability to monitor packet statistics and perform its own 278 application-level FEC, if necessary. 280 As a result, this document makes no recommendations regarding FEC for 281 the underlying data transport. 283 7. Implementation Requirements 285 To support the functionality recommended above, implementations MUST 286 be able to receive and make use of the relevant FEC formats for their 287 supported audio codecs, and MUST indicate this support, as described 288 in Section 4. Use of these formats when sending, as mentioned above, 289 is RECOMMENDED. 291 The general FEC mechanism described in 292 [I-D.ietf-payload-flexible-fec-scheme] SHOULD also be supported, as 293 mentioned in Section 5. 295 Implementations MAY support additional FEC mechanisms if desired, 296 e.g., [RFC5109]. 298 8. Adaptive Use of FEC 300 Because use of FEC always causes redundant data to be transmitted, 301 and the total amount of data must remain within any bandwidth limits 302 indicated by congestion control and the receiver, this will lead to 303 less bandwidth available for the primary encoding, even when the 304 redundant data is not being used. This is in contrast to methods 305 like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] 306 retransmissions, which only transmit redundant data when necessary, 307 at the cost of an extra roundtrip. 309 Given this, WebRTC implementations SHOULD consider using RTX or 310 flexfec retransmissions instead of FEC when RTT is low, and SHOULD 311 only transmit the amount of FEC needed to protect against the 312 observed packet loss (which can be determined, e.g., by monitoring 313 transmit packet loss data from RTCP Receiver Reports [RFC3550]), 314 unless the application indicates it is willing to pay a quality 315 penalty to proactively avoid losses. 317 Note that when probing bandwidth, i.e., speculatively sending extra 318 data to determine if additional link capacity exists, FEC SHOULD be 319 used in all cases. Given that extra data is going to be sent 320 regardless, it makes sense to have that data protect the primary 321 payload; in addition, FEC can be applied in a way that increases 322 bandwidth only modestly, which is necessary when probing. 324 When using FEC with layered codecs, e.g., [RFC6386], where only base 325 layer frames are critical to the decoding of future frames, 326 implementations SHOULD only apply FEC to these base layer frames. 328 9. Security Considerations 330 This document makes recommendations regarding the use of FEC. 331 Generally, it should be noted that although applying redundancy is 332 often useful in protecting a stream against packet loss, if the loss 333 is caused by network congestion, the additional bandwidth used by the 334 redundant data may actually make the situation worse, and can lead to 335 significant degradation of the network. 337 As described in [RFC3711], Section 10, the default processing when 338 using FEC with SRTP is to perform FEC followed by SRTP at the sender, 339 and SRTP followed by FEC at the receiver. This ordering is used for 340 all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as 341 described in [RFC5764], Section 4.1.2. 343 Additional security considerations for each individual FEC mechanism 344 are enumerated in their respective documents. 346 10. IANA Considerations 348 This document requires no actions from IANA. 350 11. Acknowledgements 352 Several people provided significant input into this document, 353 including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, 354 Tim Terriberry, Magnus Westerlund, and Mo Zanaty. 356 12. References 358 12.1. Normative References 360 [I-D.ietf-payload-flexible-fec-scheme] 361 Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP 362 Payload Format for Flexible Forward Error Correction 363 (FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in 364 progress), July 2017. 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, 368 DOI 10.17487/RFC2119, March 1997, 369 . 371 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 372 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 373 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 374 DOI 10.17487/RFC2198, September 1997, 375 . 377 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 378 with Session Description Protocol (SDP)", RFC 3264, 379 DOI 10.17487/RFC3264, June 2002, 380 . 382 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 383 "RTP Payload Format and File Storage Format for the 384 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 385 (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, 386 April 2007, . 388 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 389 the Session Description Protocol", RFC 5956, 390 DOI 10.17487/RFC5956, September 2010, 391 . 393 [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format 394 for the Opus Speech and Audio Codec", RFC 7587, 395 DOI 10.17487/RFC7587, June 2015, 396 . 398 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 399 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 400 May 2017, . 402 [TS.26114] 403 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 404 telephony; Media handling and interaction", 3GPP TS 26.114 405 15.0.0, September 2017. 407 12.2. Informative References 409 [I-D.ietf-mmusic-sdp-bundle-negotiation] 410 Holmberg, C., Alvestrand, H., and C. Jennings, 411 "Negotiating Media Multiplexing Using the Session 412 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 413 negotiation-48 (work in progress), January 2018. 415 [I-D.ietf-rtcweb-data-channel] 416 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 417 Channels", draft-ietf-rtcweb-data-channel-13 (work in 418 progress), January 2015. 420 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 421 Jacobson, "RTP: A Transport Protocol for Real-Time 422 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 423 July 2003, . 425 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 426 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 427 RFC 3711, DOI 10.17487/RFC3711, March 2004, 428 . 430 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 431 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 432 DOI 10.17487/RFC4588, July 2006, 433 . 435 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 436 Correction", RFC 5109, DOI 10.17487/RFC5109, December 437 2007, . 439 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 440 for Establishing a Secure Real-time Transport Protocol 441 (SRTP) Security Context Using Datagram Transport Layer 442 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 443 2010, . 445 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 446 Security (DTLS) Extension to Establish Keys for the Secure 447 Real-time Transport Protocol (SRTP)", RFC 5764, 448 DOI 10.17487/RFC5764, May 2010, 449 . 451 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 452 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 453 Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, 454 . 456 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 457 Transport Protocol (RTP) Header Extension for Client-to- 458 Mixer Audio Level Indication", RFC 6464, 459 DOI 10.17487/RFC6464, December 2011, 460 . 462 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 463 time Transport Protocol (RTP) Header Extension for Mixer- 464 to-Client Audio Level Indication", RFC 6465, 465 DOI 10.17487/RFC6465, December 2011, 466 . 468 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 469 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 470 September 2012, . 472 Appendix A. Change log 474 Changes in draft -08: 476 o Switch to RFC 8174 boilerplate. 478 Changes in draft -07: 480 o Clarify how bandwidth management interacts with FEC. 482 o Make 3GPP reference normative. 484 Changes in draft -06: 486 o Discuss how multiple streams can be protected by a single FlexFEC 487 stream. 489 o Discuss FEC for bandwidth probing. 491 o Add note about recovery of RTP headers and header extensions. 493 o Add note about FEC/SRTP ordering. 495 o Clarify flexfec demux text, and mention retransmits. 497 o Clarify text regarding offers/answers. 499 o Make RFC2198 support SHOULD strength. 501 o Clean up references. 503 Changes in draft -05: 505 o No changes. 507 Changes in draft -04: 509 o Discussion of layered codecs. 511 o Discussion of RTX. 513 o Clarified implementation requirements. 515 o FlexFEC MUST -> SHOULD. 517 o Clarified AMR max-red handling. 519 o Updated references. 521 Changes in draft -03: 523 o Added overhead stats for Opus. 525 o Expanded discussion of multi-packet FEC for Opus. 527 o Added discussion of AMR/AMR-WB. 529 o Removed discussion of ssrc-group. 531 o Referenced the data channel doc. 533 o Referenced the RTP/RTCP RFC. 535 o Several small edits based on feedback from Magnus. 537 Changes in draft -02: 539 o Expanded discussion of FEC-only m-lines, and how they should be 540 handled in offers and answers. 542 Changes in draft -01: 544 o Tweaked abstract/intro text that was ambiguously normative. 546 o Removed text on FEC for Opus in CELT mode. 548 o Changed RFC 2198 recommendation for PCMU to be MAY instead of NOT 549 RECOMMENDED, based on list feedback. 551 o Explicitly called out application data as something not addressed 552 in this document. 554 o Updated flexible-fec reference. 556 Changes in draft -00: 558 o Initial version, from sidebar conversation at IETF 90. 560 Author's Address 562 Justin Uberti 563 Google 564 747 6th St S 565 Kirkland, WA 98033 566 USA 568 Email: justin@uberti.name