Re: [clue] [Ice] [MMUSIC] [art] ICE, ICE-bis, and Cluster 238

[Justin Uberti <[e-mail]>]

I agree with Peter. Chrome's implementation is already closer to 8445 than
5245, so I don't see any issues associated with snapping this cluster to
8445 (aside from the work involved).

On that topic, note that JSEP will need a few more changes than just the
addition of the 8445 reference and note; the examples will have to be
updated, as will the logic regarding generation of offers and answers and
their parsing (to deal with the new ice-option). These changes will be
modest but probably will need to be done by the authors.

On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pthatcher=
[e-mail]> wrote:

> I'm late to the discussion, and reading through it, it seems that we have
> a lot of back and forth without addressing Cullen's root issue.  Let me see
> if I understand Cullen's root issue correctly.  I think it's something like:
>
> 1.  Cisco has existing code that it wants to call "WebRTC 1.0 compliant"
> without changing to be compliant with 8445.
>
> 2.  Cisco has existing code that it wants to continue to interoperate with
> endpoints, especially Chrome, even as they make changes to become 8445
> compliant.  And they don't want to have to test against old and new
> versions.
>
> Cullen, is that accurate?
>
>
>
> OK, so some of my thoughts:
>
> 1.  I don't think there is any interop risk here at all related to
> timings.  If you're worried about the drop in minimum check interval going
> from 20ms to 5ms, don't.  Just because the spec allows for going that low
> doesn't mean endpoints will.  And if they do, they'll do it carefully.
> Endpoints can and should still choose a value that works best regardless of
> the min in the spec.  For example, Chrome is still using an interval of
> 48ms (we're not in a rush to lower it, but we have non-browser endpoints
> that do go lower).  And if we roll out a lower value, it will be via
> experiments or opt-ins and carefully tracked to make sure connectivity
> rates don't drop.  If any problem were found in practice, it would be
> quickly reverted.
>
> 2.  I don't think there is any interop risk here related to nomination
> either.
> Chrome's default behavior has never been compliant to any spec anyway, and
> it's never been an issue.  And like with ping intervals, any changes to
> implementations will be done slowly and carefully.
>
> 3.  I don't think it really matters to major implementations what the
> dependency graph looks like.  Whether some point to 5245 and others to 8445
> or if all of them point to 8445, it doesn't matter, implementations will
> behave the same either way.  Chrome, for example will adjust timings as
> works well in practice (perhaps someday to below 20ms interval) regardless
> of which RFCs point to 8445 and which point to 5245.  If interop issues
> ever do come up, then they can be fixed.  And that has nothing to do with
> which RFCs point to 5245 and which point to 8445.
>
> 5.  You're going to need to test against different versions of different
> browser no matter what the RFC references are.  ICE timings and nominations
> seem like the least of your testing problems.  But on the flip side, Chrome
> (and I assume other browsers) have been very slow and careful when making
> changes to the ICE code.
>
> 6.  FlexICE should go a long way to putting the web app in control of the
> ICE behavior.  So if you are worried about what browsers will do with ICE,
> I suggest supporting the FlexICE effort.  In fact, it's the result of your
> proposal at TPAC in 2017 for wanting to have lower-level of control of
> ICE..  If we get that into all the browsers, you won't have to worry any
> more about any of this because you'll be in control (assuming you control
> the web app).
>
> Altogether, I don't see any reason to not reference 8445 everywhere, at
> least not any related to interop risk and web browsers.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings <[e-mail]> wrote:
>
>>
>> On Sep 7, 2018, at 1:25 AM, Christer Holmberg <
>> [e-mail]> wrote:
>>
>> > Cisco has implemented stuff that is WebRTC 1.0 compliant without this
>> change. These gratuitous changes, years after the implementation were
>> coded, with no real benefit will ensure that we are not
>> > and will not become compliant with the RFC. It's unlikely we will
>> upgrade to the new ICE until it has real befits.
>>
>> The main reason we did 8445 was because people had identified issues with
>> 5245. The work was driven mostly by the WebRTC community, including
>> yourself and the Chrome people (or, at least the Google people), and one of
>> the reason it took time to finalize 8445 was because you (among others)
>> wanted to make sure we get things right (by making network measurements
>> etc). Are you now saying all those changes bring no benefit? Did we all
>> waste our time?
>>
>>
>> Our testing, which we do not share, dig not indicate an improvement of
>> connectivity rates. I did not see results from others that did. Some of the
>> early test results from others that drove this work were not reproducible
>> in our testing. The one thing I think most people did find is that the more
>> out of sync the pacing of the two agents was, the worse the connectivity
>> was. But all of this is water under the bridge, we have old and new ice,
>> people can use either. What we are talking about here is what is the
>> minimum bar for WebRTC 1.0
>>
>>
>> > It is doubtful Justin will want to implement the 8445 mechanisms of
>> supporting both new and old ICE. Instead, we will move to say "works
>> with Browser X version Y or later." We have watched at W3C as it moved to
>> be that unless chrome does it, it rare that it becomes a standard.
>> > Right here I am watching how the stuff IETF defines will be less
>> relevant than the issue of what chrome implements.
>>
>> What exactly would Justin have to change?
>>
>>
>>
>> For us, the largest part is having to test for both old and new - it’s
>> not easy to do good automated testing for ICE.
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> Ice mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ice
>