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

[Peter Thatcher <[e-mail]>]

On Wed, Jul 13, 2016 at 12:45 PM, Emil Ivov <[e-mail]> wrote:

> On Wed, Jul 13, 2016 at 10:22 PM, Peter Thatcher <[e-mail]>
> wrote:
> >
> >
> > On Tue, Jul 12, 2016 at 10:38 AM, Emil Ivov <[e-mail]> 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 :) .
>
>
​Continual gathering is a separate topic that we can save for another day.



> >> 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.
>
>
​It sounds like you are making the argument that ICE has reached some kind
of "peak complexity" and can no longer be changed because it's already too
complex.  Is that what you're claiming?




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

​I don't know what this has to do with TCP vs. UDP.​

The real world problem here is that if you have two network interfaces
(WiFi and Cell) and ​ipv4 and ipv6 and 2 TURN servers and try to connect to
each over TCP and UDP, you end up with 2 x 2 x 2 x 2 = 16 TURN candidates
(at least; this ignores TCP w/ TLS).  Then both sides do that, and you have
16 * 16 = 256 TURN-TURN candidate pairs.  That's a lot.  So how do you
avoid that problem?   TURN mobility is one option, and I'd like to see TURN
mobility happen.  But candidate removal is also an option, and it's a lot
more simple.



>
> Emil
>
>
> >> Emil
> >>
> >>
> >> On Tuesday, 12 July 2016, Peter Thatcher <[e-mail]> 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
>