Subject: Re: [MMUSIC] Faster ICE by role reversal?

From: Ari Keränen <[email-masked]>
Date: Tue, 4 Nov 2014 19:50:33 +0200

All,

This feature seemed to get quite a bit of support.

There were also some concerns about:

* DTLS implementations *may* not like the fact that Hello comes from an 
unexpected candidate (may also apply to other protocols?)

* Whether (and when) the selected candidate is really firm and the 
others can be freed, media on them discarded, or an ICE library can 
return a socket that is bound to right candidate

See also the threads:
http://www.ietf.org/mail-archive/web/mmusic/current/msg13596.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg13656.html

I'm planning to take this as a discussion item during the meeting, but 
before that it would be great if the proponents of the change could come 
up with a text proposal. I assume we'd need an ICE option to indicate 
this and clarify what to do with data on a candidate without 
USE-CANDIDATE exchange.

Also, if I missed some point why this would be a bad idea, please speak now.

Cheers,
Ari

On 31/07/14 02:42, Justin Uberti wrote:
> On Wed, Jul 30, 2014 at 4:05 PM, Jonathan Lennox <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     On Jul 30, 2014, at 7:00 PM, Martin Thomson
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>      > On 30 July 2014 15:56, Jonathan Lennox <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >> The offerer can’t send its own connectivity checks until it
>     receives an answer, because it needs the remote ufrag and password.
>       Without this, it doesn’t have any valid pairs, and so can’t send
>     any media.
>      >
>      > Of course.  But you could do all the computation necessary for
>      > generating the ServerHello and accompanying messages (which in
>     TLS 1.3
>      > is quite a bit).
>      >
>      >> This suggestion might still save half an RTT, though? I’d need
>     to work through a full ladder diagram to figure it out.
>      >
>      > That's the idea.  I haven't plotted it all out either, but I think
>      > that this is the fastest possible start assuming that you don't send
>      > any DTLS messages prior to getting a successful connectivity check
>      > response.
>
>     Actually, if the answerer (controlled endpoint) can send on any
>     Valid pair, as in my suggestion, I don’t think you need the ICE role
>     reversal for this optimization.  It can send ClientHello as soon as
>     its first check succeeds, despite never having received any remote
>     checks (with or without USE-CANDIDATE).
>
> This makes a lot of sense and we should do it. Implementations not
> expecting media before choosing a selected pair (on the controlling side
> this time) may eat the packet, but it won't be fatal.
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Nov 2014 12:45:42 -0800

I have been noodling on two proposals here:

a) merging regular and aggressive nom
-- essentially, Jonathan's suggestion from before:
-- controlling side sends on any Valid pair, even prior to a pair being
selected
-- controlled side can send on any Valid pair (although it could use
receipt of media to align with controlling side)
-- controller confirms selection with use-candidate (same as today), which
ends concludes ICE
-- no ice-options needed (AFAICT)

b) adding a new mode, "continuous" nomination
-- ICE never concludes; controlling side is always able to change media
path dynamically
-- as a corollary, controlling side controls when remote candidates can be
freed
-- new candidates can be trickled at any time
-- controlled side uses either receipt of (secure) media to align with
controlling side, or receipt of new use-candidate checks
-- this mode requires opt-in via ice-options:continuous

I still need to look at how b) might overlap with MICE, but I'd be happy to
write either of these up or present them in Honolulu.

On Tue, Nov 4, 2014 at 9:50 AM, Ari Keränen <[email-masked]>
wrote:

> * Whether (and when) the selected candidate is really firm and the others
> can be freed, media on them discarded, or an ICE library can return a
> socket that is bound to right candidate
>
> See also the threads:
> before that it would be great if the proponents of the change could come up
> with a text proposal. I assume we'd need an ICE option to indicate this and
> clarify what to do with data on a candidate without USE-CANDIDATE exchange.
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Nov 2014 13:47:57 -0800

On Thu, Nov 6, 2014 at 12:45 PM, Justin Uberti <[email-masked]> wrote:

> I still need to look at how b) might overlap with MICE, but I'd be happy
> to write either of these up or present them in Honolulu.
>

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.

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 6 Nov 2014 14:08:44 -0800

On Nov 6, 2014, at 1:47 PM, Justin Uberti <[email-masked]> wrote:

