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

[Benjamin Kaduk <[e-mail]>]

On Sun, Feb 24, 2019 at 06:16:06PM -0800, Justin Uberti wrote:
> On Sun, Feb 24, 2019 at 5:32 PM Benjamin Kaduk <[e-mail]> wrote:
> 
> > On Fri, Feb 22, 2019 at 05:10:35PM -0800, Justin Uberti wrote:
> > > Thanks for your comments. See below.
> > >
> > > On Sun, Feb 17, 2019 at 2:33 PM Benjamin Kaduk <[e-mail]> wrote:
> > >
> > > > 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)?
> > > >
> > >
> > > It's similar to the redundant encoding, but done within the Opus
> > bitstream,
> > > rather than at the RTP level.
> > >
> > > >
> > > > Section 4.1
> > > >
> > > > Does it make sense to give subsection backreferences when talking about
> > > > (e.g.) redundant encoding?
> > > >
> > >
> > > Yes, this could be done easily.
> > >
> > > >
> > > > 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?
> > > >
> > >
> > > Agreed - earlier versions of flexfec were slightly different.
> > >
> > > >
> > > > 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?
> > > >
> > >
> > > This para only applies to audio. The following para discusses video, but
> > is
> > > SHOULD-strength given the relative newness of flexfec.
> > >
> > > >
> > > > 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).
> > > >
> > >
> > > flexfec is not quite a subset of generic FEC, since it also has a
> > > 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?
> >
> 
> 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.

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

> 
> > > >
> > > > 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.
> > > >
> > > >  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.
> >
> > 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.
> >
> 
> 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.

Okay.  Thanks for confirming!

-Benjamin

> >
> > Thanks for the updates and confirmations of my understanding,
> >
> > Benjamin
> >