draft-ietf-rtcweb-fec-03.txt   draft-ietf-rtcweb-fec-04.txt 
Network Working Group J. Uberti Network Working Group J. Uberti
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track March 20, 2016 Intended status: Standards Track October 31, 2016
Expires: September 21, 2016 Expires: May 4, 2017
WebRTC Forward Error Correction Requirements WebRTC Forward Error Correction Requirements
draft-ietf-rtcweb-fec-03 draft-ietf-rtcweb-fec-04
Abstract Abstract
This document provides information and requirements for how Forward This document provides information and requirements for how Forward
Error Correction (FEC) should be used by WebRTC applications. Error Correction (FEC) should be used by WebRTC applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 21, 2016. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
3.3. Codec-Specific In-band FEC . . . . . . . . . . . . . . . 3 3.3. Codec-Specific In-band FEC . . . . . . . . . . . . . . . 3
4. FEC for Audio Content . . . . . . . . . . . . . . . . . . . . 4 4. FEC for Audio Content . . . . . . . . . . . . . . . . . . . . 4
4.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 4 4.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 4
4.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 4 4.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 4
5. FEC for Video Content . . . . . . . . . . . . . . . . . . . . 5 5. FEC for Video Content . . . . . . . . . . . . . . . . . . . . 5
5.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 5 5.1. Recommended Mechanism . . . . . . . . . . . . . . . . . . 5
5.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 5 5.2. Negotiating Support . . . . . . . . . . . . . . . . . . . 5
6. FEC for Application Content . . . . . . . . . . . . . . . . . 6 6. FEC for Application Content . . . . . . . . . . . . . . . . . 6
7. Implementation Requirements . . . . . . . . . . . . . . . . . 6 7. Implementation Requirements . . . . . . . . . . . . . . . . . 6
8. Adaptive Use of FEC . . . . . . . . . . . . . . . . . . . . . 6 8. Adaptive Use of FEC . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
In situations where packet loss is high, or perfect media quality is In situations where packet loss is high, or perfect media quality is
essential, Forward Error Correction (FEC) can be used to proactively essential, Forward Error Correction (FEC) can be used to proactively
recover from packet losses. This specification provides guidance on recover from packet losses. This specification provides guidance on
which FEC mechanisms to use, and how to use them, for WebRTC client which FEC mechanisms to use, and how to use them, for WebRTC client
implementations. implementations.
2. Terminology 2. Terminology
skipping to change at page 3, line 41 skipping to change at page 3, line 41
their own in-band FEC mechanism, where redundant data is included in their own in-band FEC mechanism, where redundant data is included in
the codec payload. the codec payload.
For Opus, packets deemed as important are re-encoded at a lower For Opus, packets deemed as important are re-encoded at a lower
bitrate and added to the subsequent packet, allowing partial recovery bitrate and added to the subsequent packet, allowing partial recovery
of a lost packet. This scheme is fairly efficient; experiments of a lost packet. This scheme is fairly efficient; experiments
performed indicate that when Opus FEC is used, the overhead imposed performed indicate that when Opus FEC is used, the overhead imposed
is about 20-30%, depending on the amount of protection needed. Note is about 20-30%, depending on the amount of protection needed. Note
that this mechanism can only carry redundancy information for the that this mechanism can only carry redundancy information for the
immediately preceding packet; as such the decoder cannot fully immediately preceding packet; as such the decoder cannot fully
recover multiple consecutive lost packets. See [RFC6716], recover multiple consecutive lost packets, which can be a problem on
Section 2.1.7 for complete details. wireless networks. See [RFC6716], Section 2.1.7 for complete
details.
For AMR/AMR-WB, packets can contain copies or lower-quality encodings For AMR/AMR-WB, packets can contain copies or lower-quality encodings
of multiple prior audio frames. This mechanism is similar to the of multiple prior audio frames. This mechanism is similar to the
[RFC2198] mechanism described above, but as it adds no additional [RFC2198] mechanism described above, but as it adds no additional
framing, it can be slightly more efficient. See [RFC4867], framing, it can be slightly more efficient. See [RFC4867],
Section 3.7.1 for details on this mechanism. Section 3.7.1 for details on this mechanism.
4. FEC for Audio Content 4. FEC for Audio Content
The following section provides guidance on how to best use FEC for The following section provides guidance on how to best use FEC for
skipping to change at page 4, line 43 skipping to change at page 4, line 43
potentially significant bitrate increase, and that suddenly potentially significant bitrate increase, and that suddenly
increasing bitrate to deal with losses from congestion may actually increasing bitrate to deal with losses from congestion may actually
make things worse. make things worse.
Because of the lower packet rate of audio encodings, usually a single Because of the lower packet rate of audio encodings, usually a single
packet per frame, use of a separate FEC stream comes with a higher packet per frame, use of a separate FEC stream comes with a higher
overhead than other mechanisms, and therefore is NOT RECOMMENDED. overhead than other mechanisms, and therefore is NOT RECOMMENDED.
4.2. Negotiating Support 4.2. Negotiating Support
Support for redundant encoding can be indicated by offering "red" as Support for redundant encoding MUST be indicated by offering "red" as
a supported payload type in the offer. Answerers can reject the use a supported payload type in the offer. Answerers can reject the use
of redundant encoding by not including "red" as a supported payload of redundant encoding by not including "red" as a supported payload
type in the answer. type in the answer.
Support for codec-specific FEC mechanisms are typically indicated via Support for codec-specific FEC mechanisms are typically indicated via
"a=fmtp" parameters. "a=fmtp" parameters.
For Opus, support for FEC at the received side is controlled by the For Opus, a receiver MUST indicate that it is prepared to use
"useinbandfec=1" parameter, as specified in incoming FEC data with the "useinbandfec=1" parameter, as specified
in [RFC7587]. This parameter is declarative and can be negotiated
[I-D.ietf-payload-rtp-opus]. This parameter is declarative and can separately for either media direction.
be negotiated separately for either media direction.
For AMR/AMR-WB, support for redundant encoding, and the maximum For AMR/AMR-WB, support for redundant encoding, and the maximum
supported depth, are controlled by the 'max-red' parameter, as supported depth, are controlled by the 'max-red' parameter, as
specified in [RFC4867], Section 8.1. [TODO: figure out any specified in [RFC4867], Section 8.1. Receivers MUST include this
additional recommendations are needed.] parameter, and set it to an appropriate value, as specified in
[3GPP.26.114], Table 6.3.
5. FEC for Video Content 5. FEC for Video Content
The following section provides guidance on how to best use FEC for The following section provides guidance on how to best use FEC for
transmitting video data. As indicated in Section 8 below, FEC should transmitting video data. As indicated in Section 8 below, FEC should
only be activated if network conditions warrant it, or upon explicit only be activated if network conditions warrant it, or upon explicit
application request. application request.
5.1. Recommended Mechanism 5.1. Recommended Mechanism
skipping to change at page 6, line 22 skipping to change at page 6, line 22
Because the application can control exactly what data to send, it has Because the application can control exactly what data to send, it has
the ability to monitor packet statistics and perform its own the ability to monitor packet statistics and perform its own
application-level FEC, if necessary. application-level FEC, if necessary.
As a result, this document makes no recommendations regarding FEC for As a result, this document makes no recommendations regarding FEC for
the underlying data transport. the underlying data transport.
7. Implementation Requirements 7. Implementation Requirements
To support the functionality recommended above, implementations MUST To support the functionality recommended above, implementations MUST
support the relevant mechanisms for their supported audio codecs, as be able to receive and make use of the relevant FEC formats for their
described in Section 4, and the general FEC mechanism described in supported audio codecs, and MUST indicate this support, as described
[I-D.ietf-payload-flexible-fec-scheme]. in Section 4. Use of these formats when sending, as mentioned above,
is RECOMMENDED.
The general FEC mechanism described in
[I-D.ietf-payload-flexible-fec-scheme] SHOULD also be supported, as
mentioned in Section 5.
Implementations MAY support additional FEC mechanisms if desired, Implementations MAY support additional FEC mechanisms if desired,
e.g. [RFC5109]. e.g. [RFC5109].
8. Adaptive Use of FEC 8. Adaptive Use of FEC
Since use of FEC causes redundant data to be transmitted, this will Since use of FEC always causes redundant data to be transmitted, this
lead to less bandwidth available for the primary encoding, when in a will lead to less bandwidth available for the primary encoding when
bandwidth-constrained environment. Given this, WebRTC in a bandwidth-constrained environment. This is in contrast to
implementations SHOULD only transmit the amount of FEC needed to methods like RTX [RFC4588], which only transmits redundant data when
protect against the observed packet loss (which can be determined, necessary, at the cost of an extra roundtrip.
e.g., by monitoring transmit packet loss data from RTCP Receiver
Reports [RFC3550]), or the application indicates it is willing to pay Given this, WebRTC implementations SHOULD consider using RTX instead
a quality penalty to proactively avoid losses. of FEC when RTT is low, and SHOULD only transmit the amount of FEC
needed to protect against the observed packet loss (which can be
determined, e.g., by monitoring transmit packet loss data from RTCP
Receiver Reports [RFC3550]), unless the application indicates it is
willing to pay a quality penalty to proactively avoid losses.
When using FEC with layered codecs, e.g., [RFC6386], where only base
layer frames are critical to the decoding of future frames,
implementations SHOULD only apply FEC to these base layer frames.
9. Security Considerations 9. Security Considerations
This document makes recommendations regarding the use of FEC. This document makes recommendations regarding the use of FEC.
Generally, it should be noted that although applying redundancy is Generally, it should be noted that although applying redundancy is
often useful in protecting a stream against packet loss, if the loss often useful in protecting a stream against packet loss, if the loss
is caused by network congestion, the additional bandwidth used by the is caused by network congestion, the additional bandwidth used by the
redundant data may actually make the situation worse, and can lead to redundant data may actually make the situation worse, and can lead to
significant degradation of the network. significant degradation of the network.
Additional security considerations for each individual FEC mechanism Additional security considerations for each individual FEC mechanism
are enumerated in their respective documents. are enumerated in their respective documents.
10. IANA Considerations 10. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
11. Acknowledgements 11. Acknowledgements
Several people provided significant input into this document, Several people provided significant input into this document,
including Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, including Bernard Aboba, Jonathan Lennox, Giri Mandyam, Varun Singh,
and Mo Zanaty. Tim Terriberry, Magnus Westerlund, and Mo Zanaty.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-payload-flexible-fec-scheme] [I-D.ietf-payload-flexible-fec-scheme]
Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP Singh, V., Begen, A., Zanaty, M., and G. Mandyam, "RTP
Payload Format for Flexible Forward Error Correction Payload Format for Flexible Forward Error Correction
(FEC)", draft-ietf-payload-flexible-fec-scheme-01 (work in (FEC)", draft-ietf-payload-flexible-fec-scheme-03 (work in
progress), October 2015. progress), October 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., [RFC2198] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse- Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, Parisis, "RTP Payload for Redundant Audio Data", RFC 2198,
DOI 10.17487/RFC2198, September 1997, DOI 10.17487/RFC2198, September 1997,
<http://www.rfc-editor.org/info/rfc2198>. <http://www.rfc-editor.org/info/rfc2198>.
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
the Session Description Protocol", RFC 5956, the Session Description Protocol", RFC 5956,
DOI 10.17487/RFC5956, September 2010, DOI 10.17487/RFC5956, September 2010,
<http://www.rfc-editor.org/info/rfc5956>. <http://www.rfc-editor.org/info/rfc5956>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-payload-rtp-opus]
Spittka, J., Vos, K., and J. Valin, "RTP Payload Format
for the Opus Speech and Audio Codec", draft-ietf-payload-
rtp-opus-11 (work in progress), April 2015.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015. progress), January 2015.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006,
<http://www.rfc-editor.org/info/rfc4588>.
[RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, [RFC4867] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie,
"RTP Payload Format and File Storage Format for the "RTP Payload Format and File Storage Format for the
Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband
(AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867, (AMR-WB) Audio Codecs", RFC 4867, DOI 10.17487/RFC4867,
April 2007, <http://www.rfc-editor.org/info/rfc4867>. April 2007, <http://www.rfc-editor.org/info/rfc4867>.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, DOI 10.17487/RFC5109, December Correction", RFC 5109, DOI 10.17487/RFC5109, December
2007, <http://www.rfc-editor.org/info/rfc5109>. 2007, <http://www.rfc-editor.org/info/rfc5109>.
[RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
Wilkins, P., and Y. Xu, "VP8 Data Format and Decoding
Guide", RFC 6386, DOI 10.17487/RFC6386, November 2011,
<http://www.rfc-editor.org/info/rfc6386>.
[RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the
Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
September 2012, <http://www.rfc-editor.org/info/rfc6716>. September 2012, <http://www.rfc-editor.org/info/rfc6716>.
[RFC7587] Spittka, J., Vos, K., and JM. Valin, "RTP Payload Format
for the Opus Speech and Audio Codec", RFC 7587,
DOI 10.17487/RFC7587, June 2015,
<http://www.rfc-editor.org/info/rfc7587>.
Appendix A. Change log Appendix A. Change log
Changes in draft -04:
o Discussion of layered codecs.
o Discussion of RTX.
o Clarified implementation requirements.
o FlexFEC MUST -> SHOULD.
o Clarified AMR max-red handling.
o Updated references.
Changes in draft -03: Changes in draft -03:
o Added overhead stats for Opus. o Added overhead stats for Opus.
o Expanded discussion of multi-packet FEC for Opus. o Expanded discussion of multi-packet FEC for Opus.
o Added discussion of AMR/AMR-WB. o Added discussion of AMR/AMR-WB.
o Removed discussion of ssrc-group. o Removed discussion of ssrc-group.
 End of changes. 19 change blocks. 
37 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/