Draft: draft-ietf-rtcweb-fec

Commentary: While reading the document , I wrote down the following notes that the editor may take into account when revising the document : in 3.1 , expland SSRC on first usage and say that this is about sending streams over RTP somewhere early on ( I assume this is implied by using the term WebRTC but for outsiders like me it may help to be more specific ) . Acknowledged . stylistic : I am not a big fan of using citations like ' [ RFC2198 ] ' as ordinary words or nouns , it makes text difficult to follow unless you know the RFC numbers by heart and your brain translates them back to something meaningful on the fly . This makes texts more difficult to read for outsiders . Example : This mechanism is similar to the [ RFC2198 ] mechanism described above . I prefer this : This mechanism is similar to the redundant encoding mechanism described above . There are couple of such usages of [ RFCXXXX ] in the document OK . add reference for PCMU OK . Reminder to self , RFC 5391 .
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.
This approach, as described in RFC5956, Section 4.3, sends FEC
packets as an independent SSRC-multiplexed stream, with its own SSRC
and payload type.  While this approach can protect multiple packets
of the primary encoding with a single FEC packet, each FEC packet
will have its own IP+UDP+RTP+FEC header, and this overhead can be
excessive in some cases, e.g., when protecting each primary packet
with a FEC packet.
This approach, as descibed in 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.
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 this can be
accomplished for RTP media streams RFC3550; this section enumerates
the various mechanisms available and describes their tradeoffs.
This approach, as described in RFC5956, Section 4.3, sends FEC
packets as an independent RTP stream with its own synchronization
source (SSRC, RFC3550) and payload type, multiplexed with the primary
encoding.  While this approach can protect multiple packets of the
primary encoding with a single FEC packet, each FEC packet will have
its own IP+UDP+RTP+FEC header, and this overhead can be excessive in
some cases, e.g., when protecting each primary packet with a FEC
packet.
This approach, as described in 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.
For AMR/AMR-WB, packets can contain copies or lower-quality encodings
of multiple prior audio frames.  This mechanism is similar to the
RFC2198 mechanism described above, but as it adds no additional
framing, it can be slightly more efficient.  See RFC4867,
Section 3.7.1 for details on this mechanism.
For AMR/AMR-WB, packets can contain copies or lower-quality encodings
of multiple prior audio frames.  This mechanism is similar to the
redundant encoding mechanism described above, but as it adds no
additional framing, it can be slightly more efficient.  See RFC4867,
Section 3.7.1 for details on this mechanism.
When using variable-bitrate codecs without an internal FEC, RFC2198
redundant encoding with lower-fidelity version(s) of the previous
packet(s) is RECOMMENDED.  This provides reasonable protection of the
payload with only moderate bitrate increase, as the redundant
encodings can be significantly smaller than the primary encoding.
When using the Opus codec, use of the built-in Opus FEC mechanism is
RECOMMENDED.  This provides reasonable protection of the audio stream
against individual losses, with minimal overhead.  Note that, as
indicated above, the built-in Opus FEC only provides single-frame
redundancy; if multi-packet protection is needed, the aforementioned
RFC2198 redundancy with reduced-bitrate Opus encodings SHOULD be used
instead.
When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism
is RECOMMENDED.  This provides slightly more efficient protection of
the audio stream than RFC2198.
When using constant-bitrate codecs, e.g.  PCMU, use of 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.
When using variable-bitrate codecs without an internal FEC, redundant
encoding (as described in redundant-encoding) with lower-fidelity
version(s) of the previous packet(s) is RECOMMENDED.  This provides
reasonable protection of the payload with only moderate bitrate
increase, as the redundant encodings can be significantly smaller
than the primary encoding.
When using the Opus codec, use of the built-in Opus FEC mechanism is
RECOMMENDED.  This provides reasonable protection of the audio stream
against individual losses, with minimal overhead.  Note that, as
indicated above, the built-in Opus FEC only provides single-frame
redundancy; if multi-packet protection is needed, the aforementioned
redundant encoding with reduced-bitrate Opus encodings SHOULD be used
instead.
When using the AMR/AMR-WB codecs, use of their built-in FEC mechanism
is RECOMMENDED.  This provides slightly more efficient protection of
the audio stream than redundant encoding.
When using constant-bitrate codecs, e.g., PCMU RFC5391, redundant
encoding MAY be used, but this will result in a potentially
significant bitrate increase, and suddenly increasing bitrate to deal
with losses from congestion may actually make things worse.