> -- controlling side sends on any Valid pair, even prior to a pair being selected
> -- controlled side can send on any Valid pair (although it could use receipt of media to align with controlling side)
> -- controller confirms selection with use-candidate (same as today), which ends concludes ICE
> -- ICE never concludes; controlling side is always able to change media path dynamically
> -- as a corollary, controlling side controls when remote candidates can be freed
> -- controlled side uses either receipt of (secure) media to align with controlling side, or receipt of new use-candidate checks
> I still need to look at how b) might overlap with MICE, but I'd be happy to write either of these up or present them in Honolulu. 
> 
> I looked into how MICE works; I think that continuous nomination might be able to effectively support that use case,

Agreed, it should work nicely with MICE.  The critical aspect of MICE is the same as the continuous nomination, namely, that ICE keeps running on both endpoints.

> as well as the case that Brandon was interested in, namely picking the route that uses the best set of TURN servers.

-d

> 
> On Tue, Nov 4, 2014 at 9:50 AM, Ari Keränen <[email-masked]> wrote:
> All,
> 
> * DTLS implementations *may* not like the fact that Hello comes from an unexpected candidate (may also apply to other protocols?)
> 
> * Whether (and when) the selected candidate is really firm and the others can be freed, media on them discarded, or an ICE library can return a socket that is bound to right candidate
> 
> See also the threads:
> I'm planning to take this as a discussion item during the meeting, but before that it would be great if the proponents of the change could come up with a text proposal. I assume we'd need an ICE option to indicate this and clarify what to do with data on a candidate without USE-CANDIDATE exchange.
>

---

From: Varun Singh <[email-masked]>
Date: Thu, 6 Nov 2014 14:16:21 -0800

selected
path dynamically
>>> I still need to look at how b) might overlap with MICE, but I'd be
happy to write either of these up or present them in Honolulu.
>>
>>
>> I looked into how MICE works; I think that continuous nomination might
be able to effectively support that use case,
>
>
> Agreed, it should work nicely with MICE.  The critical aspect of MICE is
the same as the continuous nomination, namely, that ICE keeps running on
both endpoints.
>
>> as well as the case that Brandon was interested in, namely picking the
route that uses the best set of TURN servers.

This behavior is also required by Multipath RTP, where an endpoint may
change candidates and/or use several of these candidates simultaneously.

wrote:
>>>> * DTLS implementations *may* not like the fact that Hello comes from
an unexpected candidate (may also apply to other protocols?)
>>>> * Whether (and when) the selected candidate is really firm and the
others can be freed, media on them discarded, or an ICE library can return
a socket that is bound to right candidate

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Nov 2014 15:29:23 -0800

> was interested in, namely picking the route that uses the best set of TURN

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.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Nov 2014 15:44:05 -0800

Agreed.

I wrote up a slightly more fleshed-out proposal at
https://docs.google.com/document/d/1P1XPCRJKBkSjwCzIIEUJmp7V694_FzJQe-fvN8bk-Xw/edit

---

From: Emil Ivov <[email-masked]>
Date: Fri, 7 Nov 2014 01:31:15 +0100

> time.  But you also might want multiple paths available, or maybe

There are two aspects here:

1. Obtaining multiple valid paths as a result of ICE processing (and
leaving it up to apps to use one or more) and
2. Handling events where new candidates become available and need to
be communicated to the remote party.

"1" can definitely be very useful so that would be a great feature to
add to ICE.

I agree that, especially with mobiles, "2" is also important. That
said, what is the problem of doing this with Trickle ICE today?

Starting a new Trickle ICE negotiation is a very light-weight process.
It is basically a matter of sending a new ufrag/pwd pair.  It is also
a non-disruptive process as media continues during ICE processing and
failure results in falling back to whatever one had before.

Also note that, if new candidates appear as a result of mobility
event, it might be worth rechecking your previous pairs anyway because
some of them may have become invalid or, on the contrary, more
relevant.

On the other hand, having a clear "start" and "end" in ICE processing
also has value as it allows one to declare failure in a deterministic
way, as opposed to just waiting out magic timers.

I other words, I think we already have everything that is necessary
for continuous ICE operation, don't we?

Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Nov 2014 16:37:05 -0800

> said, what is the problem of doing this with Trickle ICE today?

ICE ends.  A candidate that arrives after that point is not going to
change anything.

> for continuous ICE operation, don't we?

Almost.  I think that Justin has identified the gap reasonably well in
his doc.  (Justin, please turn this into a draft :)

Honestly, I think that this is the sort of thing that ICE-bis should
be tackling, more than just a little fixup.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 7 Nov 2014 01:41:42 +0100

