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

[🔓Dan Wing <[e-mail]>]

On Nov 7, 2014, at 2:41 PM, Emil Ivov <[e-mail]> wrote:

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

For MICE and some other use cases, I agree that need to signal (in SDP) is the 'scary' part of an ICE restart.

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

That is a nice approach -- move the 'ICE restart' signaling to an (existing, working) media path.


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

If that trickling happens over the SIP/WebRTC/XMPP signaling channel, MICE would prefer not requiring that SDP signaling step or to at least allow it to be done later.

-d


> 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