RE: Issue 179: Faster failover timings for RTP inactivity vs network failover

As you say, Option (a) would very likely result in false positives, even if it were only fired after loss of several consent checks. Under Option (b) I would include a variety of future ICE improvements, such as support for multiple nominated pairs (e.g. ICE implementation could switch from a failing candidate pair to a working one prior to consent failure), continuous gathering (e.g. implementation brings up a WWAN interface in response to decreasing signal strength on the WLAN interface on which consent failures are happening), etc.  So this one seems the most reasonable. 
________________________________________
From: Robin Raymond [robin@hookflash.com]
Sent: Tuesday, February 10, 2015 1:37 PM
To: public-ortc@w3.org
Subject: Issue 179: Faster failover timings for RTP inactivity vs  network failover

When RTP data is flowing over an ICE Transport via an RTP sender, it's easy to determine the ICE Transport is still alive / active due to the incoming / outgoing validated SRTP packets. However, a lack of activity is not necessarily an indication of failure thus the current ICE Transport "disconnect" state failure can be significantly long before an application becomes aware a problem is occurring.

Scenario A:
1) RTP Sender sends packets over ICE Transport
2) .stop() is called on RTP Sender and ICE Transport sends ICE connectivity checks in absence of RTP data (at a slow interval rate)

Scenario B:
1) RTP Sender sends packets over ICE Transport
2) A transport failure occurs and ICE Transport stops receiving results from connectivity checks and ICE transport eventually goes into "disconnected" state

Issue:
The application must wait until a full ICE Transport "disconnect" state has occurred before an ICE re-gather can be attempted and only then can the application exchange the new candidates after the initial failure actually happened (e.g. could be 30 seconds of time).

Solutions:
(a) ICE Transport could signal an issue might be happening well before the full "disconnected" state. This would allow the application layer to warm up the gatherer and get some new candidates well before waiting for a full disconnect to occur.
(b) ICE Transport could automatically warm up the ICE gatherer when there might be an issue detected and thus the ICE gatherer will obtain new (or refreshed) candidates and signal those new candidates in a manner as normal trickle ice would reveal then over time to be signalled to the remote party (thus the ICE Transport would effectively heal itself).
(c) Do nothing and wait until "disconnected" happens before the application is aware and live with the long time it will take to detect a full failure state.

Right now, we have (c) by doing nothing. I don't like this excessive timeout. I prefer option (b) where the gatherer is allowed to go out and get new candidates if it detects things are going wrong well before the full disconnect. I think (a) is good in that more control is allowed but I can see it difficult for the application developer to get right, especially if the ICE Transport falsely flags a temporary connectivity issue which resolves itself early (and thus the ICE gatherer can be put back to sleep by the ICE Transport straight away).

This issue is related to issue #174 and #176


-Robin

Received on Saturday, 14 February 2015 22:36:32 UTC