On Fri, Nov 7, 2014 at 1:37 AM, Martin Thomson <[email-masked]> wrote:
> ICE ends.

Right, and that's a feature. It means that if you don't have a working
pair by the time it ends you can rapidly declare failure.

> A candidate that arrives after that point is not going to
> change anything.

This is wrong.

Just attach a new ufrag/pwd to your new cand and it can change everything.

> his doc.  (Justin, please turn this into a draft :)

Could you please point me to the text that you thing does this? I must
be missing it because I don't see it.

Emil

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Nov 2014 17:39:18 -0800

> his doc.  (Justin, please turn this into a draft :)

I'll see if I can get this done before I fly out.

---

From: Ari Keränen <[email-masked]>
Date: Fri, 7 Nov 2014 16:24:14 +0200

> -- no ice-options needed (AFAICT)

This seems to me something that could potentially go to ICE bis.

Do we need here considerations on which one would send Client Hello?

Also would be good to hear from folks would this kind of functionality 
break (with) something? Middle boxes doing rate control? ICE library 
waiting for ICE to finish before giving out socket to app? OTOH, 
probably we cant rely on this working 100% anyway, and then we could 
always fall back to regular nomination.

> to write either of these up or present them in Honolulu.

This is slightly more complicated and I'm looking forward to more 
details and discussion. I saw there was some good text on the Gdoc 
document, so once that's somewhat stable, posting that to the list or ID 
tracker would be good for a stable reference.

Cheers,
Ari

---

From: Emil Ivov <[email-masked]>
Date: Fri, 07 Nov 2014 23:41:08 +0100

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:
> On Thu, Nov 6, 2014 at 3:29 PM, Martin Thomson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 6 November 2014 13:47, Justin Uberti <[email-masked]
>     <mailto:[email-masked]>> wrote:

-- 
https://jitsi.org

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 7 Nov 2014 16:35:29 -0800

On Nov 7, 2014, at 2:41 PM, Emil Ivov <[email-masked]> 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. 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.
> 
> *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:
> 
> b) You gather candidates on the old interface that haven't been valid before but that are worth trying again (this is non-essential)
> 

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

---

From: Emil Ivov <[email-masked]>
Date: Sat, 08 Nov 2014 02:18:34 +0100

On 8.11.14, 1:35, 🔓Dan Wing wrote:
>> 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.
>>
>> because an ICE restart only sounds scary, and it doesn't actually
>> need to be ;).
>>
>> 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.
>

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.

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

---

From: Justin Uberti <[email-masked]>
Date: Fri, 7 Nov 2014 18:03:23 -0800

It's getting hard to follow the idea here, so I suggest you write it up in
a document and then we can try to find some time in Hono to sit down and
discuss the pros/cons of continuous nomination and your approach.

On Fri, Nov 7, 2014 at 5:18 PM, Emil Ivov <[email-masked]> wrote:

> 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.
>
> requires you to make the assumption that one of your media paths is certain
> to survive any sort of mobility event.
>
> know that your new location wouldn't be one where TURN-TCP is the only way
> to get out of the local network?
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Nov 2014 21:15:38 -0800

> Just attach a new ufrag/pwd to your new cand and it can change everything.

There's a marked difference between ICE restart and trickling.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 7 Nov 2014 22:08:07 -0800

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, which is a serious issue.

Therefore I think continuous nomination is the simplest solution to this
problem.

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 7 Nov 2014 17:29:28 -0800

On Nov 7, 2014, at 5:18 PM, Emil Ivov <[email-masked]> wrote:

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

I am slightly uncomfortable using signaling path for same reason, and signaling path takes longer to start up (TCP, TLS).  Even if we make the signaling path start up faster with all the spiffy new TLS 0-RTT or QUIC or whatever, the signaling path should remain slower because a server is involved and the path isn't as straight as the peer-to-peer path.  That's why MICE does not require to first send a=candidate over the signaling path.

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

You're right, we don't know, of course.

But same risk exists of the signaling path on a mobility event.

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

From my perspective, thinking about MICE, I want to make the mobility event (voice/video) successful.  If signaling takes a little while to get re-established, *shrug*, I don't care.  

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

It would help.  But multipath ICE requires I have that connection to TURN set up prior to the mobility event, right?  If I'm right, that is not desirable.

-d

---

From: Emil Ivov <[email-masked]>
Date: Sun, 09 Nov 2014 02:43:06 +0100

