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

["Stach, Thomas" <[e-mail]>]

Justin,


From: Justin Uberti [mailto:[e-mail]]
Sent: Sonntag, 22. März 2015 05:09
To: Stach, Thomas
Cc: [e-mail]
Subject: Re: [MMUSIC] Fwd: New Version Notification for draft-uberti-mmusic-nombis-00.txt



On Thu, Mar 19, 2015 at 9:39 AM, Stach, Thomas <[e-mail]<mailto:[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?
[TS] These questions apply  if continuous nomination (CN) would be an inherent part of Trickle-ICE.
It might be useful for implementations mentioned above that don’t want to go all the way down to CN.
However, using two separate flags (trickle and continuous) would do the job as well.

Apart from that, the half-trickle case needs to be addressed. How does the end-of-candidates flag in the offer affect CN?
If CN is supported by the answerer, could the offerer still use CN although it indicated end-of-candidates?


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.
[TS] OK, but you might want to spell it out.

Regards
Thomas