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

[Robin Raymond <[e-mail]>]

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

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

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.

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.

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.

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

-Robin