On 8.11.14, 3:03, Justin Uberti wrote:
> It's getting hard to follow the idea here, so I suggest you write it up
> in a document and then we can try to find some time in Hono to sit down
> and discuss the pros/cons of continuous nomination and your approach.

Indeed, this is a good idea. I have tried to describe all this here:

https://github.com/emcho/ice-updates/blob/master/draft-ivov-mmusic-ice-updates-00.txt

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Sun, 09 Nov 2014 02:43:47 +0100

> There's a marked difference between ICE restart and trickling.

Trickle ICE is one of the components that helps alleviate potential 
inconveniences in an ICE restart.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Sun, 09 Nov 2014 02:50:22 +0100

On 8.11.14, 7:08, Justin Uberti wrote:
> 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.
>

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
b) it is no longer clear when unused candidates (srflx and relay) can be 
released.

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

---

From: Justin Uberti <[email-masked]>
Date: Sat, 8 Nov 2014 21:53:07 -0800

> a) we lose the possibility to clearly detect failures and we need to

It's timers one way or another (e.g. how do you know when to give up on
retransmitting ICE checks?). I don't think this is a salient point.

> b) it is no longer clear when unused candidates (srflx and relay) can be

This is explicitly discussed in my proposal.

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

---

From: Emil Ivov <[email-masked]>
Date: Sun, 09 Nov 2014 15:12:55 +0100

On 9.11.14, 6:53, Justin Uberti wrote:
>
>
> On Sat, Nov 8, 2014 at 5:50 PM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     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.
>
> 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.
>

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

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Nov 2014 07:41:13 -1000

On Nov 8, 2014, at 3:50 PM, Emil Ivov <[email-masked]> wrote:
> a) we lose the possibility to clearly detect failures and we need to resort to magic timers
> b) it is no longer clear when unused candidates (srflx and relay) can be released.

[BA] Justin's proposal does provide a way to know when unused candidates can be released. The problem is that those released candidates might actually be needed after a new interface comes up.

For example, say two peers are initially on the same WiFi LAN so that host candidate checks work.  As a result, there is no reason for either peer to keep unused relay candidates. Media is flowing, then one peer senses WiFi signal strength decreasing so it brings up an LTE interface. While it can trickle the new host, srflx and relay candidates, the other peer no longer has functioning relay candidates so the checks could fail.  While the peer could have kept its LTE interface hot all along and used it to ensure that the other peer kept its relay candidates that would have a high cost in terms of energy usage.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Nov 2014 11:29:33 -0800

> For example, say two peers are initially on the same WiFi LAN so that host candidate checks work.  As a result, there is no reason for either peer to keep unused relay candidates. Media is flowing,…

I think that this is the key problem.  And we need to start to
concentrate on the properties that we are looking for, rather than
looking dogmatically at one solution or other.  We need clear rules
(or an acknowledgment that there is a policy decision) around when a
given candidate can be released.  We probably also need rules or
mechanisms to support a reduction in testing of candidate pairs.

Emil's suggestion that you have some sort of explicit marker to
declare candidates dead or unusable is definitely worthwhile.  I
wonder if that's not better suited to something on the media path
though.

---

From: Emil Ivov <[email-masked]>
Date: Sun, 09 Nov 2014 22:22:55 +0100

> wonder if that's not better suited to something on the media path

So how about the following:

