Re: [MMUSIC] Faster ICE by role reversal?

[Ari Keränen <[e-mail]>]

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
>