Re: A network-change detection and IPv6 quirk - on Windows

First, how are you detecting slow connections?  Just by not receiving 
data?  If so, that is a wrong approach and always was.

You have out of bounds ways to detect this - TCP keep alive.  I don't 
remember if that has been put off the table as uncontrollable on all 
platforms or too faulty.  If not, setting the TCP keep-alive timeout 
_during the time you are receiving a response_ to something reasonable 
(your 5 seconds) will do the job for you very nicely.  And I also think 
that 5 seconds is a too small interval.  At least 10 would do better IMO.

Other way is to rate the _response_ and probably also each 
_connection_.  You can measure how fast they are receiving and adjust 
your timeout according it.  Still not a perfect solution and also not 
simple and also stateful.

In general, I'm very much against application-level timeouts.  I was 
never able to find the right time and whichever value you choose you 
always overlap both the good and the bad land as well.


-hb-


On 2/25/2016 10:23, Daniel Stenberg wrote:
> Hi friends,
>
> I work on a little issue (bug 1245059) that I feel I could use some 
> feedback or thoughts on, on how to best go about and handle it. This 
> problem is happening on Windows (right now) but in theory it could 
> happen similarly on other platforms too.
>
> The ground rules:
>
> 1. We trigger an internal network change event on IP and network
>    interface changes.
>
> 2. We make a checksum of all network "adapters" and their IP addresses to
>    avoid duplicate events. We also coalesce events to not send them 
> more often
>    than once per second.
>
> 3. When a change is detected, we want to detect stalled HTTP 
> connections to
>    avoid "hangs" and to provide a snappier experience.
>
> 4. A "stalled" HTTP/1 connection is detected by not having traffic for N
>    seconds. There is no difference between a stalled connection and a
>    connection on which the server is just very slow to respond and thus
>    leaving an N second pause. (N is 5 seconds by default).
>
> The problem:
>
> 1. The user uses a slow server that often takes more than N seconds to
>    respond.
>
> 2. The same user has a (Microsoft Teredo tunneling) network adapter that
>    appears and disappears every few minutes (with 60 - 200 seconds 
> interval it
>    seems) thus triggering network change events fairly often.
>
> 3. User gets sad face because Firefox keeps cutting off slow (but 
> working)
>    HTTP requests. (There's a few other downsides to these frequent 
> network
>    change events, but they're not as visible.)
>
> Additionally:
>
> - Yes, this seems like a broken/strange user setup, but still it 
> happens and
>   it is not causing a (noticable) problem for the user if Firefox is 
> prevented
>   from killing silent HTTP connections.
>
> - We can detect Teredo tunnels by its IP address range, but how does that
>   help?
>
> The bug:
>
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1245059
>
>
> Any bright ideas?
>