Re: [MMUSIC] Faster ICE by role reversal?

[Emil Ivov <[e-mail]>]

On 9.11.14, 6:53, Justin Uberti wrote:
>
>
> On Sat, Nov 8, 2014 at 5:50 PM, Emil Ivov <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>     On 8.11.14, 7:08, Justin Uberti wrote:
>
>         Yeah, I'm of the same opinion. If you are going to allow
>         tricking of new
>         candidates, you only have two choices:
>         a) ICE never ends, or
>         b) ICE restart
>
>         But ICE restart invalidates existing candidates,
>
>
>     Existing candidates can very well be part of the new ICE negotiation
>     and if they are confirmed as "still working", no invalidation needs
>     to occur.
>
>     5245 even already mentions this:
>         Consequently, the set of candidates MAY include some,
>         none, or all of the previous candidates for that stream and MAY
>         include a totally new set of candidates gathered as described in
>         Section 4.1.1.
>
>
>
>         which is a serious issue.
>
>         Therefore I think continuous nomination is the simplest solution
>         to this
>         problem.
>
>
>     Continuous nomination has at least two serious problems:
>
>     a) we lose the possibility to clearly detect failures and we need to
>     resort to magic timers
>
>
> It's timers one way or another (e.g. how do you know when to give up on
> retransmitting ICE checks?).

If you don't define a clear end of trickling, then continuous nomination 
would require an extra layer of timers, that would actually need to be 
very dependent on usage scenarios. This is unnecessary.

So, yes, while there will always be timers somewhere in the stack this 
is in no way an excuse to keep piling them up.

> I don't think this is a salient point.
>
>     b) it is no longer clear when unused candidates (srflx and relay)
>     can be released.
>
> This is explicitly discussed in my proposal.

I don't think it is. Your proposal talks about pruning pairs you no 
longer wish to use. That's a strategy decision that mostly belongs to 
the implementation and in that way having the option is certainly useful.

However, your proposal says nothing about the connectivity decision: 
when can I release the ports on the interfaces that I am not using? When 
can I stop refreshing server-reflexive candidates? When do I drop relay 
candidates that haven't been used?

I assume the answer would be: when timer X fires ...

... and obviously you should reallocate all of these again later, when 
your peer enters a Wi-Fi network and starts trickling the new 
candidates. You would need to go over all the interfaces and relays that 
you released and claim them again.

So the irony is, that at the end of the day, even with continuous 
nomination you would still need two modes of operation: one where you 
are actively looking for possible routes/paths and another where you are 
operating and using a set of pairs/paths that have been validated.

In other words you would have ICE restarts in all but name.

Emil

>     We could obivously work on resolving the above issues by preserving
>     the end-of-candidates indication and then allowing new candidates to
>     still arrive after it. We could also work on clearing out a few
>     other points, like for example, how receiving a trickled candidate
>     means one needs to potentially re-gather and re-trickle and re-check
>     local candidates.
>
>     While this is certainly a possibility ... it is likely to simply
>     take us to something very similar to ICE restarts. Potentially even
>     the exact same thing, only triggered with something other and a
>     ufrag/pwd update. :)
>
>     So, it might be more productive to just rename "ICE restarts" to
>     something that scares us less and see if and how we need to address
>     any actual issues there.
>
>     Emil
>
>
>     --
>     https://jitsi.org
>
>

-- 
https://jitsi.org