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

[Emil Ivov <[e-mail]>]

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.

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

In other words, this whole thing may well turn out to be useless half
the time. That'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.

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