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

From: Justin Uberti <[email-masked]>
Date: Mon, 9 Mar 2015 16:52:14 -0700

This document proposes updates to how ICE nomination is conducted.

In particular, it suggests that Regular Nomination can be used to get all
the benefits of Aggressive Nomination, and therefore Aggressive Nomination
can be deprecated without sacrificing latency.

It also proposes a new mechanism, known as Continuous Nomination, which
allows for in-call optimization of the media path, and discusses how it
could be used to pick a path with the lowest RTT, how to deal with a newly
discovered TURN server, and how to switch seamlessly between wifi and
cellular networks.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Mar 9, 2015 at 2:18 PM
Subject: New Version Notification for draft-uberti-mmusic-nombis-00.txt
To: Jonathan Lennox <[email-masked]>, Justin Uberti <[email-masked]>

A new version of I-D, draft-uberti-mmusic-nombis-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Name:           draft-uberti-mmusic-nombis
Revision:       00
Title:          Improvements to ICE Candidate Nomination
Document date:  2015-03-09
Group:          Individual Submission
Pages:          12
URL:            http://www.ietf.org/internet-drafts/draft-uberti-mmusic-
nombis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-uberti-mmusic-nombis/
Htmlized:       http://tools.ietf.org/html/draft-uberti-mmusic-nombis-00

Abstract:
   This document makes recommendations for simplifying and improving the
   procedures for candidate nomination in Interactive Connectivity
   Establishment (ICE).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Mar 2015 13:40:39 -0700

Good document.  A few comments:  
Section 5.2
   During continuous nomination, the controlling side may still elect to
   prune certain candidate pairs; for example, an implementation may
   choose to drop relay candidates once a successful connection has been
   established.  The controlled side, however, should follow the
   controlling side's lead in terms of deciding whether any pairs should
   be pruned.  [TODO: should the controlled side have any say in the
   matter, e.g. to eliminate certain candidates?]  
[BA] The controlled side probably shouldn't prune candidates that the controlling side has indicatedshould be kept alive, or (if a timeout is used) before the timeout expires.  However, an interface could of course go down. 
   The controlling ICE
   Agent informs the remote side of its preferences by continuing to
   send Binding Requests to the remote side on each candidate pair that
   it wants to retain.  The controlled ICE Agent SHOULD prune any
   candidate pairs that have not received a Binding Request in N seconds
   (30?), and SHOULD NOT keep alive any candidates that are not
   associated with a live candidate pair.  [TODO: decide if this
   implicit timeout approach is correct, or if we should have some sort
   of approach similar to TURN LIFETIME indicating when a pair should be
   GCed, with LIFETIME==0 indicating immediate GC.] 

[BA] As noted in Section 3.3: 
   the controlling endpoint MUST have some way to indicate to the
   controlled side that specific candidates are to be kept alive.

To achieve this goal, is it necessary to send Binding Requests for each candidate pair to be kept alive? This could consume quite a bit of energy, particularly if there are multiple candidates on both sides.  I wonder if there are ways to achieve the goal more economically.  
For example, on the controlled side, if the relay candidate receives a check but the corresponding host candidate doesn't, it would make no sense to prune the host candidate.  Similarly, if a relay candidate on the controlled side is kept alive due to receipt of a periodic check originating from a WLAN interface, does the controlling side also have to periodically wake the WWAN interface so as to check that same relay candidate?  I realize that the WWAN interface does need to be periodically awoken to satisfy the requirements on RFC 5245 Section 4.1.1.4.  
The explicit timeout approach could reduce the burden still further by reducing the interval at which checks need to be done.  
   One side benefit of
   doing this is that the continuous exchange of Binding Requests across
   all candidate pairs allows the RTT and loss rate for each to be
   reliably determined and kept up to date.
[BA] Unless the checks are pretty frequent, it may be hard to derive a reliable RTT/loss rate estimate from them.   

