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

[Justin Uberti <[e-mail]>]

On Wed, Mar 18, 2015 at 4:49 PM, Robin Raymond <[e-mail]> wrote:

>
>
> [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.
>
> [Justin wrote]:
> 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.
>
>
> As a general note, this draft is very much on the right direction.
>

Thanks - glad it looks useful.

>
> As for having to keep the wwan ‘hot' for the sake of pinhoeles/turn - not
> necessarily. Consider the case where the controlling side is on mobile but
> the controlled side is desktop with TURN. The mobile side might keeps it
> wwan IP alive but not used (e.g. IPv6 interface). The controlled side might
> keep it’s TURN candidate alive as a backup should the primary path fail.
> Neither side need to be actively pinging between each other but keep their
> respective interfaces alive in the event of primary path failure. You are
> correct that the pinhole won’t remain open since it’s not an active tested
> path but both are good back up candidates in the event of primary path
> failure (and if both check simultaneously then the pinholes will open). The
> moment both sides simultaneously detect failure they could both start doing
> connectivity checks to the other which will re-open the pinholes and allow
> traffic on the backup path (but this can only happen if candidates are NOT
> pruned away).
>

This doesn't work in all cases, e.g. NATs with address-dependent mapping.
For those, the binding must be kept warm or else it will become invalid and
repinging will generate a new binding.


>
> I think the couple of “TODOs” you have in the draft will resolve many of
> the remaining issues I see. Specifically, 5.2, “should the controlled side
> have any say …]. My answer is “yes”, either side should be able to send a
> connectivity check to keep an active candidate pair alive but I agree
> controlling side should always pick the nominated/active path.
>

I wasn't proposing the controlled side be able to keep pairs warm; it
probably makes no sense to do so since the controlling side decides what is
actually used. The question here is whether the controlled side can
specifically drop 'backup' candidates that have some downside, e.g. cost.
It seems potentially useful so I agree we should provide for this.


> The other 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.” I
> think a LIFETIME option for a candidate (and indirectly would be the
> combined pair lifetime) would be a good idea. This would allow an ice
> transport to know which remote candidates are considered gone vs still
> around / available. Thus candidate pairs can be kept as “backup” should the
> primary path(s) look like it is failing and they can be checked again for
> connectivity as long as both local / remote candidate pairs are still
> considered alive. When a primary path looks like it might be failing, both
> parties could recheck simultaneously their backup candidates (which would
> open firewall pinholes at that time to each other) and the backup
> candidates could therefor work and a temporary switch could happen to the
> backup candidates until the primary path either comes back [or fails
> completely]. This will work well with TURN and/or IPv6 on mobile. This
> would require ICE not prune non-failed pairs so long as the combined
> candidate pair LIFETIME was still alive.
>

The point of LIFETIME would be to declaratively tell the controlled side to
stop using a pair. Otherwise, we have to use some sort of timeout. I think
either could work, it's just a question of whether LIFETIME provides more
flexibility.

>
> There is another scenario that does cause me concern though. I’m concerned
> that ICE will cause fallback to wwan (good) but it will not recognize that
> a wlan was back available again (bad). A wlan can temporarily be disrupted
> causing a fallback to wwan. Because candidates are only trickled when they
> become availing and the IP for the wlan never goes away when connectivity
> fails, the wlan candidate are never trickled again (and a new STUN test
> might reveal the same firewall port so that won’t be trickled again
> either). If the wlan interface is just intermittently failing then remote
> party may have pruned the wlan candidates away and never retest it again
> and thus the connection remains on wwan permanently. Since the connection
> is working there’s no reason to restart ICE either. So I think there is a
> need here that a wlan device may have “reachability” checks it conducts on
> its own and then re-trickle the candidate back when it detects
> “reachability" for the wlan has changed to available.
>

As I understand it, the failure scenario here is for a wlan pair to be
selected, then wlan fails, wwan is selected, and wlan is pruned due to
multiple failures. I think this is a subset of the problem of being on
wwan, and then entering an environment where wlan is available - in this
case, you'd want to collect new wlan candidates since the wlan interface is
preferred.

>
> So I’m +1 on this draft and +1 for controlled keep-alines and definitely a
> +1 for candidate “LIFETIME".
>
> -Robin
>
>