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

From: Justin Uberti <[email-masked]>
Date: Mon, 1 Oct 2018 13:27:50 -0700

[dropping some DLs]

I think this is probably a day of work, but will probably take 2 weeks to
author and get approval for.

If we go down this path, I would also suggest taking the two pending PRs in
JSEP, which will also impact the examples.
https://github.com/rtcweb-wg/jsep/pull/849
https://github.com/rtcweb-wg/jsep/pull/850

On Mon, Oct 1, 2018 at 1:23 PM Justin Uberti <[email-masked]> wrote:

> I think this is probably a day of work, but will probably take 2 weeks to
> author and get approval for.
>
> If we go down this path, I would also suggest taking the two pending PRs
> in JSEP, which will also impact the examples.
> https://github.com/rtcweb-wg/jsep/pull/849
> https://github.com/rtcweb-wg/jsep/pull/850
>
> On Mon, Oct 1, 2018 at 12:17 PM Adam Roach <[email-masked]> wrote:
>
>> On 9/27/18 6:20 PM, Justin Uberti wrote:
>> > 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.
>>
>>
>> If I read what you're saying correctly, it sounds like you're talking
>> about changes that are significant enough that we'll have to put JSEP
>> through IETF last call and through the IESG again. That being the case,
>> and the rest of the cluster being so close to done, I'd really prefer to
>> see this done very soon, if such changes are required. When do you
>> believe such an update could be available?
>>
>> I've copied the RFC Series Editor on this note for her awareness.
>>
>> /a
>>
>>

---

From: Adam Roach <[email-masked]>
Date: Mon, 1 Oct 2018 14:17:24 -0500

/a

---

From: Heather Flanagan <[email-masked]>
Date: Tue, 2 Oct 2018 09:47:00 -0700

Thanks for copying me in, Adam. I definitely agree that this level of 
change is significant enough that it can't be handled in AUTH48. But, 
better it be right than fast!

-Heather

On 10/1/18 1:27 PM, Justin Uberti wrote:
> [dropping some DLs]
>
> I think this is probably a day of work, but will probably take 2 weeks 
> to author and get approval for.
>
> If we go down this path, I would also suggest taking the two pending 
> PRs in JSEP, which will also impact the examples.
> On Mon, Oct 1, 2018 at 1:23 PM Justin Uberti <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think this is probably a day of work, but will probably take 2
>     weeks to author and get approval for.
>
>     If we go down this path, I would also suggest taking the two
>     pending PRs in JSEP, which will also impact the examples.
>     On Mon, Oct 1, 2018 at 12:17 PM Adam Roach <[email-masked]
>     <mailto:[email-masked]>> wrote:
>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 12 Oct 2018 08:13:43 -0700

On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti <juberti=
[email-masked]> wrote:

> 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.
>
>
I've updated the references to 8445 (and to draft-ietf-mmusic-ice-sip-sdp)
in this PR: https://github.com/rtcweb-wg/jsep/pull/851

I've also added the ice2 processing and added ice2 to the examples in the
same PR.

What did you mean by "and note"?  Is there something more needed?

> On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pthatcher=
> [email-masked]> 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 <[email-masked]> wrote:
>>
>>>
>>> On Sep 7, 2018, at 1:25 AM, Christer Holmberg <
>>> christer.holmberg@ericsson..com <[email-masked]>> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>> _______________________________________________
>
>
>> Ice mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ice
>>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 12 Oct 2018 18:08:29 -0700

On Fri, Oct 12, 2018 at 8:14 AM Peter Thatcher <pthatcher=
[email-masked]> wrote:

>> than 5245, so I don't see any issues associated with snapping this cluster
>> to 8445 (aside from the work involved).
>>

Thanks for doing this, Peter.

> What did you mean by "and note"?  Is there something more needed?

The note in question is the text that Adam mentioned in the original email:

*While this specification formally relies on [RFC8445], at the time of its
publication, the majority of WebRTC implementations support the version of
ICE described in [RFC5245], and use a pre-standard version of the trickle
ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute
defined in [RFC8445] can be used to detect the version in use by a remote
endpoint and to provide a smooth transition from the older specification to
the newer one. *

I do think we need text similar to this to be added to S 5.11 (processing
an answer) in JSEP.

>>> 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:
>>>
>>> 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
>>>> change.. These gratuitous changes, years after the implementation were

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Sat, 13 Oct 2018 11:22:58 +0200

p0090

El lun., 1 oct. 2018 23:11, Adam Roach <[email-masked]> escribió:

> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Sat, 13 Oct 2018 16:45:09 -0700

[removing DLs again]

We are taking a few other outstanding issues as part of this rev
(potentially including https://github.com/rtcweb-wg/jsep/issues/843 which
you noted), so I think a new LC is warranted.

Aiming for a new doc version on Monday.

On Sat, Oct 13, 2018 at 1:50 PM Justin Uberti <[email-masked]> wrote:

> We are taking a few other outstanding issues as part of this rev
> (potentially including https://github.com/rtcweb-wg/jsep/issues/843 which
> you noted), so I think a new LC is warranted.
>
> Aiming for a new doc version on Monday.
>
> On Sat, Oct 13, 2018 at 2:52 AM Christer Holmberg <
> [email-masked]> wrote:
>
>> Hi,
>>
>>
>> Personally I don't think updating of references and examples require a
>> new IETF last call.
>>
>>
>> Do people foresee any changes to the technical JSEP procedures due to the
>> reference update?
>>
>>
>> Regards,
>>
>>
>> Christer
>>
>>
>> ------------------------------
>> *From:* clue <[email-masked]> on behalf of Sergio Garcia Murillo <
>> [email-masked]>
>> *Sent:* Saturday, October 13, 2018 12:22 PM
>> *To:* Adam Roach
>> *Cc:* [email-masked]; [email-masked]; Heather Flanagan (RFC Series
>> Editor); [email-masked]; pthatcher=[email-masked];
>> [email-masked]; RTCWeb IETF; Justin Uberti
>> *Subject:* Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and
>> Cluster 238
>>
>> p0090
>>
>> El lun., 1 oct. 2018 23:11, Adam Roach <[email-masked]
>> <adam@nostrum..com>> escribió:
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 13 Oct 2018 09:51:48 +0000

Hi,

Personally I don't think updating of references and examples require a new IETF last call.

Do people foresee any changes to the technical JSEP procedures due to the reference update?

Regards,

Christer

________________________________
From: clue <[email-masked]> on behalf of Sergio Garcia Murillo <[email-masked]>
Sent: Saturday, October 13, 2018 12:22 PM
To: Adam Roach
Cc: [email-masked]; [email-masked]; Heather Flanagan (RFC Series Editor); [email-masked]; pthatcher=[email-masked]; [email-masked]; RTCWeb IETF; Justin Uberti
Subject: Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238

p0090

El lun., 1 oct. 2018 23:11, Adam Roach <[email-masked]<mailto:adam@nostrum..com>> escribió:

/a

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb