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

On 31 Jul 2014 9:18 PM, "Justin Uberti" <juberti@google.com> wrote:
>
>
>
>
> On Wed, Jul 30, 2014 at 4:23 PM, Justin Uberti <juberti@google.com> wrote:
>>
>>
>>
>>
>> On Wed, Jul 30, 2014 at 3:20 PM, Jonathan Lennox <jonathan@vidyo.com>
wrote:
>>>
>>>
>>> On Jul 30, 2014, at 5:59 PM, Justin Uberti <juberti@google.com> wrote:
>>>
>>>> On Wed, Jul 30, 2014 at 2:14 PM, Jonathan Lennox <jonathan@vidyo.com>
wrote:
>>>>>
>>>>> 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.
>>>
>>>
>>> Oh, that’s true, it has to pick something.
>>>
>>> In the semantic I’m suggestion, I think it doesn’t matter what it picks
— it could choose any valid pair, just like the controlling agent does,
since it knows that’s a working round-trip path.
>>>
>>> For both sides, if you receive media on any candidate (from an IP and
port from which you’ve received a valid connectivity check), accept it.
 USE-CANDIDATE is then just an optimization that lets you close down the
unselected candidates.
>>>
>>> I don’t think you want a rule of “most recently received USE-CANDIDATE”
to determine the selected pair.  Checks will race each other, especially
when the paths’ RTTs are very different.
>>>
>>> In my model, there is only ever one USE-CANDIDATE sent per component —
i.e., it works like pure regular nomination, except for the “early media”.
>>
>>
>> OK, I get it now. I think the main issues you face are:
>> 1) Inability to selectively free candidates - all candidates except the
selected pair can be freed by the controlled side after USE-CANDIDATE.
>> 2) No guarantee of symmetric RTP - remote side can use a different pair
than local side - and you can't resolve this without USE-CANDIDATE (see #1).
>> 3) Potential issues when media arrives on non-nominated pair.
>>
>> Given #3, I think I'd prefer to find a solution that also addresses
#1/#2.
>
>
> Sounds like #3 is unlikely to be a problem given 5245 allows it.
>
> What do others think about #1/#2? These seem to be the main differences
between Jonathan's proposal and my proposal.

While #3 is indeed allowed by 5245 I don't think current regular nomination
implementations would actually handle things that way. (Except for those
that started with aggressive nomination as the default).

#1 and #2 can be important for ICE libs that just return a socket for the
app to use (the do need to know whem to return it)

 _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>