network link detection is a signal that drives a remedy. i.e. we detect the network has changed and we do something about it.
The discussion here should be about the signal (that the network has changed) - if the remedy needs to be tweaked (which I'm not convinced of) we can do that separately. Remember that there are quite a few things that get done as part of the remedy not even mentioned here and the real issue here is that the signal is too noisy. So let's talk about the signal. I don't think we want to just ignore teredo - a tunnel coming and going is relevant to the general problem at hand, but it appears the tunnel isn't relevant to the use case of the reporter. Here's a basic question - is the address of the tunnel ever used by necko in the log? Perhaps we could only hash interfaces with addresses that have seen use.. On Thu, Feb 25, 2016 at 2:23 AM, Daniel Stenberg <[email protected]> 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? > > -- > > / daniel.haxx.se > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
