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

[Emil Ivov <[e-mail]>]

Hey Peter,

On Sat, Jul 16, 2016 at 5:58 PM, Peter Thatcher <[e-mail]> wrote:
>
>
> 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.

Sure.

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

This would be a bad way to handle if down events as it would only work
in a very limited window of time (at least the way it's currently
defined).

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

This makes no sense to me. If you are going to remove TURN candidates
as soon as you send them, then why the heck do you have 8 TURN servers
to begin with?

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

No.

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

You don't need to implement explicit delays. You only need to order
your gathering and trickling according to the priority you desire.
Pacing will take care of the actual delays.

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

I am sure you have but this is not obvious from reading the document.

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

I am having trouble parsing this sentence but "don't signal worse
candidates" sounds to me as the opposite of "signal removal".

My guess at this stage is that once you implement "non-signalling of
worse candidates" removal of worse candidates is going to have a very
marginal benefit.

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

Yup. And that's pretty much my main problem.

I am very much missing a description of all possible states where a
removal signal can arrive and how the agent should behave under those
circumstances.

I am also missing guidelines for when exactly removal signals should be sent.

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

If twelve months from now you decide this wasn't worth doing, you'll
simply go and take it out of your code. If by that time the document
is out of editor's queue it will stay there.

Emil

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



-- 
https://jitsi.org