Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis

[Justin Uberti <[e-mail]>]

The issue isn't just that you don't know when aggressive nomination has
ended - it's that the CONTROLLING side can't truly express its desires to
the CONTROLLED side, including use of some dynamic metric (e.g. RTT) to
choose the active candidate pair instead of PRIORITY.

With regular nomination, the CONTROLLING side has this option, but not with
aggressive nomination. This is the core issue that I want to fix, and I
would definitely want to fix this in the media plane using something like
REALLY-USE-CANDIDATE, since it may change fairly quickly as RTT values
stabilize.

There are other things that we can try to fix at the same time, e.g. the
CONTROLLED side can keep other candidate pairs warm and switch to them at
any time (via another REALLY-USE-CANDIDATE).


On Wed, Jul 23, 2014 at 12:30 PM, Ari Keränen <[e-mail]>
wrote:

> On 7/22/14 7:12 PM, Emil Ivov wrote:
>
>>
>> On 22 Jul 2014 6:11 PM, "Ari Keränen" <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>  >
>>  > On 7/22/14 11:06 AM, Emil Ivov wrote:
>>  >>
>>  >> On 22.07.14, 11:02, Ari Keränen wrote:
>>  >>>
>>  >>> Hi,
>>  >>>
>>  >>> On 7/21/14 4:45 PM, Emil Ivov wrote:
>>  >>>>
>>  >>>> In London we mentioned the option of adding a new attribute that,
>> during
>>  >>>> aggressive nomination, the controlling agent can use to notify its
>> peer
>>  >>>> that ICE processing is over and no more changes are going to be
>>  >>>> attempted. This way controlled agents will no they can now release
>>  >>>> resources.
>>  >>>>
>>  >>>> This could either be a new attribute (e.g.,
>> USE-CANDIDATE-CONFIRMED) or,
>>  >>>> as Justin suggested in an off-list discussion, we could have the
>>  >>>> controlling agent send a second USE-CANDIDATE once aggressive
>> nomination
>>  >>>> converges.
>>  >>>
>>  >>>
>>  >>> Did you consider using the updated offer to indicate that you're
>> really
>>  >>> done? This would require that you always send it (i.e., a slight
>>  >>> modification to 5245), but that's something that has been already
>>  >>> proposed to be updated for other purposes.
>>  >>
>>  >>
>>  >> The point is to have all that information without involving
>> signalling,
>>  >> as is the case with regular nomination.
>>  >>
>>  >> Let me ask the question the other way. Is there any reason not to do
>> this?
>>  >
>>  >
>>  > Just the usual: are the benefits higher than the added complexity.
>> Here, depending how it's done, the added complexity should be fairly low
>> though.
>>
>> The complexity of having to handle that over signalling and the need to
>> implement it on every sig protocol that ever dares to use ICE is
>> arguably much higher than that of an extra attribute
>>
>
> Actually I meant the complexity of implementing something like this, and
> why to do/not to do this (in any way).
>
>
>   > For the benefits, currently with SIP you are allowed to release the
>> not selected candidate resources after 3 seconds from concluding ICE
>> (http://tools.ietf.org/html/rfc5245#section-8.3.1).
>>
>> And that is the whole point because currently with aggressive nomination
>> you simply don't know exactly when ICE has concluded.
>>
>
> So if you assume aggressive ICE has concluded after you've got your first
> USE-CANDIDATE checks done (as the text currently says), and you stop doing
> keep-alives on all except the selected candidate pair and let your relayed
> and reflexive candidates die away. You still have some time to switch
> between the candidates since the candidates are still alive for at least
> some (tens of?) seconds. Isn't that OK?
>
>
> Or did you have some other kind of resources in mind?
>
>
> Cheers,
> Ari
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>