Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

[Justin Uberti <[e-mail]>]

On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox <[e-mail]> wrote:

>
>  On Jul 30, 2014, at 4:59 PM, Justin Uberti <[e-mail]> wrote:
>
>   On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox <[e-mail]>
> wrote:
>
>>
>> On Jul 29, 2014, at 1:57 PM, Justin Uberti <[e-mail]> wrote:
>> >
>> > The one thing we need to do is update ICE to allow the CONTROLLING side
>> to make dynamic decisions about which pair to use, instead of being forced
>> to use PRIORITY (which is what 5245 says). I am going to try to write this
>> up before Hawaii.
>>
>> This is equivalent to using regular nomination, but saying that an
>> endpoint can send media on any Confirmed candidate pair, not just the
>> Selected one, right?
>>
>
>  It's a bit more than that - the controlled endpoint has to also
> synchronize on the candidate pair, which means that it needs to know what
> its selected pair should be, using logic other than what is outlined in
> http://tools.ietf.org/html/rfc5245#section-11.1.1 (which says use the
> highest priority nominated pair).
>
>  So it becomes:
> - controlling side can pick any nominated candidate pair it wants to be
> its selected pair
> - controlled side should use presence of media from controlling side to
> decide selected pair (for secure media), or some TBD attribute (for
> non-secure media)
> - controlling side can tell controlled side when it is OK to discard
> candidate pairs that it has nominated (so that the controlling side can
> still safely do the switch to a new pair). This is probably done by having
> the controlled side keep all candidates alive that have received a check
> from the controlling side in the past XX seconds.
>
>
>  You’ve just reinvented regular nomination — your “TBD attribute” is
> regular nomination’s USE-CANDIDATE.
>

>  Thus the suggestion I’m making — do regular nomination, but allow media
> to be sent on any valid pair prior to selection.  (Yes, re-reading 5245, I
> should have said “Valid” rather than “Confirmed”.  I mis-remembered the
> terminology.)
>

Understood. But controlled side needs some way to know what pair it should
use to send media, so we need some way to indicate this. Would this be done
via USE-CANDIDATE? If so, we could end up with multiple USE-CANDIDATEs as
we figure out the ideal path to use, which doesn't fit exactly with regular
nomination as defined in 5245, but otherwise seems exactly like what I am
proposing. Basically, controlled side uses the pair that it most recently
received USE-CANDIDATE on as its selected pair.

>
>    5245 says that an ICE endpoint MUST be prepared to receive media on
>> any candidate, but only sends on the Selected candidate pair.  I don’t know
>> if this means, in practice, that ICE-bis could change to the behavior I’ve
>> described above and still be backward compatible, or if there’d need to be
>> some sort of ice-option negotiation to indicate that this early media (oh,
>> dread phrase) is acceptable.
>>
>
>  Yes, I think we need a new ICE option, or else old ICE impls in the
> controlled role will be surprised when they think the selected pair is A
> but media arrives on B. We've already seen a number of implementations have
> issues with this.
>
>
>  Do they have issues receiving media if there is no selected pair yet?
>  This would be nonconformant with 5245, but nevertheless wouldn’t surprise
> me.
>

Since the controlled side sends the ClientHello in the typical case, this
isn't usually a problem. The issue that is most often seen is that the
ServerHello comes from B instead of A and is ignored.