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

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

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: 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: Adam Roach <[email-masked]>
Date: Wed, 17 Oct 2018 15:45:53 -0500

Cullen --

Thanks for sharing your perspective. In the spirit of section 3 of RFC 
7282, I
believe that the specific points you raised have been considered and 
addressed
(even though they haven't necessarily all been accommodated). I see evidence
that the impacted working groups have taken the objections seriously and
provided technically sound responses. I have taken steps to address the
process objection you highlighted regarding the timing and duration of the
period for feedback. Your input regarding the impact on two specific 
documents
beyond that which was called out in the original proposal has been noted and
is in the process of being addressed.

Specific details pertaining to each raised point can be found below.

On 9/6/18 3:24 PM, Cullen Jennings wrote:

 > It is not merely an issue of which document we point out, and they 
are all the
 > same. The problem is the timing of 8445 is not clearly interoperable 
with the
 > timing of 5245. ICE relies on both sides to do sequence things at 
roughly the
 > same order so that suicided packets open pinholes in the reverse 
direction at
 > the right time. The changes in timing change how this happens and is 
a problem
 > for the ICE algorithm.
 >
 > This was discussed in the WG, and though not everyone agrees it is a 
problem
 > or not, no one has ever provided a convincing argument that it is not.

Peter has attempted to do so. It is difficult to prove that something is 
not a
problem, but the explanation seems pretty compelling, especially when 
coupled
with Justin's later observation that the currently deployed Chrome code more
closely resembles RFC 8445 than it does RFC 5245.

 > This is
 > a very substantial change to the on the wire protocol and at a 
minimum would
 > need to be reviewed and discussed in the WG not slipped through in 
Auth 48
 > during a one week period in the summer while everyone is on vacation.

Based on your feedback, I have kept the issue open for eight weeks, 
including
four of which that are unambiguously not part of the northern hemisphere's
summer. I will also be running another IETF last call for the JSEP document,
to ensure proper exposure of this set of changes to the IETF community.

 > We will
 > also need to change other examples and normative text in drafts like 
JSEP.

A plan is being put in place to address JSEP's normative text (the authors
have already prepared a PR to address these changes), while the latest 
version
of the SDP examples document already contains such modifications.

 > I would propose that instead of the parts of specs that use the trickle
 > mechanism purely reference that part of the new ICE spec that defines the
 > syntax and say to transfer trickle candidates.

This preference has not received support from other participants.

 > 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. It is doubtful Justin will want to implement the 8445 
mechanisms of
 > supporting both new and old ICE.

Justin Uberti has indicated that Chrome's current behavior more closely
reflects RFC 8445 behavior than it does the behavior specified by RFC 5245,
and so this change brings the published documents closer to current browser
implementations than any proposed alternatives.  Nils Ohlmeier, who owns 
this
decision for Mozilla, has indicated that Firefox intends to implement 
both RFC
8445 and RFC 5245 behavior and use the "a=ice2" flag to determine which to
use. To the extent that Cisco products work with browsers deployed today,
these statements would seem to ensure that they should continue to do so in
the face of the plan I outlined.

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

Given what Justin has indicated about Chrome's current behavior, this logic
would argue for moving to reference RFC 8445 rather than not doing so.

Again, thanks for taking the time to clearly spell our your objections 
so that
they could be fully considered by the interested parties. I believe that we
are in a better place, both from a process and from a protocol perspective,
because of your input.

/a

