idnits 2.17.1 draft-ietf-rtcweb-fec-07.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 (December 10, 2017) is 2323 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-43 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 December 10, 2017 5 Expires: June 13, 2018 7 WebRTC Forward Error Correction Requirements 8 draft-ietf-rtcweb-fec-07 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 June 13, 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 (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 . . . . . . . . . . . . . . . . . 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 Because use of FEC always causes redundant data to be transmitted, 299 and the total amount of data must remain within any bandwidth limits 300 indicated by congestion control and the receiver, this will lead to 301 less bandwidth available for the primary encoding, even when the 302 redundant data is not being used. This is in contrast to methods 303 like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme] 304 retransmissions, which only transmit redundant data when necessary, 305 at the cost of an extra roundtrip. 307 Given this, WebRTC implementations SHOULD consider using RTX or 308 flexfec retransmissions instead of FEC when RTT is low, and SHOULD 309 only transmit the amount of FEC needed to protect against the 310 observed packet loss (which can be determined, e.g., by monitoring 311 transmit packet loss data from RTCP Receiver Reports [RFC3550]), 312 unless the application indicates it is willing to pay a quality 313 penalty to proactively avoid losses. 315 Note that when probing bandwidth, i.e., speculatively sending extra 316 data to determine if additional link capacity exists, FEC SHOULD be 317 used in all cases. Given that extra data is going to be sent 318 regardless, it makes sense to have that data protect the primary 319 payload; in addition, FEC can be applied in a way that increases 320 bandwidth only modestly, which is necessary when probing. 322 When using FEC with layered codecs, e.g., [RFC6386], where only base 323 layer frames are critical to the decoding of future frames, 324 implementations SHOULD only apply FEC to these base layer frames. 326 9. Security Considerations 328 This document makes recommendations regarding the use of FEC. 329 Generally, it should be noted that although applying redundancy is 330 often useful in protecting a stream against packet loss, if the loss 331 is caused by network congestion, the additional bandwidth used by the 332 redundant data may actually make the situation worse, and can lead to 333 significant degradation of the network. 335 As described in [RFC3711], Section 10, the default processing when 336 using FEC with SRTP is to perform FEC followed by SRTP at the sender, 337 and SRTP followed by FEC at the receiver. This ordering is used for 338 all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as 339 described in [RFC5764], Section 4.1.2. 341 Additional security considerations for each individual FEC mechanism 342 are enumerated in their respective documents. 344 10. IANA Considerations 346 This document requires no actions from IANA. 348 11. Acknowledgements 350 Several people provided significant input into this document, 351 including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh, 352 Tim Terriberry, Magnus Westerlund, and Mo Zanaty. 354 12. References 356 12.1. Normative References 358 [I-D.ietf-payload-flexible-fec-scheme] 359 Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP 360 Payload Format for Flexible Forward Error Correction 361 (FEC)", draft-ietf-payload-flexible-fec-scheme-05 (work in 362 progress), July 2017. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., 370 Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- 371 Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, 372 DOI 10.17487/RFC2198, September 1997, 373 . 375 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 376 with Session Description Protocol (SDP)", RFC 3264, 377 DOI 10.17487/RFC3264, June 2002, 378 . 380 [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, 381 "RTP Payload Format and File Storage Format for the 382 Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband 383 (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, 384 April 2007, . 386 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 387 the Session Description Protocol", RFC 5956, 388 DOI 10.17487/RFC5956, September 2010, 389 . 391 [RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format 392 for the Opus Speech and Audio Codec", RFC 7587, 393 DOI 10.17487/RFC7587, June 2015, 394 . 396 [TS.26114] 397 3GPP, "IP Multimedia Subsystem (IMS); Multimedia 398 telephony; Media handling and interaction", 3GPP TS 26.114 399 15.0.0, September 2017. 401 12.2. Informative References 403 [I-D.ietf-mmusic-sdp-bundle-negotiation] 404 Holmberg, C., Alvestrand, H., and C. Jennings, 405 "Negotiating Media Multiplexing Using the Session 406 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 407 negotiation-43 (work in progress), December 2017. 409 [I-D.ietf-rtcweb-data-channel] 410 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 411 Channels", draft-ietf-rtcweb-data-channel-13 (work in 412 progress), January 2015. 414 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 415 Jacobson, "RTP: A Transport Protocol for Real-Time 416 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 417 July 2003, . 419 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 420 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 421 RFC 3711, DOI 10.17487/RFC3711, March 2004, 422 . 424 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 425 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 426 DOI 10.17487/RFC4588, July 2006, 427 . 429 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 430 Correction", RFC 5109, DOI 10.17487/RFC5109, December 431 2007, . 433 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 434 for Establishing a Secure Real-time Transport Protocol 435 (SRTP) Security Context Using Datagram Transport Layer 436 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 437 2010, . 439 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 440 Security (DTLS) Extension to Establish Keys for the Secure 441 Real-time Transport Protocol (SRTP)", RFC 5764, 442 DOI 10.17487/RFC5764, May 2010, 443 . 445 [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J., 446 Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding 447 Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011, 448 . 450 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 451 Transport Protocol (RTP) Header Extension for Client-to- 452 Mixer Audio Level Indication", RFC 6464, 453 DOI 10.17487/RFC6464, December 2011, 454 . 456 [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- 457 time Transport Protocol (RTP) Header Extension for Mixer- 458 to-Client Audio Level Indication", RFC 6465, 459 DOI 10.17487/RFC6465, December 2011, 460 . 462 [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the 463 Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, 464 September 2012, . 466 Appendix A. Change log 468 Changes in draft -07: 470 o Clarify how bandwidth management interacts with FEC. 472 o Make 3GPP reference normative. 474 Changes in draft -06: 476 o Discuss how multiple streams can be protected by a single FlexFEC 477 stream. 479 o Discuss FEC for bandwidth probing. 481 o Add note about recovery of RTP headers and header extensions. 483 o Add note about FEC/SRTP ordering. 485 o Clarify flexfec demux text, and mention retransmits. 487 o Clarify text regarding offers/answers. 489 o Make RFC2198 support SHOULD strength. 491 o Clean up references. 493 Changes in draft -05: 495 o No changes. 497 Changes in draft -04: 499 o Discussion of layered codecs. 501 o Discussion of RTX. 503 o Clarified implementation requirements. 505 o FlexFEC MUST -> SHOULD. 507 o Clarified AMR max-red handling. 509 o Updated references. 511 Changes in draft -03: 513 o Added overhead stats for Opus. 515 o Expanded discussion of multi-packet FEC for Opus. 517 o Added discussion of AMR/AMR-WB. 519 o Removed discussion of ssrc-group. 521 o Referenced the data channel doc. 523 o Referenced the RTP/RTCP RFC. 525 o Several small edits based on feedback from Magnus. 527 Changes in draft -02: 529 o Expanded discussion of FEC-only m-lines, and how they should be 530 handled in offers and answers. 532 Changes in draft -01: 534 o Tweaked abstract/intro text that was ambiguously normative. 536 o Removed text on FEC for Opus in CELT mode. 538 o Changed RFC 2198 recommendation for PCMU to be MAY instead of NOT 539 RECOMMENDED, based on list feedback. 541 o Explicitly called out application data as something not addressed 542 in this document. 544 o Updated flexible-fec reference. 546 Changes in draft -00: 548 o Initial version, from sidebar conversation at IETF 90. 550 Author's Address 552 Justin Uberti 553 Google 554 747 6th St S 555 Kirkland, WA 98033 556 USA 558 Email: justin@uberti.name