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

On Tue, Mar 10, 2015 at 1:40 PM, Bernard Aboba <bernard_aboba@hotmail.com>
wrote:

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

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