[rtcweb] Review of draft-ietf-rtcweb-fec-03

[Bernard Aboba <[e-mail]>]

Section 3.3

   Note that this mechanism can only carry redundancy information for the
   immediately preceding packet; as such the decoder cannot fully
   recover multiple consecutive lost packets.


[BA] In our experience, this has turned out to be a significant problem

on wireless networks where burst loss is common.


Section 4.1


   When using the Opus codec, use of the built-in Opus FEC mechanism is
   RECOMMENDED.  This provides reasonable protection of the audio stream
   against typical losses, with modest overhead.  Note that as indicated
   above the built-in Opus FEC only provides single-frame redundancy; if
   multi-packet protection is needed, the built-in FEC should be
   combined with [RFC2198 <https://tools.ietf.org/html/rfc2198>]
redundancy to protect the N-2th, N-3rd, etc.
   packets.


   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.


[BA] In our implementation, we have found that using external FEC

supporting burst loss resilience provides audio quality superior

to RFC 2198 redundancy with less overhead, iff the level of

protection can be dynamically adjusted (e.g. it is only used if

needed). Since that is recommended in Section 8, NOT RECOMMENDED

seems too harsh. Maybe optional?


Section 5.1


   For video content, use of a separate FEC stream with the RTP payload
   format described in [I-D.ietf-payload-flexible-fec-scheme
<https://tools.ietf.org/html/draft-ietf-rtcweb-fec-03#ref-I-D.ietf-payload-flexible-fec-scheme>]
is
   RECOMMENDED.


[BA] The above RECOMMENDED seems to be contradicted by a MUST in

Section 7.


Section 7


 To support the functionality recommended above, implementations MUST
   support the relevant mechanisms for their supported audio codecs, as
   described in Section 4
<https://tools.ietf.org/html/draft-ietf-rtcweb-fec-03#section-4>, and
the general FEC mechanism described in
   [I-D.ietf-payload-flexible-fec-scheme
<https://tools.ietf.org/html/draft-ietf-rtcweb-fec-03#ref-I-D.ietf-payload-flexible-fec-scheme>].

   Implementations MAY support additional FEC mechanisms if desired,
   e.g.  [RFC5109 <https://tools.ietf.org/html/rfc5109>].


[BA] The above paragraph seems to indicate that flex fec is a MUST,
rather than merely RECOMMENDED. Personally, I think a MUST for
flex fec is too much, and that since existing implementations support
ulpfec, this should be upgraded to RECOMMENDED.

RECOMMENDED seems more suitable for flexible fec since we don't have much

implementation experience yet.  My recommendation would be to wait to

publish the flex fec document until we had some implementation

experience, since if the flex fec goes to RFC before that we could

have some surprises (including late IPR declarations) that might lead

us to regret publishing early.


Section 8


   Given this, WebRTC
   implementations 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 <https://tools.ietf.org/html/rfc3550>]), or the
application indicates it is willing to pay
   a quality penalty to proactively avoid losses.


[BA] Very much in agreement with this - particularly since RTX can
be a quite viable robustness mechanism, particularly when combined
with temporal scalability. Where RTX is not sufficient (e.g. RTT
is too high), it might be worth mentioning selective FEC protection
(e.g. of the base layer only). Since VP8, VP9 and future video
codecs can all benefit from this, it's not that esoteric.