Re: Issue 176: More responsive mobile ICE failover and Wifi/3G/4G switch-back

Not only does IPv6 help keep a stable IP for 4G (as designed), this draft will help maintain a stable IP for TURN despite network interface changes:
https://tools.ietf.org/html/draft-wing-tram-turn-mobility-02

This is another reason why assuming which remote candidates are pruned or not pruned for an IceTransport is not necessarily a good idea because TURN in this mode would allow for a stable back-up and testable IP in the event of switch of a failover.

-Robin

On February 7, 2015 at 10:35:55 AM, Robin Raymond (robin@hookflash.com) wrote:


The issue:
Wifi and 3G/4G can go up/down like a yo-yo. A mobile device can go in/out of Wifi and 3G/4G range where switching between the networks seamlessly is highly desirable but difficult in practice due to the cost of keeping interfaces "hot" and / or firewalls interfering with communications (i.e. pinholes close or reflexive / relay ports / IPs change).

Scenario A:
1. IceTransport discovers Wifi and 3G/4G are available but settles on the preferred Wifi candidate pairing.
2. Wifi stops working and 3G/4G might be a viable option but those candidates were already pruned within the IceTransport due to current ICE rules (despite the other candidate(s) still being viable).

Scenario B:
1. IceTransport discovers 3G/4G is available but not Wifi.
2. Wifi becomes available. The new host (presumably reflexive and relay as well) candidates are transmitted and used. (nice)

This issue is also related to issue #174 . 

Problem:
For scenario A, the IceTransport must go into a full disconnected state and cause an ICE restart to occur to resolve the issue. But the better solution would be to allow the ICE engine to know that candidates are NOT expired remotely and thus when trouble "starts" the backup non-expired host, reflexive and possible relay candidates can be tested. In the case of 3G/4G, the reality is for mobile IPv4 that the firewalls will close the pinholes and they will not remain viable reflexive candidates for very long. But mobile IPv6 only requires mutual IceTransport connectivity checks to reopen pinholes to be a viable backup when Wifi starts to fail.

For scenario B, this works nicely but the reflexive and relay candidates are likely to be required for Wifi to work again. If the IceGatherer is not aware that it needs to power backup the Wifi and re-discover reflexive / relay candidates then Wifi switch-back over will likely fail too, especially if the IceGatherer is in full "prune unused candidates" operating mode and the IceTransport is already settled on the "completed" state.

Solutions:
(a) Before a full "disconnect" of an IceTransport, start testing still viable back-up candidates mutually. This would allow 3G/4G IPv6 failover to have a reasonable chance of success without a full restart (and a faster response time before full disconnect where the application layer needs to be involved).
(b) When interfaces come back-up (e.g. Wifi becomes available), temporarily re-gather the reflexive and TURN candidates if those candidates would have higher priority than other candidates active within any of the attached IceTransports.
(c) Do nothing and expect "restart" to solve this issue.

I personally would recommend (a) and (b) solutions be done. I think that would allow for nice failover to 3G / 4G IPv6 which is available (NOTE: IPv4 mobile is being flagged as "optional" now and "IPv6" is mandatory by the mobile industry):
http://ipv6.com/articles/mobile/Mobile-IPv6.htm
http://en.wikipedia.org/wiki/IPv6_deployment

Likewise (b) would allow new interfaces that show up with potentially higher priority to take over when they become available. Without the re-gather of the reflexive and maybe the TURN the Wifi is likely to not succeed.

I dislike (c) from the user experience perspective. This would require a full "disconnect" to happen before any reaction takes place. This means not just a short "glitch" where audio / video resumes once candidate back-ups are tested but a full failure where the application layer is needed to be involved to resolve scenario A. Solution (c) does not allow for scenario B optimizations either as even though a preferred host candidate might show up as there's no guarantee host related reflexive or relay candidates might come back after the "completed" IceTransport state.

-Robin