On Thu, 17 Mar 2016 09:32:28 +0100 (CET) Daniel Stenberg <[email protected]> wrote:
>On Thu, 25 Feb 2016, Patrick McManus wrote: > >> the remedies are backwards looking (flush caches, close connections >> etc).. so the phrasing about the hash was probably too lazy, but >> perhaps the basic idea has merit? > >We can certainly use a hash to figure out that we're dealing with a >"yo-yo interface", but what to do with that information is the tricky >part. > >I'm currently thinking of a few different routes of exploration: > >1. check the routing table (updates) to better figure out when an >adapter is removed but doesn't affect the routing as then it shouldn't >need to cause a network change. Then it would also have to not signal >a network change on a new adapter until it gets routing added to it. I >don't really know what the Teredo adapters get in terms of routing by >default - and especially not for these yo-yo setups. > >2. check data counters for the particular adapter so an unused adapter >can be ignored when removed. This will obvsiously not affect new >adapters so it'll only address half the problem. > >3. Use of a hash to store added and removed adapters and keep them >around for N minutes (I'm thinking 300 seconds to start with). If an >adapter is added/removed and its name is already in the hash, it's a >yo-yo and we ignore it. It is a bit harsh and risky but... We could >potentially work on a scheme where the N value changes over time to >adapt. > >4. Short-term and the most abrupt: disable (behind a pref) the use of >NotifyIpInterfaceChange. It makes Firefox go back to the old >NotifyAddrChange() method which doesn't have this problem - mostly >because it doesn't support IPv6. Incidentally, Chrome only uses >NotifyAddrChange to detect network changes. > From: Patrick McManus <[email protected]> To: Christopher Barry <[email protected]> Cc: dev-tech-network <[email protected]> Subject: Re: A network-change detection and IPv6 quirk - on Windows Date: Thu, 17 Mar 2016 10:38:31 -0400 Hi Christopher, On Thu, Mar 17, 2016 at 8:38 AM, Christopher Barry < [email protected]> wrote: > Should all network applications behave in this manner, Only firefox (and gecko) is in scope here. myriad implementations and redundancies? Is it in fact the domain of > network *applications* to do this? > > when necessary to ensure security, performance and usability applications have always availed themselves of customizations beyond that provided by the operating system. Firefox will do so on a case by case basis. > Isn't this a systems function that should be left to the system > itself? That's always a judgment call. I mean we have our own set of PKI roots bundled in firefox - so we aren't purists on the issue when we think we can bring value. > I seem to remember another out-of-scope foray where FF was using > built-in dns server addresses behind the user's back a while ago, > I don't believe that is true - I would be interested in any citation you had. That being said, we don't do that because at this point in time we don't think it would be a good user experience. If we had a model where it added value we would consider doing so openly and likely with user choice. > still happening too? Why is FF going here? Why does it *need* to? Do > sometimes the underlying services and even standards they implement have trouble at web scale - especially at the tail. The issues Daniel are working with are correlated with network mobility - that's why he is using changes in addressing as a proxy for mobility. This can manifest itself in some odd ways: TCP can simply stall for minutes (or hours) before figuring out the connection isn't working any more, that's a bad user experience. Your proxy selection may or may not be relevant after such an event. Same thing with your DNS cache because of split DNS. Some unauthenticated data that you used in one location might want to be flushed from cache when you move, etc.. We see this when you wake from a sleep with an open H2 session - an attempt to reuse it can just hang for a long time without any feedback Daniel's code provides a framework for when more aggressive timeouts are appropriate. And we are actively working on this stuff in the standards space where applicable. > This kind of stuff is out-of-authorized-and-expected-scope for a user > program, and frankly is more than a little creepy. I know others will > share this concern if/when they are aware of it. > > I don't share your concern that awareness of local addressing is out of scope for a user space application. Indeed, enforcing security around that kind of thing is the role of the operating system and we wouldn't attempt to subvert that. The OS provides an unpriv'd interface to learn about address changes and we're listening to it - not a big deal. From: Daniel Stenberg <[email protected]> To: Christopher Barry <[email protected]> cc: [email protected] Subject: Re: A network-change detection and IPv6 quirk - on Windows Date: Thu, 17 Mar 2016 15:39:22 +0100 (CET) User-Agent: Alpine 2.20 (DEB 67 2015-01-07) On Thu, 17 Mar 2016, Christopher Barry wrote: > Should all network applications behave in this manner, detecting and > internally adjusting to network modification? Would this not lead to > myriad implementations and redundancies? Is it in fact the domain of > network *applications* to do this? I don't think I can speak for all network applications, but I think all applications that have long lived connections to remote servers, where the application travels in and out of networks while running, where there are network interfaces coming and going and for which networks expose different "realities" or "views" of the world depending on which network you're on will benefit from acting on network changes. By being aware of network changes and adapting to them, we actually improve the user experience quite significantly thanks to less stalled connections that require the user to either just wait out or shift-reload to fix, with less old/wrong content sticking around and surviving into the new network while it was only actually true in the former network and we increase responsiveness for proxies (when moving in/out of "proxy controlled" networks). If we don't react to network changes appropriately, users suffer. > Isn't this a systems function that should be left to the system > itself? Yes, if that worked it'd be aweseome but as it is now, the stack works in one way and we need to give it some gentle pushes to act more in ways we like. > I seem to remember another out-of-scope foray where FF was using > built-in dns server addresses behind the user's back a while ago, and > *bypassing* the specific servers set by the administrator. Is that > still happening too? Sorry, I don't know what you're referring to so I don't know and can't comment on that specific thing. But of course we're not strangers to trying out things in any area, if we think it improves functionality or user experience etc. Experiments of course by their nature don't always pan out successful. > Do you see a problem not being addressed by the system, are > frustrated that your efforts to help change it there are not being > addressed, and thus are creating these homegrown workarounds? Why is > this even an issue? Why does it actually matter which interface you > are communicating through? It isn't important which network interface Firefox is using. We're detecting that there is a *network change*. Any network change. And when such a change has happened we act on that information. It is for example very common for networks to have private DNS spaces, to show different views of the same site and more depending on which network you are on. And it is also common that connections get stalled in the actual process of switching networks and the regular way to detect that is very slow and that slowness leads to frustrated users. This is just one of those tiny little details ordinary humans don't need to bother or care about. Firefox is by the way not the only browser detecting network changes and acting on them. > This kind of stuff is out-of-authorized-and-expected-scope for a user > program, and frankly is more than a little creepy. Sorry, I don't understand. Exactly how is this creepy and why? There's really no magic involved here. -- / daniel.haxx.se ======================================================================== I've had to cut and paste the thread parts into position above to help provide some context here. Their nesting is of course broken now. It's generally acceptable, and indeed appreciated to continue to use the complete message thread, keeping it intact, replying inline if desired, but it's generally not helpful to cherry pick parts of a thread and still reply to the original thread with most of it missing. It simply makes it impossible to follow without opening every single response individually. That has been the case for the twenty plus years I've been using mailing lists anyway. >From my read of the fist post that I saw, which I will admit was incomplete and missing most of it's context, you, Daniel, are discussing adapters being removed from the system, analyzing routing tables, counters, considering virtual tunneling adapters, etc. What's creepy, is that a generic user-level network application is concerning itself with low level system information. Strictly speaking, this data is really none of FF's business. I get you are concerned with your users experience and you want to make it as performant as possible, and while I laud your commitment to your user base, I think your efforts could be more useful at the system level. I get also that you work for Mozilla, so you are seeing it through that lens, that set of restrictions, and from that set of issues and requirements. However, I think your energies should probably be put toward helping to fix the underlying part that's non-optimal, not hacking stuff on top of a networking stack that's obviously inadequate to deal with roaming at speed, or docking/un-docking/un-suspending - because apparently that's become a huge issue. Perhaps time better spent would be teaching users that changing network adapters or state will negatively impact active network applications. Hacking in workarounds to cater to the least aware and informed amongst us is causing you to veer outside of your lane, and really should be avoided. Just because others (Chrome?) are taking the approach of cobbing system stuff into a browser does not mean Mozilla should too. As for the dns topic I mentioned, my concerns there were eerily similar to these here. The dns thread is here Patrick, to which you responded a few times: https://groups.google.com/forum/#!topic/mozilla.dev.tech.network/D8UmrLZZh5k The fact that the concern I mention is very similar for two very different things says to me that straying into the system arena and (attempting to) control and/or bypass system stuff is not an unusual event, is not seen as off-limits, and in fact is seen as completely acceptable if it serves your immediate purposes. My opinion is that this basic mindset and approach is ineffective, non-standard, somewhat irresponsible, will lead to multiple variously hacky redundant implementations across similar applications, add even more bloat, provide less security, and increase the likelihood of even more privacy invasion. All in the name of 'fixing' something that arguably is not actually broken. That's what concerns me. -- Regards, Christopher _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
