One document matched: draft-ietf-rtcweb-fec-02.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2198.xml">
<!ENTITY rfc5109 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5109.xml">
<!ENTITY rfc5956 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5956.xml">
<!ENTITY rfc6716 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml">
<!ENTITY fecpayload SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-payload-flexible-fec-scheme.xml">
<!ENTITY opuspayload SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-payload-rtp-opus.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>

<rfc category="std" docName="draft-ietf-rtcweb-fec-02" ipr="trust200902">
  <front>
    <title abbrev="WebRTC FEC">WebRTC Forward Error Correction Requirements</title>

    <author fullname="Justin Uberti" initials="J." surname="Uberti">
      <organization>Google</organization>

      <address>
        <postal>
          <street>747 6th Ave S</street>

          <city>Kirkland</city>

          <region>WA</region>

          <code>98033</code>

          <country>USA</country>
        </postal>

        <email>justin@uberti.name</email>
      </address>
    </author>

    <date day="18" month="October" year="2015" />

    <area>RAI</area>

    <abstract>
      <t>This document provides information and requirements for how
      Forward Error Correction (FEC) should be used by WebRTC applications.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>In situations where packet loss is high, or perfect media quality is essential,
      Forward Error Correction (FEC) can be used to proactively recover from packet losses.
      This specification provides guidance on which FEC mechanisms to use, and
      how to use them, for WebRTC client implementations.</t>
    </section>

    <section title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"></xref>.</t>
    </section>

    <section title="Types of FEC">
      <t>By its name, FEC describes the sending of redundant information in
         an outgoing packet stream so that information can still be recovered
         even in the face of packet loss. There are multiple ways in which this
         can be accomplished; this section enumerates the various mechanisms
         and describes their tradeoffs.</t>
      <section title="Separate FEC Stream">
          <t>This approach, as described in <xref target="RFC5956"/>, Section 4.3,
            sends FEC packets as an
            independent SSRC-multiplexed stream, with its own SSRC and payload type.
            While by far the most flexible, each FEC packet will have its own
            IP+UDP+RTP+FEC header, leading to additional overhead of the FEC stream.
          </t>
      </section>
      <section title="Redundant Encoding">
          <t>This approach, as descibed in <xref target="RFC2198"/>, allows for redundant data
            to be piggybacked on an existing primary encoding, all in a single packet.
            This redundant data may be an exact copy of a previous packet, or
            for codecs that support variable-bitrate encodings, possibly a smaller,
            lower-quality representation. In certain cases, the redundant data
            could include multiple prior packets.</t>
          <t>Since there is only a single set of
            packet headers, this approach allows for a very efficient representation of
            primary + redundant data. However, this savings is only realized when
            the data all fits into a single packet (i.e. the size is less than a MTU).
            As a result, this approach is generally not useful for video content.
          </t>
      </section>
       <section title="Codec-Specific In-band FEC">
          <t>Some audio codecs, notably Opus <xref target="RFC6716"/>, support their own in-band FEC
            mechanism, where FEC data is included in the codec payload. In the
            case of Opus specifically, packets deemed as important are re-encoded
            at a lower bitrate and added to the subsequent packet, allowing partial
            recovery of a lost packet. See <xref target="RFC6716"/>, Section 2.1.7 for details.
          </t>
      </section>
    </section>

    <section title="FEC for Audio Content">
      <t>The following section provides guidance on how to best use FEC for transmitting
      audio data. As indicated in <xref target="adaptive-fec"/> below, FEC should only
      be activated if network conditions warrant it, or upon explicit application request.
      </t>
      <section title="Recommended Mechanism">
        <t>When using the Opus codec in its default (hybrid) mode, use of
          the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable
          protection of the audio stream against typical losses, with minimal
          overhead. [TODO: add stats]
        </t>
        <t>When using variable-bitrate codecs without an internal FEC, use of
        <xref target="RFC2198"/> redundant encoding with a lower-fidelity version
        of previous packet(s) is RECOMMENDED.
        This provides reasonable protection of the payload with moderate overhead.
        </t>
        <t>When using constant-bitrate codecs, e.g. PCMU, use of
        <xref target="RFC2198"/> redundant encoding MAY be used, but note that
        this will result in a potentially significant bitrate increase, and
        that suddenly increasing bitrate to deal with losses from congestion may
        actually make things worse.
        </t>
        <t>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 overhead
        than other mechanisms, and therefore is NOT RECOMMENDED.
        </t>
      </section>

      <section title="Negotiating Support">
        <t>Support for redundant encoding can be indicated by offering "red" as a
        supported payload type in the offer. Answerers can reject the use of
        redundant encoding by not including "red" as a supported payload type in
        the answer.</t>
        <t>Support for codec-specific FEC mechanisms are typically indicated via
        "a=fmtp" parameters. For Opus specifically, this is controlled by the
        "useinbandfec=1" parameter, as specified in <xref target="I-D.ietf-payload-rtp-opus"/>.
        These parameters are declarative and can
        be negotiated separately for either media direction.</t>
      </section>
    </section>

    <section title="FEC for Video Content">
      <t>The following section provides guidance on how to best use FEC for transmitting
      video data. As indicated in <xref target="adaptive-fec"/> below, FEC should only
      be activated if network conditions warrant it, or upon explicit application request.
      </t>
      <section title="Recommended Mechanism">
        <t>For video content, use of a separate FEC stream with the RTP payload format
        described in <xref target="I-D.ietf-payload-flexible-fec-scheme"/> is RECOMMENDED.
        The receiver can demultiplex the incoming FEC stream by SSRC and correlate it
        with the primary stream via the ssrc-group mechanism.
        </t>
        <t>Support for protecting multiple primary streams with a single FEC stream is
        complicated by WebRTC's 1-m-line-per-stream policy,
        which does not allow for a m-line dedicated specifically to FEC.</t>
      </section>
      <section title="Negotiating Support">
        <t>To offer support for a separate SSRC-multiplexed FEC stream, the
        offerer MUST offer one of the formats described in
        <xref target="I-D.ietf-payload-flexible-fec-scheme"/>, Section 5.1,
        as well as a ssrc-group with "FEC-FR" semantics as described in
        <xref target="RFC5956"/>, Section 4.3.</t>
        <t>Use of FEC-only m-lines, and grouping using the SDP group mechanism,
          is not currently defined for WebRTC, and SHOULD NOT be offered.</t>
        <t>Answerers can reject the use of SSRC-multiplexed FEC, by not
          including FEC payload types in the answer.</t>
        <t>Answerers SHOULD reject any FEC-only m-lines, unless they
        specifically know how to handle such a thing in a WebRTC context (perhaps
        defined by a future version of the WebRTC specifications). This ensures
        that implementations will not malfunction when said future version of WebRTC
        enables offers of FEC-only m-lines.</t>
      </section>
    </section>

    <section title="FEC for Application Content">
      <t>WebRTC also supports the ability to send generic application data, and
      provides transport-level retransmission mechanisms that the application
      can use to ensure that its data is delivered reliably. </t>
      <t>
      Because the application can control exactly what data to send, it has the
      ability to monitor packet statistics and perform its own application-level
      FEC, if necessary.</t>
      <t>As a result, this document makes no recommendations regarding FEC for
      the underlying data transport.</t>
    </section>

    <section title="Implementation Requirements">
        <t>To support the functionality recommended above, implementations MUST support
        the redundant encoding mechanism described in <xref target="RFC2198"/> and the FEC
        mechanism described in <xref target="RFC5956"/> and
        <xref target="I-D.ietf-payload-flexible-fec-scheme"/>.</t>
        <t>Implementations MAY support additional FEC mechanisms if desired,
        e.g. <xref target="RFC5109"/>.</t>
    </section>

    <section anchor="adaptive-fec" title="Adaptive Use of FEC">
      <t>Since use of FEC causes redundant data to be transmitted, this will
        lead to less bandwidth available for the primary encoding, when in a
        bandwidth-constrained environment. Given this, WebRTC implementations
        SHOULD only transmit FEC data when network conditions indicate that
        this is advisable (e.g. by monitoring transmit packet loss data from
        RTCP Receiver Reports), or the application indicates it is willing to
        pay a quality penalty to proactively avoid losses.
      </t>
    </section>

    <section title="Security Considerations">
      <t>This document makes recommendations regarding the use of FEC.
      Generally, it should be noted that although applying redundancy is often useful
      in protecting a stream against packet loss, if the loss is caused by network
      congestion, the additional bandwidth used by the redundant data may actually
      make the situation worse, and can lead to significant degradation of the
      network.
      </t>
      <t>Additional security considerations for each individual FEC mechanism
      are enumerated in their respective documents.
      </t>

    </section>

    <section title="IANA Considerations">
      <t>This document requires no actions from IANA.</t>
    </section>

    <section title="Acknowledgements">
      <t>Several people provided significant input into this document, including
      Jonathan Lennox, Giri Mandyam, Varun Singh, Tim Terriberry, and Mo Zanaty.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
      &rfc2198;
      &rfc5956;
      &fecpayload;
    </references>

    <references title="Informative References">
      &rfc5109;
      &rfc6716;
      &opuspayload;
    </references>

    <section title="Change log">
      <t>Changes in draft -02: <list style="symbols">
        <t>Expanded discussion of FEC-only m-lines, and how they should be
        handled in offers and answers.</t>
      </list></t>
      <t>Changes in draft -01: <list style="symbols">
        <t>Tweaked abstract/intro text that was ambiguously normative.</t>
        <t>Removed text on FEC for Opus in CELT mode.</t>
        <t>Changed RFC 2198 recommendation for PCMU to be MAY instead of
           NOT RECOMMENDED, based on list feedback.</t>
        <t>Explicitly called out application data as something not addressed
           in this document.</t>
        <t>Updated flexible-fec reference.</t>
      </list></t>
      <t>Changes in draft -00: <list style="symbols">
        <t>Initial version, from sidebar conversation at IETF 90.</t>
      </list></t>
    </section>
  </back>
</rfc>