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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of Emil Ivov
> Sent: Saturday, November 08, 2014 6:49 AM
> To: Dan Wing (dwing)
> Cc: Jonathan Lennox; Ari Keränen; mmusic
> Subject: Re: [MMUSIC] Continuous Nomination (Was: Faster ICE by role
> reversal?)
> 
> 
> 
> 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?

TURN Mobility can be used to solved the problem and allows client to switch-over to TURN-TCP. Only TURN works in case of  Simultaneous Mobility (If both the endpoints are mobile and roam at the same time between networks.)

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

TURN servers could be provided by access network, application service provider or a third party provider (https://tools.ietf.org/html/draft-patil-tram-turn-serv-selection-00) and should be reachable across different networks.

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

Yes, it's discussed in http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06#section-3.2.

-Tiru

> 
> 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_FzJ
> Q
> >>> e-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
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic