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

[Ben Campbell <[e-mail]>]

Thanks for the response. Comments below:

> On Feb 22, 2019, at 6:31 PM, Justin Uberti <[e-mail]> wrote:
> 
> Thanks for your comments. See below:
> 
> On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:

[…]

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

Prefer is better, thanks.

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

Would it make sense to say that the threshold for “low” is application dependent, but that would be a reasonable number for “typical” applications?


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

Thanks

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

Is that true for the case of in-band FEC at the codec level?

> But given that no new mechanisms are being proposed in this document, it's probably covered elsewhere.

I can accept that argument.

Thanks!

Ben.