Re: [MMUSIC] Faster ICE by role reversal?

[Justin Uberti <[e-mail]>]

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 <[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.
>
>
> Cheers,
> Ari
>
> On 31/07/14 02:42, Justin Uberti wrote:
>
>> On Wed, Jul 30, 2014 at 4:05 PM, Jonathan Lennox <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>
>>     On Jul 30, 2014, at 7:00 PM, Martin Thomson
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>      > On 30 July 2014 15:56, Jonathan Lennox <[e-mail]
>>     <mailto:[e-mail]>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>