...
>> On Aug 22, 2018, at 10:58 AM, Adam Roach <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Members of the ART community interested in real-time communications:
>>
>> Cluster 238 [1] is a set of inter-related documents dealing with 
>> real-time communications. The bulk of these documents relate to 
>> WebRTC, either directly or indirectly. They also form the 
>> underpinnings of CLUE. As of now, there are 34 documents in the 
>> cluster that are not yet published, with 25 of these already in the 
>> RFC Editor's queue. The dependency graph among these documents is 
>> such that the bulk of them can be published as soon as a specific six 
>> of them are handed off to the RFC editor, and we expect this to 
>> happen in the upcoming few months.
>>
>> One long-running complication for this cluster of documents is that 
>> each of the documents were developed over the course of seven years, 
>> in concert with implementations, while the ICE protocol itself was 
>> undergoing significant revision. As a consequence, some documents 
>> rely (directly or indirectly) on the older ICE specification (RFC 
>> 5245), while some rely on the newer one (RFC 8445). In some cases, 
>> documents refer directly to the old version and transitively to the 
>> new version.
>>
>> It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the 
>> mechanism described in RFC 8445 has some  changes that break 
>> backwards compatibility with the mechanism defined in RFC 5245 (with 
>> such behavioral changes controlled by an SDP attribute, allowing 
>> clients to transition from one to the other).
>>
>> Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC 
>> protocol in the IETF) refers to directly to RFC 5245, while relying 
>> on the behavior defined in draft-ietf-ice-trickle; 
>> draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 
>> handling. JSEP's reference to RFC 5245 is a practical consideration 
>> that acknowledges that current deployments of WebRTC implement the 
>> older version of ICE. At the same time, these deployed 
>> implementations use a somewhat older version of 
>> draft-ietf-ice-trickle in concert with the older ICE implementation.
>>
>> In order to get Cluster 238 published, we need to find some way to 
>> rationalize its references to ICE. At a basic level, the ART Area 
>> Directors do not believe that it makes sense to publish new documents 
>> that refer to an already obsoleted RFC. At the same time, we 
>> recognize that there is value in our specifications being informed by 
>> running code. For WebRTC, the complexity of the system has led us to 
>> a point that we must choose between these principles. Our proposal is 
>> to choose the first, while acknowledging the second.
>>
>> This would result in a request to the RFC editor to update all 
>> references to RFC 5245 in the Cluster 238 documents to instead point 
>> to RFC 8445. Documents not yet in the RFC editor queue would be 
>> updated prior to IESG review. We would further request that the RFC 
>> editor add the following text to draft-ietf-rtcweb-overview and 
>> draft-ietf-rtcweb-jsep:
>>
>>
>>> 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. 
>> RFC 8445 would be a normative reference for both documents, while RFC 
>> 5245 would be informative.
>>
>> There is one more minor complication, in that 
>> draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 
>> 5245) is intended to be an exhaustive list of the SDP attributes 
>> defined in the documents it lists, and RFC 8445 adds a new "ice2" 
>> attribute that was not present in RFC 5245. For this reason, we would 
>> also ask the RFC Editor to add a new row to the table in 
>> draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:
>>
>>
>>>     +-------------------+---------------------------+-------+-----------+
>>>     | Name              | Notes                     | Level | Mux       |
>>>     |                   |                           |       | Category  |
>>>     +-------------------+---------------------------+-------+-----------+
>>>     | ice2              | Not Impacted              | S     | NORMAL    |
>>>     |                   |                           |       |           |
>>>     +-------------------+---------------------------+-------+-----------+
>>
>> For clarity, the affected documents are as follows.
>>
>> The following documents would be updated to reference RFC 8445 prior 
>> to IESG evaluation:
>>
>>   * draft-ietf-clue-datachannel
>>   * draft-ietf-clue-signaling
>>   * draft-ietf-rtcweb-security
>>   * draft-ietf-rtcweb-security-arch
>>
>>
>> The following documents would be updated to reference RFC 8445 by the 
>> RFC Editor:
>>
>>   * draft-ietf-mmusic-mux-exclusive
>>   * draft-ietf-mmusic-sctp-sdp
>>   * draft-ietf-rtcweb-alpn
>>   * draft-ietf-rtcweb-data-channel
>>   * draft-ietf-rtcweb-rtp-usage
>>
>>
>> The following documents would be updated to reference RFC 8445 and 
>> have the text proposed above added to them:
>>
>>   * draft-ietf-rtcweb-jsep
>>   * draft-ietf-rtcweb-overview
>>
>>
>> The following document would be updated to reference RFC 8445 by the 
>> RFC Editor, and include a new row for "ice2" in its Section 5.12, as 
>> described above:
>>
>>   * draft-ietf-mmusic-sdp-mux-attributes
>>
>>
>> This message is cross-posted to the affected working groups. Because 
>> the issue at hand has impact across several different groups, we ask 
>> that all follow-up discussion take place on <[email-masked]>. Thank you.
>>
>> /Adam on behalf of the ART Area Directors
>>
>> ____
>> [1] https://www.rfc-editor.org/cluster_info.php?cid=C238
>>
>> clue mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/clue
>
>
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art