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

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 4 Sep 2018 09:16:25 +0000

Hi Adam,

Is there a real need to update draft-ietf-clue-signaling-13

There is an informative reference to RFC5245 and the text is

A CLUE call may involve sending and/or receiving significant numbers
   of media streams.  Conventionally, media streams are sent and
   received on unique ports.  However, each separate port used for this
   purpose may impose costs that a device wishes to avoid, such as the
   need to open that port on firewalls and NATs, the need to collect ICE
   candidates [RFC5245<https://tools.ietf.org/html/rfc5245>], etc.

So since RFC8445b obsolete RFC5245 this is not a major issue.

Anyhow I will ask the authors to update the document

Roni Even

From: clue [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Wednesday, August 29, 2018 9:13 PM
To: Applications and Real-Time Area Discussion
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [clue] ICE, ICE-bis, and Cluster 238

It's been a week; so far there have been no objections to this plan, and several messages in support. I plan to consult with the other ART ADs to evaluate consensus on this proposal next week, and take appropriate action. If you have thoughts to share, please send them to the ART mailing list before September 5th.

Thanks!

/a

On 8/22/18 12:58 PM, Adam Roach 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]><mailto:[email-masked]>. Thank you.

/Adam on behalf of the ART Area Directors

____
[1] https://www.rfc-editor.org/cluster_info.php?cid=C238

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 6 Sep 2018 13:24:45 -0700

I object to this plan. 

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. 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. We will also need to change other examples and normative text in drafts like JSEP. 

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. 

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

> On Aug 22, 2018, at 10:58 AM, Adam Roach <[email-masked]> wrote:
> 
> draft-ietf-clue-datachannel
> draft-ietf-clue-signaling
> draft-ietf-rtcweb-security
> draft-ietf-rtcweb-security-arch
> 
> draft-ietf-mmusic-mux-exclusive
> draft-ietf-mmusic-sctp-sdp
> draft-ietf-rtcweb-alpn
> draft-ietf-rtcweb-data-channel
> draft-ietf-rtcweb-rtp-usage
> 
> draft-ietf-rtcweb-jsep
> draft-ietf-rtcweb-overview
> 
> 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]> <mailto:[email-masked]>. Thank you.
> 
> [1] https://www.rfc-editor.org/cluster_info.php?cid=C238 <https://www.rfc-editor.org/cluster_info.php?cid=C238>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 6 Sep 2018 13:40:59 -0700

On Thu, Sep 6, 2018 at 1:25 PM Cullen Jennings <[email-masked]> wrote:

>
>  It's unlikely we will upgrade to the new ICE until it has real benefits.
>

[BA] Do not worry. Since there are limited benefits in 8445, upgrades will
be slow to arrive at best, except perhaps if they are bundled with Trickle
support.

It is doubtful Justin will want to implement the 8445 mechanisms of
> supporting both new and old ICE.
>

[BA] Yes, the 8445 negotiation mechanism never really made sense (though
Trickle negotiation does make sense).

Right here I am watching how the stuff IETF defines will be less relevant
> than the issue of what chrome implements.
>

[BA] Implementations have always mattered. What has changed is that the
IETF seems to be paying less attention to cost/benefit tradeoffs.

> 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.
>
> 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:
>
>    - draft-ietf-clue-datachannel
>    - draft-ietf-clue-signaling
>    - draft-ietf-rtcweb-security
>    - draft-ietf-rtcweb-security-arch
>
>
>    - draft-ietf-mmusic-mux-exclusive
>    - draft-ietf-mmusic-sctp-sdp
>    - draft-ietf-rtcweb-alpn
>    - draft-ietf-rtcweb-data-channel
>    - draft-ietf-rtcweb-rtp-usage
>
>
>    - 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]> <[email-masked]>. Thank
> you.
>
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 6 Sep 2018 19:54:08 -0500

On 9/6/18 3:24 PM, Cullen Jennings wrote:
> 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.

Unfortunately, it's not quite so simple. The mismatch with trickle-ice 
is only the most obvious problem. In practice, there are a few dozen 
places where unpublished documents in the cluster refer directly to one 
version of ICE, and indirectly to another, or indirectly to both.

