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

[Justin Uberti <[e-mail]>]

It is important to understand that this proposed approach doesn't change
the interactions with signaling at all.

Currently, when doing regular nomination, the CONTROLLING can use its own
policy to decide which active candidate pair to use, as is described in
RFC5245, S 8.1.1.1. This is not possible when doing aggressive nomination.
The solution I am proposing fixes this issue.


On Wed, Jul 23, 2014 at 8:42 PM, Parthasarathi R <[e-mail]
> wrote:

> Hi Emil,
>
> It is better to handle through signaling as it provides to flexibility in
> the application (like forking usecase). In case of pushing the intelligence
> within ICE will just move the portion of the signaling to ICE in case the
> application is required to know.
>
> Please note that the signaling protocol which choose not to indicate it
> based on the specific signaling protocol design.
>
> Thanks
> Partha
>
> > -----Original Message-----
> > From: mmusic [mailto:[e-mail]] On Behalf Of Emil Ivov
> > Sent: Thursday, July 24, 2014 3:58 AM
> > To: Ari Keränen
> > Cc: mmusic
> > Subject: Re: [MMUSIC] Seriously, USE-CANDIDATE!!! in 5245bis
> >
> >
> >
> > On 23.07.14, 18:21, Ari Keränen wrote:
> > > On 7/23/14 6:00 PM, Emil Ivov wrote:
> > >>
> > >>
> > >> On 23.07.14, 12:30, Ari Keränen 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).
> > >>
> > >> Yes, so did I. We are talking about the "complexity" of adding one
> > ICE
> > >> attribute as opposed to intertwining the states of ICE and
> > signalling
> > >> and making them dependent on each other.
> > >>
> > >>>>  > 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?
> > >>
> > >> If I assume ICE has concluded after my *first* USE-CANDIDATE and let
> > >> everything die away then, with aggressive nomination, how am I ever
> > >> going to get a second?
> > >
> > > It takes a while before your server reflexive and relayed candidates
> > die
> > > out so you have some time to get more checks through. Of course you
> > > shouldn't close the local sockets immediately. However, if you want
> > to
> > > do that considerably (> tens of second) later, and perhaps multiple
> > > times, it may get more complicated (something like mobility with
> > ICE).
> >
> > These are exactly the kinds of hacks that implementations try to do
> > today. Magic timers and proprietary logic. This is exactly what I was
> > hoping we could remove by replicating the same feature in aggressive
> > that we already have for regular nomination. As Justin put it:  giving
> > a
> > way to the controlling agent to communicate it's selection to the
> > controlled.
> >
> > It simply doesn't make sense not to have it and it would simplify
> > things
> > a lot so the argument "it would add complexity" doesn't really hold.
> >
> > Emil
> >
> > --
> > https://jitsi.org
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>