1. Ability for ICE to yield multiple paths
2. The ability to use these paths simultaneously or exclusively
3. Switching between available paths with no non-ICE signalling
4. (?) If paths are used exclusively, the ability for either path to do 
a switch (we may want to limit this to switches that only change the 
local candidate and not the remote one.
5. As interfaces come up: ability to add new candidates without 
disrupting ongoing communication
6. As interfaces go down: ability to update without disrupting the 
communication (well ... to whatever extent that is possible).

I think those are the main set. And then there's also one that is more 
MICE-specific:

7. In the case of a mobility event: the ability to attempt to quickly 
recover at least partial connectivity (as opposed to restoring all paths).

I think the value that MICE brings here, and that is not addressed by 
points 1-6 is that it optimizes cases where a NATed mobile node is 
talking to a public media server (e.g., a tablet in a 
WebEx/Hangouts/Jitsi Meet conference). In those cases, MICE allows the 
mobile conference participant to move to a new location and just 
continue streaming to the media server. The server would latch onto the 
new address of the mobile and the disruption time would be very low.

The reason I kept it as a separate item is because it has different 
constraints than regular ICE updates. It is an optimization for some 
cases. It tries to recover any form of connectivity as quickly as 
possible in order to reduce handover latency. Period.

There are many cases where this specific MICE optimization wouldn't work 
(e.g., when both peers are behind common types of NATs) but this is not 
a problem since MICE would then do a proper update through signalling 
anyway (e.g., an ICE restart) in order to re-establish other paths of 
communication or cover the cases that didn't connect with the optimization.

Dan, Pal, Tiru, is the above summary correct?

If so, I think we have the option of addressing this case separately. 
The following is vague but, for example, we could allow for 
peer-reflexive candidates to be discovered at any point, with the 
possibility to replace a pre-existing path.I am not even sure we need 
the extra ICE attributes defined by MICE in that case ... but I am 
likely missing something.

Anyways, the importance here is that agents would not attempt to pair 
these late peer reflexive candidates anything else than the address that 
they were received on. They would just latch onto them and do nothing 
else until a restart is triggered.

Thoughts?

Emil

-- 
https://jitsi.org

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 10 Nov 2014 00:50:09 +0000

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of Bernard
> Aboba
> Sent: Sunday, November 09, 2014 7:41 AM
> To: Emil Ivov
> Cc: Jonathan Lennox; Ari Keränen; mmusic; Dan Wing (dwing)
> Subject: Re: [MMUSIC] Faster ICE by role reversal?
> 
> [BA] Justin's proposal does provide a way to know when unused candidates
> can be released. The problem is that those released candidates might
> actually be needed after a new interface comes up.
> 
> For example, say two peers are initially on the same WiFi LAN so that host
> candidate checks work.  As a result, there is no reason for either peer to keep
> unused relay candidates. Media is flowing, then one peer senses WiFi signal
> strength decreasing so it brings up an LTE interface. While it can trickle the
> new host, srflx and relay candidates, the other peer no longer has
> functioning relay candidates so the checks could fail.  While the peer could
> have kept its LTE interface hot all along and used it to ensure that the other
> peer kept its relay candidates that would have a high cost in terms of energy
> usage.

Alternatively unused relayed candidate could be maintained on the Wifi interface and after switch-over to LTE use TURN Mobility (https://tools.ietf.org/html/draft-wing-tram-turn-mobility-02) to retain the allocations. The overhead is that unused candidate pair with relayed candidate has to be maintained with connectivity checks for fail-over.

-Tiru

---

From: Varun Singh <[email-masked]>
Date: Sun, 9 Nov 2014 15:18:56 -1000

Catching up on the mailing list. One comment inline, reflecting on our
experiments with MPRTP.

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

Back in 2010, before we had trickle ICE, in Multipath RTP, we
implemented advertising the interfaces in RTCP, we wanted to do it
in-band with the media, because we wanted to avoid the SDP
offer/answer. It was more like a notification to the other party that
a new interface is available and that the endpoint wants to make use
of it. On receiving the RTCP message with the interface advertisement,
the endpoints would perform connectivity checks on the interfaces and
reported successful candidates to the RTP layer, and the scheduling
algorithm would figure out over time, which candidates should be
active/passive depending on the performance metrics (e.g., loss,
delay, throughput, etc.). OTOH, the application needs to know if any
paths work or else it would be stuck waiting for the transports to be
setup.

We tried not implementing ICE, but ended up doing something similar
anyway. Some of the early experiments are described in Section 7.1 of
MPRTP paper. [1]

[1] http://www.netlab.tkk.fi/~jo/papers/2013-mmsys-mprtp.pdf.

> From my perspective, thinking about MICE, I want to make the mobility event (voice/video) successful.  If signaling takes a little while to get re-established, *shrug*, I don't care.

+1

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Varun Singh <[email-masked]>
Date: Sun, 9 Nov 2014 15:28:51 -1000

On Sun, Nov 9, 2014 at 11:22 AM, Emil Ivov <[email-masked]> wrote:
>>> For example, say two peers are initially on the same WiFi LAN so that
>>> host candidate checks work.  As a result, there is no reason for either peer
>>> to keep unused relay candidates. Media is flowing, then one peer senses WiFi
>>> signal strength decreasing so it brings up an LTE interface. While it can
>>> trickle the new host, srflx and relay candidates, the other peer no longer
>>> has functioning relay candidates so the checks could fail.  While the peer
>>> could have kept its LTE interface hot all along and used it to ensure that
>>> the other peer kept its relay candidates that would have a high cost in
>>> terms of energy usage.
>>
>>
>>

do you mean: switching between paths with ICE signalling?

In the case of MPRTP, the scheduling algorithm/congestion controller
can make the decision on which paths to use.
However, if it is single RTP, then switching from one to another makes sense.

> 4. (?) If paths are used exclusively, the ability for either path to do a
> switch (we may want to limit this to switches that only change the local
> candidate and not the remote one.
> 5. As interfaces come up: ability to add new candidates without disrupting
> ongoing communication

+1 for the rest.

> I think the value that MICE brings here, and that is not addressed by points
> 1-6 is that it optimizes cases where a NATed mobile node is talking to a
> public media server (e.g., a tablet in a WebEx/Hangouts/Jitsi Meet
> conference). In those cases, MICE allows the mobile conference participant
> to move to a new location and just continue streaming to the media server.
> The server would latch onto the new address of the mobile and the disruption
> time would be very low.
>
> constraints than regular ICE updates. It is an optimization for some cases.
> It tries to recover any form of connectivity as quickly as possible in order
> to reduce handover latency. Period.
>
> (e.g., when both peers are behind common types of NATs) but this is not a
> problem since MICE would then do a proper update through signalling anyway
> (e.g., an ICE restart) in order to re-establish other paths of communication
> or cover the cases that didn't connect with the optimization.
>
> If so, I think we have the option of addressing this case separately. The
> following is vague but, for example, we could allow for peer-reflexive
> candidates to be discovered at any point, with the possibility to replace a
> pre-existing path.I am not even sure we need the extra ICE attributes
> defined by MICE in that case ... but I am likely missing something.
>
> Anyways, the importance here is that agents would not attempt to pair these
> late peer reflexive candidates anything else than the address that they were
> received on. They would just latch onto them and do nothing else until a
> restart is triggered.
>
> Thoughts?
>
> Emil
>
> --
> https://jitsi.org
>
>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Nov 2014 03:35:11 +0100

> recover at least partial connectivity (as opposed to restoring all paths).

I'd like to add one more here:

8. Preserve the possibility to detect an end of the candidate trickling. 
That is: end of the candidates that are currently available to a peer.

This options allows us to:

a) quickly recognize failure when it occurs and
b) release candidates that are not used as a result of ICE processing.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Nov 2014 03:37:46 +0100

> do you mean: switching between paths with ICE signalling?

Yes. With only media-path signalling.

> However, if it is single RTP, then switching from one to another makes sense.

Well ... I am expecting that if and when we do come up with Multipath 
ICE we would have the option for endpoints/applications to decide 
whether those paths are meant to be used together or separately. So 
MPRTP could simply go for the aggregate option.

Emil

-- 
https://jitsi.org

---

From: Varun Singh <[email-masked]>
Date: Sun, 9 Nov 2014 17:03:28 -1000

On 9 Nov 2014 16:37, "Emil Ivov" <[email-masked]> wrote:
> Well ... I am expecting that if and when we do come up with Multipath ICE
we would have the option for endpoints/applications to decide whether those
paths are meant to be used together or separately. So MPRTP could simply go
for the aggregate option.

Yes, For MPRTP knowing which paths have connectivity is sufficient for
operation.

I just want to make sure that ICE doesn't switch interfaces unless it is
for failover (the current candidate disappears) because it will pollute the
path metrics used by the congestion control.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Nov 2014 19:17:03 -0800

> b) release candidates that are not used as a result of ICE processing.

I think that these two are the actual requirements:

8. Detect a dead-end: where there is no further chance of success
because there are no more candidates forthcoming and all combinations
have been tested

9. Have a means to remove candidates from the set that a peer has
offered (I'm not sure if a peer might want to remove candidates its
peer has offered, but a peer should definitely be able to retract its
own candidates)

---

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Nov 2014 19:45:06 +0100

FYI: this draft is now submitted:

http://tools.ietf.org/html/draft-ivov-mmusic-ice-updates-00

Emil

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Nov 2014 13:25:31 -0800

I've written up a draft as well, detailing the goals discussed earlier in
this thread, as well as our proposed solution.

http://juberti.github.io/draughts/nombis/draft-uberti-mmusic-nombis.txt

Anyone up for discussing in the 1PM slot this afternoon?

---

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Nov 2014 23:25:46 +0100

Could we maybe have the discussion in a way that would allow those of
us not present in Hawaii to also attend?

Emil

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Nov 2014 15:16:26 -0800

Let's meet in the lounge upstairs. I'm at the back table.

Emil, we might have to have a sidebar here in person and then have a call
later to discuss next steps.