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

[Ben Campbell <[e-mail]>]

> On Feb 22, 2019, at 7:17 PM, Justin Uberti <juberti=[e-mail]> wrote:
> 
> 
> 
> On Fri, Feb 22, 2019 at 4:57 PM Ben Campbell <[e-mail] <mailto:[e-mail]>> wrote:
> Thanks for the response. Comments below:
> 
>> On Feb 22, 2019, at 6:31 PM, Justin Uberti <[e-mail] <mailto:[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?
> 
> In the RFC 2198 case, SRTP is once again run over a new packet, again with a new IV (from a new sequence number), and a new primary payload, so the cipher state will be entirely different when the previous data is re-encrypted. In the codec in-band case, you have a new bitstream, so there are no repeated bytes.

Okay, I’m convinced. Thanks!

Ben.