To help wrap our collective minds around this issue, I've put together a 
dependency graph that shows which Cluster 238 documents refer to which 
version of ICE. The red lines indicate references (directly or 
indirectly) to RFC 5245, while the purple lines indicate references to 
RFC 8445. The thickness of the line indicates how many hops away from 
ICE the reference is. Dotted lines are informative references.

https://trac.ietf.org/trac/art/wiki/c238

To put a finer point on this, it took me a couple of hours to pare this 
graph down to something that was small enough to look at and actually 
understand -- there are actually twice as many documents involved in 
this mess, but including them makes the situation too confusing to even 
start to get a grip on.

Everywhere you see a purple document with a red arrow or vice-versa is a 
place we need to figure out how to handle this mismatch. You can push 
the boundaries around, but the count of mismatches is pretty much the 
same no matter how you do that. On a first order estimation, this is 
days -- or, more likely, weeks of work. And I'm talking about 
person-hours, not calendar time. If you can do this, or find someone to 
step up and do it, then your proposal would be a viable alternative to 
the one that the ART ADs have proposed. Short of that, I'm not sure how 
we can do what you want.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2018 07:25:13 +0000

Hi,

> I object to this plan.
>
> 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. 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. We will also need to change other examples and normative text in drafts like JSEP.

What normative text do you need to change in JSEP?

In fact, I would even claim that the JSEP text is more aligned with 8445 than 5245. For example, JSEP does not talk about aggressive and normative nomination, only about nomination.

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

It is not only about the syntax. The trickle procedures are based on procedures in 8445.

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

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

Regards,

Christer

On Aug 22, 2018, at 10:58 AM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

   |                   |                           |       | Category  |

   |                   |                           |       |           |

  *   draft-ietf-rtcweb-jsep

