Re: [MMUSIC] Faster ICE by role reversal?

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

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

> On Thu, Nov 6, 2014 at 12:45 PM, Justin Uberti <[e-mail]> wrote:
> 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. 
> 
> 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 <[e-mail]> wrote:
> 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.
> 
>