Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-fec-08: (with COMMENT)

Thanks for your comments. See below:

On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell <ben@nostrum.com> wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-rtcweb-fec-08: Yes
>
> 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:
> ----------------------------------------------------------------------
>
> Thanks for this effort. I am balloting "yes", but have some minor comments:
>
> §8:
> - "Given this, WebRTC implementations SHOULD consider using RTX or
> flexfec retransmissions instead of FEC when RTT is low,"
>
> "consider" seems vague for a normative requirement. Can you describe
> concrete
> requirements? Otherwise I suggest descriptive language.
>

Perhaps "prefer" rather than "consider" would be less squishy.

>
> Can you give guidance on what RTT would be reasonable to consider as "low"?
>

This is somewhat application-dependent, but ~100 ms would be a reasonable
threshold.

>
> - "Note that when probing bandwidth, i.e., speculatively sending extra
> data to determine if additional link capacity exists, FEC SHOULD be
> used in all cases."
>
> I assume the point of this is the redundant FEC data should _be_ that extra
> data. But one could read this to mean that, if you are already sending
> extra
> data, you should also use FEC.
>

I see what you mean, agree this could be clarified.

>
> §9, 2nd paragraph:
>
> I'm by no means an expert in this, and leave it to the crypto experts to
> know
> if this matters, but does the additional redundancy of FEC have any impact
> on
> SRTP encryption?
>

My understanding is that the fact that FEC is sent as its own stream with
its own IV means that even if the data was identical to the primary
payload, there would be no issue. But given that no new mechanisms are
being proposed in this document, it's probably covered elsewhere.

>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>