Re: [MMUSIC] Fwd: New Version Notification for draft-uberti-mmusic-nombis-00.txt

[Justin Uberti <[e-mail]>]

On Thu, Mar 19, 2015 at 9:39 AM, Stach, Thomas <[e-mail]>
wrote:

> Justin,
>
> I think continuous nomination is a very useful enhancement.
>
> I'm just wondering if this needs to be an extension to Trickle-ICE via
> ice-option:continuous
> or if it could be an inherent part of trickle-ICE.
> Are there use cases where Trickle-ICE is needed without continuous
> nomination?
> I mean apart from implementations of the current Trickle-ICE drafts.
>

Trickle ICE is useful without continuous nomination, and while I agree you
would probably want to use both together, I suspect that there will be a
nonzero number of applications that will not be ready to go all the way to
continuous nomination (at least at this point in time).

>
> With respect to deprecation of aggressive nomination, couldn't this just
> be declared as non-usable for Trickle-ICE,
> if not completely deprecated in ICEbis as already proposed at IETF91?
> A vanilla-ICE agent anyhow needs to fallback to regular nomination when it
> sees ice-options:trickle.
>

Yes, that makes sense - it would avoid the need for the pseudo-option
mentioned in the draft.

>
> A few more questions or comments:
>
> Is there a need to request the other peer to stop continuous nomination?
> Could the end-of-candidates flag used to indicate that continuous
> nomination has stopped locally?
>

I don't think continuous nomination ever stops - hence the name :). Could
you explain why you think this might be necessary?

>
> Section 3.1 states
> "ICE endpoints MUST be able to start transmitting media immediately upon a
> successful ICE check, ..."
> This is not addressed yet in section 5, which currently focuses on
> switching to a new pair.
>

This is handled by the tweaks in section 4 to regular nomination.
Continuous nomination inherits this behavior.