From: [email-masked]
Date: Mon, 9 Mar 2015 16:52:14 -0700
To: [email-masked]
Subject: [MMUSIC] Fwd: New Version Notification for	draft-uberti-mmusic-nombis-00.txt

This document proposes updates to how ICE nomination is conducted. 
In particular, it suggests that Regular Nomination can be used to get all the benefits of Aggressive Nomination, and therefore Aggressive Nomination can be deprecated without sacrificing latency.
It also proposes a new mechanism, known as Continuous Nomination, which allows for in-call optimization of the media path, and discusses how it could be used to pick a path with the lowest RTT, how to deal with a newly discovered TURN server, and how to switch seamlessly between wifi and cellular networks.

---------- Forwarded message ---------
From:  <[email-masked]>
Date: Mon, Mar 9, 2015 at 2:18 PM
Subject: New Version Notification for draft-uberti-mmusic-nombis-00.txt
To: Jonathan Lennox <[email-masked]>, Justin Uberti <[email-masked]>

IETF repository.

Revision:       00

Pages:          12

URL:            http://www.ietf.org/internet-drafts/draft-uberti-mmusic-nombis-00.txt

Abstract:

   Establishment (ICE).

The IETF Secretariat

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Justin Uberti <[email-masked]>
Date: Tue, 10 Mar 2015 17:45:57 -0700

On Tue, Mar 10, 2015 at 1:40 PM, Bernard Aboba <[email-masked]>
wrote:

> [BA] The controlled side probably shouldn't prune candidates that the controlling side has indicated
>
> should be kept alive, or (if a timeout is used) before the timeout expires.  However, an interface could of course go down.
>
>
>    The controlling ICE
This is a good question, but I think any NAT pinholes for established pairs
need to be kept alive, similar to what is described in 4.1.1.4 for
candidates. Given that keeping your srflx candidates alive will require
waking the wwan interface somewhat frequently anyway, pinging existing
pairs can probably be done with little additional energy expenditure if
properly coalesced. Or, if this is a significant issue, the app may not
choose to keep wwan active if wifi is solid.

> [BA] Unless the checks are pretty frequent, it may be hard to derive a reliable RTT/loss rate estimate from them.
Right, this relates to the discussion above. Frequent checks are good for
dynamically determining an optimal path, but may have power considerations
in certain cases.

>
>
> ------------------------------
> From: [email-masked]
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 19 Mar 2015 16:39:10 +0000

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.

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.

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?

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. 

Regards
Thomas

---

From: Justin Uberti <[email-masked]>
Date: Sat, 21 Mar 2015 21:09:21 -0700

> 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,

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

> 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?

> This is not addressed yet in section 5, which currently focuses on

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

---

From: "Stach, Thomas" <[email-masked]>
Date: Sun, 22 Mar 2015 15:38:25 +0000

Justin,

From: Justin Uberti [mailto:[email-masked]]
Sent: Sonntag, 22. März 2015 05:09
To: Stach, Thomas
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Justin,

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).

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

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Mar 2015 23:56:38 +0000

Hi,

> To achieve this goal, is it necessary to send Binding Requests for each candidate pair 
> to be kept alive? This could consume quite a bit of energy, particularly if there are multiple 
> candidates on both sides.

Don't you need to do that anyway, if you use continuous consent?

Section 4.1 of draft-ietf-rtcweb-stun-consent-freshness-11 says:

	"After a successful ICE connectivity check on a particular transport address,
   	consent MUST be maintained following the procedure described in this
   	document." 

I assume that applies to every valid candidate pair. Or?

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Mon, 23 Mar 2015 14:43:04 -0700

> > candidates on both sides.

Sending a few STUN packets doesn't cost appreciable energy, although
powering up the radio does. For most devices, you won't want to maintain
multiple active radios unless you think one might suddenly drop out.

> I assume that applies to every valid candidate pair. Or?
Right, any pair that you might want to switch to will need to maintain
consent.