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

[Emil Ivov <[e-mail]>]

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

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