[MMUSIC] Continuous Nomination (Was: Faster ICE by role reversal?)

[Emil Ivov <[e-mail]>]

Hey all,

In the context of the ongoing discussion on two potential ICE 
improvements, I wanted to spin off this thread on the idea of continuous 
nomination.

So first of all, as I already mentioned in Toronto, I am very much in 
favour of a mechanism that would allow ICE processing to yield more than 
a single nominated pair. Back then the discussion was about MPRTP but 
there would likely be other use cases as well.

In that context, it seems perfectly valid to me that nomination among 
all validated pairs can occur multiple times within a session. Again, I 
find this to be a very valid and useful feature.

I am however bothered by the "ICE never ends" suggestions made by the 
document below and more specifically by the fact that candidates may 
continue to be trickled forever. I think that's both unnecessary and a 
problem.

It is a problem because

a) being able to know when the remote agent is done trickling is one of 
the very reasons we started the work on trickle ICE. This allows to 
quickly and deterministically detect and declare failure when it occurs. 
Not having this would require implementations to use magic timers of the 
sort: "Surely if I couldn't connect in .. say 20 seconds ... then the 
situation must be hopeless ... I think".

b) being able to continuously trickle new candidates forever and ever 
means that they would have to be paired with all of the peer's *initial* 
candidates. This means that ICE agents would have to maintain all 
gathered candidates even when they are not working for them.

More importantly however, the whole concept is likely unnecessary 
because an ICE restart only sounds scary, and it doesn't actually need 
to be ;).

A restart is non-disruptive as media can keep flowing while we are doing 
ICE processing.

5245 already supports pair reuse and we can easily port that concept to 
multipath ICE.

The one thing that we might be missing today is the syntax to allow for 
a restart without using offer/answer. This would be trivial to resolve: 
we just need to allow trickling a restart command. Sending your ufrag 
and pwd in a trickle update should do the job.

To put that into perspective, let's look at the following use cases:

I. You have used the new multipath ICE and you have successfully 
discovered a couple of working routes: one going through your wi-fi 
interface and another one going through 4G. During your session, you 
move closer to your Wi-Fi access point so you detect that RTT and packet 
loss start looking better on your Wi-Fi interface.

You decide to switch from 4G to Wi-Fi.

*No ICE restart* would be necessary here because no new paths would need 
to negotiated. This would be a native feature of the new multipath ICE.

II. You start on Wi-Fi in the presence of a 4G interface that you keep 
for backup. Multipath ICE comes up with pairs over both your interfaces. 
I don't believe this requires an ICE restart either. You just switch 
between pre-existing path and one of them expires as pointed out in 
Justin's document below

III. You setup a session at a point of time where 4G is your only 
working interface. Your Wi-Fi interface then comes up and you want to 
include it in the game. Here's what you do:

a) You gather host, srflx and relay candidates for the new interface.
b) You gather candidates on the old interface that haven't been valid 
before but that are worth trying again (this is non-essential)

d) you then trickle a new ufrag and pwd to trigger a restart.
b) you batch trickle all currently working candidates that you'd wish to 
preserve (you can omit any candidates you no longer wish to use, for 
whatever reason).
c) you trickle the newly gathered candidates.

The remote party, your peer, would then do the following

a) Gather all candidates that didn't work before but that deserve a 
second chance. This time *this is essential*. SRFLX candiates on your 
peer might not have worked with your 4G connection but they have every 
chance of working this time. There are a number of other scenarios where 
candidates would be worth retrying.

b) Your peer would then trickle back to you all the working candidates 
it wishes to preserve (as long as they are still valid)
c) It trickles all candidates it gathered for the occasion, that it 
wishes to retry.

Connectivity checks then proceed as usual. It might be worth paying 
special attention to the in-use candidates. Implementations might want 
to either confirm that data is still flowing there, or start the checks 
with them. This would determine how urgently ICE processing needs to 
yield results and it may imply changes in nomination strategies.

Thoughts?

Emil


On 7.11.14, 0:44, Justin Uberti wrote:
> Agreed.
>
> I wrote up a slightly more fleshed-out proposal at
> https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8bk-Xw/edit
>
> On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 6 November 2014 13:47, Justin Uberti <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     > I looked into how MICE works; I think that continuous nomination might be
>     > able to effectively support that use case, as well as the case that Brandon
>     > was interested in, namely picking the route that uses the best set of TURN
>     > servers.
>
>
>     I've always believe that continuous ICE operation was the only way to
>     ensure proper reliability.  Multipath or otherwise.  You just need to
>     work out when it is safe to completely stop on any given pair,
>     assuming that you don't want to be testing the complete mesh all the
>     time.  But you also might want multiple paths available, or maybe
>     backup paths.
>
>

-- 
https://jitsi.org