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

[Peter Thatcher <[e-mail]>]

On Thu, Jul 14, 2016 at 9:19 AM, Emil Ivov <[e-mail]> wrote:

> On Thu, Jul 14, 2016 at 1:06 AM, Peter Thatcher <[e-mail]>
> wrote:
> >
> >
> > 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?
>
> And question the existence of this wonderful working group? No, of course
> not ;)
>
> What I am claiming is that ICE is too complex for *frivolous* updates
> that are likely to be superseded by newer more complete solutions like
> the one you mentioned in TRAM.
>
>
While I'm happy that TURN mobility is progressing, I expect it will be some
time before wide deployments TURN servers​
​
​ will have support for it.  And clients working with TURN servers that
don't support mobility will find it useful to signal candidate removal.

And I thought of another case outside of TURN candidates and continual
gathering where this is useful: when a network interface goes away at the
beginning of ICE setup.  It's useful to tell the remote side when this
happens to possibly avoid checking useless candidates.


Oh, and another:  if you have many TURN servers (say, 8), then you'll have
8*8 = 64 TURN-TURN candidates pairs, unless you are capable of removing
candidates for worse TURN servers.  TURN mobility doesn't help across TURN
servers (does it?)



> >> 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.
>
> Except that it's not (necessarily) 256.
>
> > So how do you avoid that problem?
>
> Well to begin with you can simply apply the same logic as the one you
> propose in your draft, but rather than doing it after sending
> candidates, you apply it before. That is, you start by sending your
> "better" candidates (the ones you wouldn't "deallocate" otherwise) and
> you only send your less desirable ones if you fail to obtain the prime
> candidates.


​Are you proposing to delay signaling the worse candidates?  I never like
the idea of delaying candidates because you don't know that the "better"
ones will succeed or not.  For example, if only TCP candidates work, how
long do you wait before you give up on UDP candidates?   Or if only cell
works, how long do you wait to give up on WiFi candidates?​



> This means that you would only end up with 256 if all of
> your prime candidates failed during gathering but then suddenly
> started working. Not a great likelihood for that to happen. On average
> you'll probably have one or two that leak out (and when that happens
> it might actually be an indication that your connection is better
> there).
>



>
> So, to be clear, I do agree that ending up with 256 candidates would
> be a problem, especially given the 100 pairs MAX constraint 5245.
>
> What bothers me with this draft is not the problem though: it's that
> the solution doesn't appear well thought out. For example: depending
> on your timing it is not at all clear that you will be able to remove
> candidates before you hit 100 pairs, before they start stun
> transactions or before you've already wasted the time you want to
> save.
>

​Actually, we did quite a lot of thinking through it.

We determined that if both sides remove worse TURN candidates and also
don't signal worse candidates, and also signal removal of worse candidates
before the addition of better candidates, then in the worst case scenario,
there are 2*N candidate pairs instead of N^2 candidates pairs.  Which means
in this example you would have 32 instead of 256.  And that's the absolute
worst case when all of your candidates are allocated in the worst possible
order, on both sides.  In more normal circumstances, it would reduce to far
fewer.
​


> In other words, this whole thing may well turn out to be useless half
> the time.
> ​ T
> hat's the sort of extra complexity we don't need with ICE.

> 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.
>
> Again, I am not at all convinced of its purported simplicity and even
> less its efficiency.
>
>
The whole draft is approximately one sentence if you subtract the boiler
plate.  It's very easy to implement (it took us perhaps one day).  And it's
just an optimization, so it's not going to break anything.  I don't know
how much more simple it can get.

​In a world where TURN mobility is widely deployed and no one wants to do
continual gathering and WiFi never turns off in the beginning of call
setup, then perhaps this is useless.​    But we have use cases in which we
have already found this useful.



> Emil
>
> >>
> >> 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
> >
> >
>
>
>
> --
> https://jitsi.org
>