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

[Emil Ivov <[e-mail]>]

On 8.11.14, 1:35, 🔓Dan Wing wrote:
>
> 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.

I was actually thinking of the signalling path. So for SIP this would be 
a SIP INFO request with the ufrag/pwd as the sole content. A couple of 
a= lines would do it for WebRTC.

I am slightly uncomfortable about doing it on the media path because it 
requires you to make the assumption that one of your media paths is 
certain to survive any sort of mobility event.

Even if you keep your TURN connection open for that purpose, how do you 
know that your new location wouldn't be one where TURN-TCP is the only 
way to get out of the local network?

Or what if you don't even have a TURN server?

You signalling channel would be a safer bet, but more importantly, you'd 
likely want to tear down your call if it didn't.

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

Well, if you had multipath ICE, you would be able to switch your media 
over to TURN (this wouldn't require any signalling)  if that still works 
and then do the non-disruptive restart after that to discover other paths.

Would this work?

Emil

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

-- 
https://jitsi.org