It seems to work fine here (iPhone 4, iOS 5.1), and I've not had a problem with g+ on 4.3.x or 5.0.[01], AT&T and various Wi-Fi networks...
Is it really endlessly redirecting or perhaps timing out and trying to reload? I had that happen once when latency was extreme, on one occasion.
EDIT: here is the text for those who are having trouble.
Host resolution accounts for a significant portion of the networking component of page load time. As such, Chromium developers are always looking to optimize it. Here I present the current considerations of host resolution in Chromium, and look forward to the IPv4+IPv6 dual stack world and what that entails for browsers (and what Chromium is doing about it). I finish off with a presentation of some of the latest data we're operating on.
Currently, Chromium uses getaddrinfo() to ask the OS to resolve a host. This is a cross-platform, blocking API that abstracts the complicated host resolution. There are a number of advantages to using this API:
* Correctness - it handles all the complicated rules of hostname lookup correctly. It understands /etc/hosts, non-DNS namespaces like NetBIOS/WINS, etc. Re-implementing this behavior would be difficult.
* OS Caching - we get to share the OS host cache with other applications. Note that this doesn't exist by default on Linux systems.
* Less code - Having to maintain code sucks. It leads to code/binary bloat and endless bugs for corner cases and OS-specific issues. And it takes engineering time.
There are many disadvantages to using this API:
* Blocking - we need to use unjoined worker threads so we don't block critical threads
* Performance - we can't optimize the host resolution process, since it's behind the getaddrinfo() call. There are lots of optimization opportunities we miss.
* Application caching - we can't tell how long to cache a DNS record for in the application, since we don't get TTLs from getaddrinfo(). We try to be safe by only caching for a minute.
As noted previously, host resolution is a substantial portion of networking time, so we try to start it as soon as possible. Our network predictor subsystem learns to predict network requests and may initiate host resolution prefetches. While this provides substantial performance benefits, it also can lead to horrible user experience when it overloads upstream resolvers/devices. For example, check out https://code.google.com/p/chromium/issues/detail?id=3041 and https://code.google.com/p/chromium/issues/detail?id=12754, where users report "internet loss" that seems correlated to DNS prefetching. The problem is that Chromium is issuing too many DNS queries in a short period of time, which may overload upstream devices (typically cheap NAT routers) which then enter a anti-DoS mode and ignore DNS queries for a period of time. Due to excessively high getaddrinfo() failure timeouts varying by platform, this results in Chromium appearing to "hang" while displaying "Resolving host…" in the status bar. Our first step to combat this was setting limits on the number of outstanding getaddrinfo() calls. Currently, the limit is 8. However, it's still possible to overload upstream devices. Worse, when that happens, now we have this limit of 8 jobs, so even if we cancel the navigations and wait a short while for the NAT router to exit its anti-DoS mode and then try to browse to other pages, we can't issue anymore host resolutions until one of the 8 getaddrinfo() calls timeout. We identified this problem in http://code.google.com/p/chromium/issues/detail?id=73327 and implemented back off behavior to recover from this situation. The important thing to note though is that we are somewhat limited by existing network devices in the degree to which we can aggressively do DNS lookups for performance reasons.
Even before I deleted my Google+ account, this was a problem for months. As far as I can tell, nobody at Google is seriously approaching major UI annoyance in Google+ - it's all about the flash and ads.
Unsurprisingly, since deleting my account I've had no reason to regret that decision and have enjoyed the complete lack of notification spam.
Interesting topic, but a great example of why Google+ makes a terrible blogging platform - the formatting and link-wrapping make it impossible to read in places
So much smoke. I like how they mask very crystal-clear strategy with barely-relevant DNS statistics and data in an attempt to obscure what's happening.
"I’ll reiterate my view that I think Google controlling search, the browser, and the network or DNS layer is a dangerous trifecta that the consumer will probably be best served avoiding. I’m sure we’ll find out soon enough."
A lot depends on how you define 'control' in that context. People still have choices. No one is forced to use their services. I find Google's ambitions and scope amazing as well as a little frightening I'll admit. They now have a significant role in millions of peoples OS (Android, ChromeOS), their communications (GMail, Android), social circles (Google+), documents (Google Docs), browser they use (Chrome, Android, Google DNS), ads they see, applications/music/books they purchase (Play), videos they see (Youtube) and can now consolidate all they have gleamed about you into one solid product.
Don't troll on HN. My comment is the exact opposite of paranoia. Wesley's post papers over their strategic goals with technical jargon. That's not paranoia. That's the standard operating procedure for Google. They are an ad company. http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-...
I don't think that you have any objection with the Chrome team writing their own (presumably open source) DNS client (or at least if you do I'm unable to see why).
To try and guess your objection (please correct me if I'm misreading), this worries you because it would make it simpler for Chrome to default to using Google's DNS rather than the OS setting?
That's an interesting objection, and one I'd like to see discussed here. If that was your point I kinda wish you'd just said it rather than hinting darkly and linking to a couple page long article.
(disclaimer: I work at Google and care a lot about its soul/ethics. I do not speak for Google. Also, I'm a low-level engineer on stuff completely unrelated to Chrome/ DNS/etc.)
Of course this is what is going to happen. They will make it an "option," naturally. Like picking your default search provider when you start Chrome for the first time.
FWIW, that would require a drastic rearchitecture of the existing Internet, and thereby seems quite unlikely: most performance-oriented infrastructure is based on being able to approximate the latency to and location of a user based on the origin of their DNS queries, allowing you to direct people to highly localized servers for the actual content; this is how all the major CDNs, such as Akamai, work. When you start using Google's DNS servers the Internet gets a lot slower (and it isn't just a couple hundred milliseconds of latency-to-start: it can mean minutes or hours of time-to-completion when you end up streaming large files and videos from the wrong places... the bandwidth difference can be massive).
I'm neither a Google employee, nor can I speak for the team that runs Google's public DNS servers, but I'd be surprised if that team didn't consider "using Google's DNS servers [causes] the Internet [to get] a lot slower" to be a major bug. 8.8.8.8 and 8.8.4.4 are supposed to be anycast addresses which route to the closest server to your location. [0]
That same FAQ directly addresses this problem. They are supposedly working with the IETF on a specification solution to the problem (which will likely take forever to get good deployment of, if it even happens).
With existing infrastructure, however, the core issue is not going to be addressed unless Google has some Nyquist limit dominating ratio of DNS servers to the number of servers Akamai has (which is a very large number ;P).
As an example: I am pretty certain Akamai has nodes at the local university campus. Unless Google has a DNS server in my neighborhood (unlikely), I'm going to get streaming data from LA instead of a couple miles away.
Hmm. That FAQ entry indicates that there are far few Google DNS servers deployed than I would have expected.
Anyway I bet that there would need to deploy fewer servers to get good CDN performance than one would think.
Drop one along side the YouTube mirrors that are already in every Comcast POP. IIRC, that gets you about 20% of USian Internet users, plus those ISPs which have reasonably decent routes to Comcast's networks. Drop one at every major and medium-sized university. That oughtta give you good geographic coverage.
shrug But what do I know? Not that much, that's for sure!
It seems that you don't know what a stub resolver is.
A stub resolver is a piece of software which uses the DNS (and other) servers listed in the system configuration to resolve names to addresses. The stub resolver may use a variety of strategies when deciding which of the configured servers to use, how to time the queries, and what to cache; but stub resolvers respect the system admin's wishes WRT what name resolution servers to talk to.
There is no connection between a stub resolver as Chrome is implementing it, and the system-indicated DNS server.
This, as an aside, is what's wrong with HN. People cite RFCs or other datapoint as if it validates their point, when in fact, it does no such thing. You can run 10 stub resolvers on your system, each talking to a different DNS server. A stub simply indicates that it lacks the fortitude for full-blown root-down DNS resolution and validation. It might even still have a cache of sorts. That's it.
Firstly I'm not making a point, I'm giving you information that your vague hand-wavy rant seems to indicate that you don't have. Secondly, I point to the RFCs to indicate that my description of stub resolvers isn't just my opinion, but is somewhat in line with the community definition.
I never said that one could not have multiple stub resolvers installed on a single system. I also never intended to imply this. There's no reason to believe that the Chromium stub resolver will do anything but intelligent caching and fetching. Certainly, there's nothing in the linked Google Plus post to make me believe otherwise. Mr. Chan mentions that writing a browser-specific stub resolver is really the wrong thing to do, but it's something that they really need to do to get their target DNS query performance and to detect and work around certain kinds of really shitty breakage.
Why did you get downvoted? Perhaps because you said
I like how they mask very crystal-clear strategy...
when the strategy is anything but clear to anyone but you. By way of explanation, you point to a multi-page article about you and OpenDNS in which -among many other things- you say "[Google has] a separate privacy policy for Google DNS, and I’m sure they are hypersensitive about privacy concerns, so I wouldn’t be too paranoid [about the possibility of DNS query logging and data mining].". I'm not sure what strategy it is that you're worked up about, but it would be really nice if you'd come out and say it, rather than being all oblique and mysterious.
Additionally, it would seem that you're the CEO or President or something of OpenDNS? It's exceedingly poor form to say vague FUDdy smelling things about companies that compete with your core business. If you're going to say something, man up and say it; don't make others feel around to maybe discover a hint of what your point was.
21 comments
[ 4.9 ms ] story [ 57.9 ms ] threadIs it really endlessly redirecting or perhaps timing out and trying to reload? I had that happen once when latency was extreme, on one occasion.
EDIT: here is the text for those who are having trouble.
Host resolution accounts for a significant portion of the networking component of page load time. As such, Chromium developers are always looking to optimize it. Here I present the current considerations of host resolution in Chromium, and look forward to the IPv4+IPv6 dual stack world and what that entails for browsers (and what Chromium is doing about it). I finish off with a presentation of some of the latest data we're operating on.
Currently, Chromium uses getaddrinfo() to ask the OS to resolve a host. This is a cross-platform, blocking API that abstracts the complicated host resolution. There are a number of advantages to using this API: * Correctness - it handles all the complicated rules of hostname lookup correctly. It understands /etc/hosts, non-DNS namespaces like NetBIOS/WINS, etc. Re-implementing this behavior would be difficult. * OS Caching - we get to share the OS host cache with other applications. Note that this doesn't exist by default on Linux systems. * Less code - Having to maintain code sucks. It leads to code/binary bloat and endless bugs for corner cases and OS-specific issues. And it takes engineering time.
There are many disadvantages to using this API: * Blocking - we need to use unjoined worker threads so we don't block critical threads * Performance - we can't optimize the host resolution process, since it's behind the getaddrinfo() call. There are lots of optimization opportunities we miss. * Application caching - we can't tell how long to cache a DNS record for in the application, since we don't get TTLs from getaddrinfo(). We try to be safe by only caching for a minute.
As noted previously, host resolution is a substantial portion of networking time, so we try to start it as soon as possible. Our network predictor subsystem learns to predict network requests and may initiate host resolution prefetches. While this provides substantial performance benefits, it also can lead to horrible user experience when it overloads upstream resolvers/devices. For example, check out https://code.google.com/p/chromium/issues/detail?id=3041 and https://code.google.com/p/chromium/issues/detail?id=12754, where users report "internet loss" that seems correlated to DNS prefetching. The problem is that Chromium is issuing too many DNS queries in a short period of time, which may overload upstream devices (typically cheap NAT routers) which then enter a anti-DoS mode and ignore DNS queries for a period of time. Due to excessively high getaddrinfo() failure timeouts varying by platform, this results in Chromium appearing to "hang" while displaying "Resolving host…" in the status bar. Our first step to combat this was setting limits on the number of outstanding getaddrinfo() calls. Currently, the limit is 8. However, it's still possible to overload upstream devices. Worse, when that happens, now we have this limit of 8 jobs, so even if we cancel the navigations and wait a short while for the NAT router to exit its anti-DoS mode and then try to browse to other pages, we can't issue anymore host resolutions until one of the 8 getaddrinfo() calls timeout. We identified this problem in http://code.google.com/p/chromium/issues/detail?id=73327 and implemented back off behavior to recover from this situation. The important thing to note though is that we are somewhat limited by existing network devices in the degree to which we can aggressively do DNS lookups for performance reasons.
Prior to last year's Wor...
Unsurprisingly, since deleting my account I've had no reason to regret that decision and have enjoyed the complete lack of notification spam.
Disables IPv6 interfaces.
-IPv6 adoption is too low!!
My prediction from 2 years ago + and again a couple weeks ago rings true now: http://www.forbes.com/sites/eliseackerman/2012/02/25/a-close...
"I’ll reiterate my view that I think Google controlling search, the browser, and the network or DNS layer is a dangerous trifecta that the consumer will probably be best served avoiding. I’m sure we’ll find out soon enough."
To try and guess your objection (please correct me if I'm misreading), this worries you because it would make it simpler for Chrome to default to using Google's DNS rather than the OS setting?
That's an interesting objection, and one I'd like to see discussed here. If that was your point I kinda wish you'd just said it rather than hinting darkly and linking to a couple page long article.
(disclaimer: I work at Google and care a lot about its soul/ethics. I do not speak for Google. Also, I'm a low-level engineer on stuff completely unrelated to Chrome/ DNS/etc.)
[0] https://code.google.com/speed/public-dns/faq.html#anycast
With existing infrastructure, however, the core issue is not going to be addressed unless Google has some Nyquist limit dominating ratio of DNS servers to the number of servers Akamai has (which is a very large number ;P).
As an example: I am pretty certain Akamai has nodes at the local university campus. Unless Google has a DNS server in my neighborhood (unlikely), I'm going to get streaming data from LA instead of a couple miles away.
http://code.google.com/speed/public-dns/faq.html#cdn
Anyway I bet that there would need to deploy fewer servers to get good CDN performance than one would think.
Drop one along side the YouTube mirrors that are already in every Comcast POP. IIRC, that gets you about 20% of USian Internet users, plus those ISPs which have reasonably decent routes to Comcast's networks. Drop one at every major and medium-sized university. That oughtta give you good geographic coverage.
shrug But what do I know? Not that much, that's for sure!
A stub resolver is a piece of software which uses the DNS (and other) servers listed in the system configuration to resolve names to addresses. The stub resolver may use a variety of strategies when deciding which of the configured servers to use, how to time the queries, and what to cache; but stub resolvers respect the system admin's wishes WRT what name resolution servers to talk to.
See: https://tools.ietf.org/html/rfc1123#page-74 and: https://tools.ietf.org/html/rfc4033#section-7
This, as an aside, is what's wrong with HN. People cite RFCs or other datapoint as if it validates their point, when in fact, it does no such thing. You can run 10 stub resolvers on your system, each talking to a different DNS server. A stub simply indicates that it lacks the fortitude for full-blown root-down DNS resolution and validation. It might even still have a cache of sorts. That's it.
Why my post got marked down, I'll never know.
I never said that one could not have multiple stub resolvers installed on a single system. I also never intended to imply this. There's no reason to believe that the Chromium stub resolver will do anything but intelligent caching and fetching. Certainly, there's nothing in the linked Google Plus post to make me believe otherwise. Mr. Chan mentions that writing a browser-specific stub resolver is really the wrong thing to do, but it's something that they really need to do to get their target DNS query performance and to detect and work around certain kinds of really shitty breakage.
Why did you get downvoted? Perhaps because you said
I like how they mask very crystal-clear strategy...
when the strategy is anything but clear to anyone but you. By way of explanation, you point to a multi-page article about you and OpenDNS in which -among many other things- you say "[Google has] a separate privacy policy for Google DNS, and I’m sure they are hypersensitive about privacy concerns, so I wouldn’t be too paranoid [about the possibility of DNS query logging and data mining].". I'm not sure what strategy it is that you're worked up about, but it would be really nice if you'd come out and say it, rather than being all oblique and mysterious.
Additionally, it would seem that you're the CEO or President or something of OpenDNS? It's exceedingly poor form to say vague FUDdy smelling things about companies that compete with your core business. If you're going to say something, man up and say it; don't make others feel around to maybe discover a hint of what your point was.