[email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2018 07:31:17 +0000

Hi,

>> It is doubtful Justin will want to implement the 8445 mechanisms of supporting both new and old ICE. 
>
> [BA] Yes, the 8445 negotiation mechanism never really made sense (though Trickle negotiation does make sense). 

Exactly what 8445 negotiation mechanism does not make sense, compared to 5245?

> [BA] Implementations have always mattered. What has changed is that the IETF seems to be paying less attention to cost/benefit tradeoffs.

I can't of course speak for everyone, but some implementers I talked to during the years of work on 8445 told me that the way they implemented 5245 was actually more 8445 than 5245.

Regards,

Christer

On Aug 22, 2018, at 10:58 AM, Adam Roach <mailto:[email-masked]> wrote:

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 mailto:[email-masked]. Thank you.
mailto:[email-masked]

mailto:[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Sep 2018 10:24:40 -0600

That’s a very useful graph but when I look at the what is actually used in the purple links, most of them seem they could trivial work with any version of ICE with the exception of the few places trickle is used and need the explicit stuff around how to deal with trickle. 

> On Sep 6, 2018, at 6:54 PM, Adam Roach <[email-masked]> wrote:
> 
> Unfortunately, it's not quite so simple. The mismatch with trickle-ice is only the most obvious problem. In practice, there are a few dozen places where unpublished documents in the cluster refer directly to one version of ICE, and indirectly to another, or indirectly to both.
> 
> To help wrap our collective minds around this issue, I've put together a dependency graph that shows which Cluster 238 documents refer to which version of ICE. The red lines indicate references (directly or indirectly) to RFC 5245, while the purple lines indicate references to RFC 8445. The thickness of the line indicates how many hops away from ICE the reference is. Dotted lines are informative references.
> 
> To put a finer point on this, it took me a couple of hours to pare this graph down to something that was small enough to look at and actually understand -- there are actually twice as many documents involved in this mess, but including them makes the situation too confusing to even start to get a grip on.
> 
> Everywhere you see a purple document with a red arrow or vice-versa is a place we need to figure out how to handle this mismatch. You can push the boundaries around, but the count of mismatches is pretty much the same no matter how you do that. On a first order estimation, this is days -- or, more likely, weeks of work. And I'm talking about person-hours, not calendar time. If you can do this, or find someone to step up and do it, then your proposal would be a viable alternative to the one that the ART ADs have proposed. Short of that, I'm not sure how we can do what you want.
> 
> /a
> 
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Sep 2018 10:36:35 -0600

> On Sep 7, 2018, at 1:25 AM, Christer Holmberg <[email-masked]> wrote:
> 

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 

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2018 18:25:56 +0000

Hi,

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

I am talking about the test results that were shared (by Google, if I remember correctly) at one of the IETF meetings, which we used to modify some timer values. I'd have to dig in the archives for the details, but you said we can't move the draft forward before we get those results, and I think we waited 1-2 meeting cycles from them.

Note that I am not blaming you for wanting to set values based on real-life experience - that's a good thing. I am just surprised that everything we did now seems like a waste of time.

> 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 

Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not use aggressive nomination. Trickle is based on 8445, and aggressive nomination was deprecated in 8445. So, what exactly are you suggesting the minimum bar for WebRTC 1.0 should be? Some "profile" of 5245?
 
>>> 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.  

So, against what spec do you test trickle? 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Sep 2018 18:28:54 +0000

Hi,

>That’s a very useful graph but when I look at the what is actually used in the purple links, >most of them seem they could trivial work with any version of ICE with the exception of the >few places trickle is used and need the explicit stuff around how to deal with trickle. 

Trickle is based on "Emil's table", which is one of the major things we did in 8445. So, if you implement that for trickle, you've implemented most of 8445 :)

The other major thing we did in 8445 was the removal of aggressive nomination, which many seem to have done in their current implementations anyway...

Regards,

Christer

_______________________________________________
Ice mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ice

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Sep 2018 12:49:17 -0700

On Sep 7, 2018, at 11:25 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not use aggressive nomination. Trickle is based on 8445, and aggressive nomination was deprecated in 8445. So, what exactly are you suggesting the minimum bar for WebRTC 1.0 should be?

[BA] I am wary of attempts to support too many variations in the matrix of “Full Trickle”/“Half Trickle” and 8445/5245.

IMHO, the most likely variants are “Full Trickle”/8445 and perhaps “Half Trickle”/5245 although I would hope the later will be quickly superceded by the former.

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 7 Sep 2018 12:56:02 -0700

> On Sep 7, 2018, at 11:25, Christer Holmberg <[email-masked]> wrote:
> Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not use aggressive nomination.

Sorry but that is not correct. Firefox does use aggressive nomination. Chrome (and everyone who copies their full stack including their ICE implementation) does not. I’m not aware of any normative language for any of the WebRTC specs demanding to use full nomination only.

Best
  Nils Ohlmeier

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 7 Sep 2018 13:01:09 -0700

> On Sep 6, 2018, at 13:24, Cullen Jennings <[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. 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.”

Obviously I’m not Justin.
But the current plan for Firefox is to implement support for 8845 some time in 2019 and then have support for 5245 and 8845 going forward.

Best regards
  Nils Ohlmeier

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Sep 2018 07:48:34 +0000

Hi Nils,

>> 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. Instead, we will move to say "works 
>> with Browser X version Y or later.”
>

Do you have any ideas, on a high level, how big the differences will be?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Sep 2018 07:56:46 +0000

Hi,

>>> 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
>> 
> Sorry but that is not correct. Firefox does use aggressive nomination. Chrome (and everyone who copies their 
> full stack including their ICE implementation) does not. I’m not aware of any normative language for any of the 
> WebRTC specs demanding to use full nomination only.

With "full nomination" I assume you mean regular nomination (as defined in 5245)?

My point was that WebRTC defines the usage of "nomination", which is the terminology 8445 uses. I am not saying it's forbidden to use aggressive nomination, but as far as I know (I may be wrong) usage of it is not mentioned anywhere. 

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Sep 2018 21:52:20 -0700

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:

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

---

From: Justin Uberti <[email-masked]>
Date: Thu, 27 Sep 2018 16:20:47 -0700

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=
[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
> ICE..  If we get that into all the browsers, you won't have to worry any
>> 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.
>> 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.