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

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: juberti@google.com
Date: Mon, 9 Mar 2015 16:52:14 -0700
To: mmusic@ietf.org
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:  <internet-drafts@ietf.org>
Date: Mon, Mar 9, 2015 at 2:18 PM
Subject: New Version Notification for draft-uberti-mmusic-nombis-00.txt
To: Jonathan Lennox <jonathan@vidyo.com>, Justin Uberti <justin@uberti.name>

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

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic 		 	   		  