Re: [Ice] I submitted and plan to present draft-thatcher-ice-remove-candidate in Berlin

Emil said:

"So I don't think continuous nomination is a good argument here even if
we keep waving it all over the place :) ."

[BA] It has always seemed to me that continuous nomination is not a "thing"
per se, but an inextricable part of Trickle ICE in that it is an
implementation decision as to when the gathering process is considered
complete.  So an implementation can choose to provide a local
"end-of-candidates" indication once it has gathered on existing interfaces,
or it could delay some arbitrary (perhaps infinite) time to allow new
interfaces to come up or for interfaces to go down.

If there are considerations relating to this that an implementation needs
to consider (such as implications for unfreezing) they are currently not
being articulated in the Trickle ICE specification. So either the
specification is negligent in this regard, or "continuous nomination" is an
optional capability that implementations can choose to support (or not),
with no interoperability implications.

On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov <emcho@jitsi.org> wrote:

> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
> >
> >
> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <emcho@jitsi.org> wrote:
> >>
> >> Are there any cases where you think this would be useful other than
> >> abetter connection with a server?
> >
> > Yes: continual gathering (aka continuous nomination) would benefit from
> > this.
>
> Last time we discussed continuous nomination (in Prague last year) it
> sounded to me that there were no arguments about what it was bringing
> on top of simple ICE restarts. It is my understanding that optimizing
> those (if at all necessary) was a more acceptable direction.
>
> So I don't think continuous nomination is a good argument here even if
> we keep waving it all over the place :) .
>
> >> If all that is changing is the connection with the server then it sounds
> >> to me like we should rather come up with a way to update the local side
> of
> >> the binding and not bother the remote agent with it.
> >
> > That would be TURN mobility, or some new equivalent (
> > the TURN mobility draft has expired).
>
> Something like that yes.
>
> > That is an option that we'd like to
> > explore implementing, but it's much more work to standardize, implement,
> and
> > deploy (both on client and server).  Whereas this is a simply mechanism
> that
> > is quick to standardize, implement, and deply, and it's useful for other
> > things (as mentioned above).
>
> On a first glance the whole ICE idea is very simple and easy to
> standardise, implement and deploy: gather and try everything. pick
> what works.
>
> I think 13 years after the initial idea was being floated on the IETF
> we know better.
>
> In other words:
>
> First I don't think it's that simple at all. I am particularly
> concerned about potential race conditions with the ICE state machine
> and the trickling itself. Same for interactions with aggressive
> nomination.
>
> Second, while we may be able to solve the above, I am worried that the
> increased complexity will not justify something that is a very limited
> solution to a more general problem. So we are setting the stage for
> redundancy and that's not something we need with ICE.
>
> Also, have you done any measurements or estimates on exactly what we
> are trying to optimize here? Some several hundred milliseconds of
> streaming over TCP rather than UDP?
>
> Emil
>
>
> >> Emil
> >>
> >>
> >> On Tuesday, 12 July 2016, Peter Thatcher <pthatcher@google.com> wrote:
> >>>
> >>> I submitted draft-thatcher-ice-remove-candidate and would like to speak
> >>> about in my allotted time on the agenda when I will also be speaking
> about
> >>> draft-thatcher-ice-network-cost and draft-thatcher-ice-renomination.
> >>>
> >>> It's a very simple draft. Basically it says you can "remove" candidates
> >>> just like trickle-ice allows you to add candidates. You could probably
> read
> >>> it in 3 minutes. Please do so:
> >>>
> >>> https://www.ietf.org/id/draft-thatcher-ice-remove-candidate-00.txt
> >>>
> >>> Thanks,
> >>> Peter (Chair hat off)
> >>
> >>
> >>
> >> --
> >> sent from my mobile
> >
> >
>
>
>
> --
> https://jitsi.org
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>