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

From: Ben Campbell <[email-masked]>
Date: Wed, 20 Feb 2019 09:56:19 -0800

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.

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

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

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

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Feb 2019 16:31:07 -0800

Thanks for your comments. See below:

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

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.

> data, you should also use FEC.

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

> if this matters, but does the additional redundancy of FEC have any impact

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 22 Feb 2019 18:57:05 -0600

Thanks for the response. Comments below:

> On Feb 22, 2019, at 6:31 PM, Justin Uberti <[email-masked]> wrote:
> 
> On Wed, Feb 20, 2019 at 9:56 AM Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:

[…]

Prefer is better, thanks.

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

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

Thanks

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

---

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

On Fri, Feb 22, 2019 at 4:57 PM Ben Campbell <[email-masked]> wrote:

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

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.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 22 Feb 2019 21:51:23 -0600

> On Feb 22, 2019, at 7:17 PM, Justin Uberti <juberti=[email-masked]> wrote:
> 
> 
> 
> On Fri, Feb 22, 2019 at 4:57 PM Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 22, 2019, at 6:31 PM, Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> 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.