On Thu, 25 Feb 2016, Patrick McManus wrote:
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..
Very good point. The multiple triggers will still be bad even if the HTTP/1
connections would surive.
The log I have doesn't reveal that detail, it was limited to detecting what
the network changes were. Since the user didn't even know there was a network
change, my guess is that it wasn't actually used. Of course I can ask about
it, or get more logs.
But then, just because it wasn't used (I'm not even sure how we should decide
if the interface was used) the previous time the interface was present I don't
think we can assume that it won't be used this time...
--
/ daniel.haxx.se
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
