Subject: [rtcweb] Benjamin Kaduk's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 17 Feb 2019 14:33:05 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-rtcweb-fec-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3

nit: The subsequent discussion seems to indicate that at least some of
these mechanisms are already specified and not new in this document; (if
so) it would be nice to have the exposition reflect that.

Section 3.3

   For Opus, packets deemed as important are re-encoded at a lower
   bitrate and added to the subsequent packet, allowing partial recovery

Is "added" supposed to be something other than "appended" (which strongly
resembles the "redundant encoding" of the previous section)?

Section 4.1

Does it make sense to give subsection backreferences when talking about
(e.g.) redundant encoding?

Section 5.2

   Support for a SSRC-multiplexed flexfec stream to protect a given RTP
   stream SHOULD be indicated by including one of the formats described
   in [I-D.ietf-payload-flexible-fec-scheme], Section 5.1, as an

nit: Since this Section 5 is solely for video, is it more appropriate to
refer to Section 5.1.2 ("Registration of video/flexfec") of
draft-ietf-payload-flexible-fec-scheme?

Section 7

   To support the functionality recommended above, implementations MUST
   be able to receive and make use of the relevant FEC formats for their
   supported audio codecs, and MUST indicate this support, as described
   in Section 4.  Use of these formats when sending, as mentioned above,
   is RECOMMENDED.

Just to double-check: this is explicitly only mandating FEC for audio and
ignoring video entirely?

Section 8

   Because use of FEC always causes redundant data to be transmitted,
   and the total amount of data must remain within any bandwidth limits
   indicated by congestion control and the receiver, this will lead to
   less bandwidth available for the primary encoding, even when the
   redundant data is not being used.  This is in contrast to methods
   like RTX [RFC4588] or flexfec [I-D.ietf-payload-flexible-fec-scheme]
   retransmissions, which only transmit redundant data when necessary,
   at the cost of an extra roundtrip.

This seems to imply that "FEC" is a specific usage and that flexfec is not
a subset of generic FEC.  If so, this could probably be reworded to be
less confusing to the reader (though my suspicion is that the "always
causes redundant data to be transmitted" is only intended to apply to
specific mechanisms from Section 3).

Section 9

This document seems to be agnostic on the question of RTP vs. SRTP; I would
consider referencing their respective security considerations as well as
what is already covered here.

   As described in [RFC3711], Section 10, the default processing when
   using FEC with SRTP is to perform FEC followed by SRTP at the sender,
   and SRTP followed by FEC at the receiver.  This ordering is used for
   all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as
   described in [RFC5764], Section 4.1.2.

I was going to comment about the lack of clarity here, but I see that Ekr
has already gotten the core points, and that the secdir review has already
resulted in some chanegs in the editor's copy.  It would be nice to have
the result of the (merged) edits available to look at, though.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Feb 2019 17:10:35 -0800

Thanks for your comments. See below.

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

It's similar to the redundant encoding, but done within the Opus bitstream,
rather than at the RTP level.

> (e.g.) redundant encoding?

Yes, this could be done easily.

> draft-ietf-payload-flexible-fec-scheme?

Agreed - earlier versions of flexfec were slightly different.

> Just to double-check: this is explicitly only mandating FEC for audio and

This para only applies to audio. The following para discusses video, but is
SHOULD-strength given the relative newness of flexfec.

> specific mechanisms from Section 3).

flexfec is not quite a subset of generic FEC, since it also has a
retransmission format. Thoughts on how this could be reworded?

>  Here's the latest text. Let me know if this needs to be further clarified.

      In the WebRTC context, FEC is specifically concerned with recovering
      data from lost packets; any corrupted packets will be discarded by the
      SRTP <xref target="RFC3711" /> decryption process. Therefore, as
described
      in <xref target="RFC3711" />, Section 10, the default processing when
      using FEC with SRTP is to perform FEC followed by SRTP at the sender,
and
      SRTP followed by FEC at the receiver. This ordering is used for all
the
      SRTP Protection Profiles used in DTLS-SRTP
      <xref target="RFC5763" />, which are enumerated in
      <xref target="RFC5764" />, Section 4.1.2.

>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 24 Feb 2019 19:32:39 -0600

> retransmission format. Thoughts on how this could be reworded?

I think it would need to be "Because use of FEC in the form of <something>
always causes [...]", but I'm not entirely sure what <something> is.  Is it
just "this document" or is there a broader framework or structure to which
this document adheres?

>       SRTP <xref target="RFC3711" /> decryption process. Therefore, as described
>       using FEC with SRTP is to perform FEC followed by SRTP at the sender, and
>       SRTP followed by FEC at the receiver. This ordering is used for all the

This is a lot better; the only thing that I might wonder about is whether
the "this ordering is used for all the SRTP protection profiles used in
DTLS-SRTP" is a new requirement imposed by this document or if that's
supposed to be something that is stated in one of the references.

Thanks for the updates and confirmations of my understanding,

Benjamin

---

From: Justin Uberti <[email-masked]>
Date: Sun, 24 Feb 2019 18:16:06 -0800

On Sun, Feb 24, 2019 at 5:32 PM Benjamin Kaduk <[email-masked]> wrote:

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

This document incorporates multiple FEC schemes, so there isn't another
overarching document (to my knowledge) that captures all of the mechanisms.

The intent here was to say "Because FEC, in general, always causes...", but
open to other phrasings.

> supposed to be something that is stated in one of the references.

It's really just a reiteration of an existing point from RFC 3711 to head
off common questions about the interaction of FEC and encryption.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 24 Feb 2019 20:37:16 -0600

> The intent here was to say "Because FEC, in general, always causes...", but

Ah, I see now.  I think what would help is "in contrast to methods like RTX
or flexfec (when retransmissions are used) [I-D.<...>]"

> off common questions about the interaction of FEC and encryption.

Okay.  Thanks for confirming!

-Benjamin