Slashdot Mirror


Google and OpenDNS Work On Global Internet Speedup

Many users have written in with news of Google and OpenDNS working together on The Global Internet Speedup Initiative. They've reworked their DNS servers so that they forward the first three octets of your IP address to the target web service. The service then uses your geolocation data to make sure that the resource you’ve requested is delivered by a local cache. From the article: "In the case of Google and other big CDNs, there can be dozens of these local caches all around the world, and using a local cache can improve latency and throughput by a huge margin. If you have a 10 or 20Mbps connection, and yet a download is crawling along at just a few hundred kilobytes, this is generally because you are downloading from an international source (downloading software or drivers from a Taiwanese site is a good example). Using a local cache reduces the strain on international connections, but it also makes better use of national networks which are both lower-latency and higher-capacity."

151 comments

  1. Re:New GNAA President paz is Elected by Anonymous Coward · · Score: 0

    Why does the GNAA website have a .eu domain name?

  2. only a few 100 KBs, WTF?!? by Anonymous Coward · · Score: 0

    I never get my downloads that slow when downloading from Taiwan...

    Oh ya, that's right, I am in Taiwan...

  3. Akamai by Anonymous Coward · · Score: 1

    Akamai has been doing this the proper way for years now.
    I prefer this is implemented by the content provider, not by the ISP

    1. Re:Akamai by PPH · · Score: 1

      If I understand TFS correctly (and sometimes I don't), it is the target web service that is selecting the local cache for you based on your IP address. So that shouldn't be a problem. Now, if OpenDNS selects it, there could be a trust problem (someone could hijack OpenDNS or they could turn evil). But that's not how I read the description.

      What I'm not understanding is the speedup part. When I open an HTTP connection to some web service, they should already have 'my' IP address (issues of NAT, tunneling, TOR exits, etc. notwithstanding). So, why the extra step?

      --
      Have gnu, will travel.
  4. P2P by anonymousNR · · Score: 1

    How is this different from P2P ?

    --
    -- It is the mark of an educated mind to be able to entertain a thought without accepting it. -- Aristotle
    1. Re:P2P by Anonymous Coward · · Score: 0

      Well, P2P is a network of clients that act on equal footing (hence, "peer"), that transfer data amongst each other (hence the "2"). This is a bunch of severs, clients, and intermediating DNS servers routing clients to more local hosts. Basically everything is different from P2P.

    2. Re:P2P by alfredos · · Score: 2

      Very. It's content delivery in real time, latency optimized, what this is about. P2P, using residential low-speed links and desktop computers, is simply not suited for the task.

      What is not is new. Distributed content caches were all the rage at the end of last millennia - everybody remembers about Squid, I guess? - and DNS geo load balancing (including fancy boxes with large price tags), and all that stuff. Ever fatter pipes have always reduced the need for this sort of solutions and my guess is that it will continue to be the case.

      Multicast is another example of a technology that was created to improve content delivery, basically for audio and video. Almost nobody uses it. Instead, CDNs distribute unicast feeds globally. It was also a good idea, but it required a ton of resources and a different thinking than traditional routing.

    3. Re:P2P by Aqualung812 · · Score: 2

      Ever fatter pipes have always reduced the need for this sort of solutions and my guess is that it will continue to be the case.

      That would be correct if ISPs were upgrading their big lines at the same rate they're upgrading their customer facing lines.

      Unfortunately, they're letting their peering lines get oversubscribed, but selling space to CDNs.

      --
      Grammer Nazis - I mod you "troll" unless you actually add something on-topic. Yes, I know I have mispellings in my sig.
    4. Re:P2P by EdZ · · Score: 1

      Just like the flip-flopping between THIN CLIENTS ARE THE SOLUTION! and ALL POWER TO THE WORKSTATIONS! every few years - at the moment, we're in a thin-clients + remote server phase ('the cloud') - there's a general flip-flopping between localised caching when the content served grows larger than the available bandwidth (the current case with streaming video) and once more bandwidth comes online the content servers become centralised again.

      Such is the circle of life!

    5. Re:P2P by m50d · · Score: 1

      IIRC the main problem with multicast was it required all the routers in between to support it, and why would you upgrade something that was already working. Maybe with IPv6 we'll get working multicast, since that requires replacing/upgrading all your routers anyway.

      --
      I am trolling
    6. Re:P2P by Anonymous Coward · · Score: 0

      If you have a 20Mbps connection or better, you'll frequently run into this if you don't live in the same timezone as the server you access. On the west coast, the best you get from NYC, and Montreal is about 1Mbit. The reason is MTU and Latency. California to New York is 75ms at the minimum. Very basic math tells you that 1000ms/latency in ms = maximum bandwidth under ideal conditions. East to West is 75ms, so you end up with maybe 7Mbps. Even if you have a 100Mbps FiOS.

      You can't do anything about the speed of light, but you can make the channel wider. 1500MTU Fast Ethernet vs 9KB MTU GigE.

      P2P mitigates the problem for fixed assets as long as there are peers in your immediate area, otherwise your p2p client will pull the data from any/all available peers, so it's not latency aware, and the entire reason ISP's have to throttle it is because of this behavior. If a properly seeded file had 1 peer in every major city, it would still pull all the neighboring cities peers. The reason you can max out the bandwidth is because you're connecting to enough peers. If all the peers were on the east coast and you're on the west coast, you need 10 times as many peers.

      CDN's work from the other side of the equation, there are machines located in data centers in major transit hubs (San Francisco, New York, Tokyo, London, etc) or even colocated at the ISP's. So instead of trying to connect to 20 machines 1000 miles away to pull 100Mbps, you only need to connect to 1 machine that is less than 5 miles away. CDN's however generally aren't configured to deliver files in pieces unless it's streaming video. So you do typically end up stuck always having to download the file from the beginning since you didn't connect to the same CDN server you did last time.

      A hybrid approach requires some kind of HTTP-TorrentCDN system where (similar to napster) there are servers that have the most requested content and cycle through backends and files users already have (peers) that are in the same geolocation sector. This solves numerous problems.
      - No more MPAA/RIAA/ESA/etc piracy issues, since the CDN servers only mirror content they've been told to mirror, files can be made to disappear by simply having the source host purge the file.
      - No more privacy invasion, since you might download a file from CDN-Montreal, but the content's home machine is located in NYC, home ISP will only see the CDN's IP address.
      - No more "plz seed" issue since the host and CDN will always have the file available
      - No more "speed sux" since any file that is too popular for the CDN to deliver will make use of peers with incomplete parts of the file to fill in the pieces for each other.

      The trade off's are also fairly dire too
      - High latency on small files, this works for large files (movies, music, flash cartoons, etc) but most sites consist of dozens of tiny files that would be delayed significantly. The current practice with CDN use is to direct small images to the same host (so that the connection isn't torn down,) and larger files to separate machines.
      - MITM attacks
      - Advertising revenue based sites are harmed by having peers connect without seeing the ads. And this is why it will never take off.

    7. Re:P2P by Aqualung812 · · Score: 2

      No, the problem with multicast is that the big providers wanted more money based on bandwidth & multicast would severely cut bandwidth need.

      As you can see with AT&T and Comcast, they already use multicast internally, as do almost all video over IP providers. They just don't want to share it.

      --
      Grammer Nazis - I mod you "troll" unless you actually add something on-topic. Yes, I know I have mispellings in my sig.
    8. Re:P2P by nschubach · · Score: 2

      I always thought multicast meant that you'd have to be downloading the same bits as everyone else at the exact same time so you'd have to sit around and wait for a multicast session to open up to start receiving your data. It would be great for broadcast television where everyone tunes in to a specific channel to get what they want, but it would be fairly useless if someone connected 5 minutes after the multicast started unless the data packet they were receiving supported the ability to pick up 5 minutes in. You'd still not have the first 5 minutes of the broadcast though.

      It's great for local networks where you need to transfer large amounts of data to large amounts of PCs, but they all have to coordinate to get the entire package.

      --
      Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
    9. Re:P2P by alfredos · · Score: 1

      Your first statement is true. As for IPv6, I don't see IPv6 as making a case for multicast globally, perhaps unfortunately. Even the contrary may be true: Since deploying IPv6 costs large sums of money, multicast will have to wait. Also, multicast and IPv6 have little in common that can create synergies; it's not as if IPv6 brought by design a multicast proposal that was radically more convenient than with IPv4.

    10. Re:P2P by lennier · · Score: 2

      Ever fatter pipes in North America have always reduced the need for this sort of solutions and my guess is that it will continue to be the case.

      Fixed that for you. The rest of the world, not so much, and we grind our teeth at having to use American web apps because they're sloppy bandwidth hogs just like American cars are petrol hogs. Caching is a good thing. Pity AJAX seems practically engineered to break caching as its primary purpose.

      --
      You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
    11. Re:P2P by walshy007 · · Score: 1

      there's this thing.. called tcp window size, with more latency you can simply up the window size to a point where the latency doesn't limit speed, mtu while effecting things does not do so in the way you say.

  5. Re:New GNAA President paz is Elected by bonch · · Score: 2

    Looks like someone forgot to check the little box marked "Post Anonymously."

  6. Little brother by lucm · · Score: 2

    > The service then uses your geolocation data to make sure that the resource you’ve requested is delivered by a local cache

    This will make censorship much easier. No more corrupt foreign data in [your favorite oppressive country].

    --
    lucm, indeed.
    1. Re:Little brother by Bucky24 · · Score: 1

      Heh, before I even got to the comments I thought "I know someone is gonna talk about how this makes it easier for privacy violations". Not to say that you're wrong though....

      --
      All the world's a CPU, and all the men and women merely AI agents
    2. Re:Little brother by vlm · · Score: 1

      > The service then uses your geolocation data to make sure that the resource you’ve requested is delivered by a local cache

      This will make censorship much easier. No more corrupt foreign data in [your favorite oppressive country].

      If my assumption is correct that they're basically using cnames to generate geo-locatable new host names, you could just distribute the knowledge than in Afghanistan / GB / GER, you simply need to visit 4.4.4.youtube.com to gain "usa" access to youtube.

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    3. Re:Little brother by Catnaps · · Score: 1

      What? It makes it easier to avoid censorship. Remind yourself of what Google did with China and the .hk redirect.

    4. Re:Little brother by MatthiasF · · Score: 2

      Makes it almost impossible to remain anonymous by proxy or Tor if you use the service, or if DNS servers start to enforce the behavior Google is suggesting in their IETF brief.

      Seems like when you do a DNS lookup, your octets get sent by yourself or the proxy, and then Google and friends see's a request for that domain in Analytics or what not from the proxy. Not going to take much to attach one piece of information to the other, or pull together patterns from Analytics from the DNS responses for the proxy to guess which requests are to particular guestimated individuals. Add on Adsense and you're even more screwed.

      Anyway, I'm dropping OpenDNS at home because of this. I don't agree that it's necessary and can be more harmful than helpful. I'm not worried about a download completing faster so much as someone having a dossier on me hidden away on some server.

      OpenDNS was nice to use as a layer of avoiding malware but it's usefulness disappears when it starts doing stuff I don't appreciate.

    5. Re:Little brother by Anonymous Coward · · Score: 0

      Why not just drop analytics and adsense instead? You have a /etc/hosts file, so use it.

    6. Re:Little brother by jc79 · · Score: 1

      Tor proxies DNS requests, so from behind a Tor tunnel, you appear to be the exit node. I don't see how this will change, as the exit node's Tor server is the entity making the DNS request on your behalf. All that'll happen is that you're more likely to end up with content coming from a CDN cache nearer to the exit node than before.

      As to google x-referencing DNS queries with Analytics etc - if you're after anonymity, why are you allowing google analytics/adsense in the first place? Privoxy and polipo can be configured to block any requests to these domains, and you really ought to be browsing via Tor with Javascript disabled anyway, to mitigate against evil exit nodes injecting malicious scripts into pages they fetch for you.

  7. Re:New GNAA President paz is Elected by royallthefourth · · Score: 1

    If you had read it, you would understand that his post is the second step in applying for GNAA membership.

  8. Re:New GNAA President paz is Elected by Anonymous Coward · · Score: 0

    Doesn't say anything about posting it under a registered username.

  9. Ehh.... this is ok, but .... by King_TJ · · Score: 2, Interesting

    Isn't this little more than an expensive band-aid for the underlying bandwidth problem? Delivering content from strategically located caches is an OLD concept, and it's always been trouble-prone, with some sites not receiving updated content in a timely manner and others getting corrupted.

    Quite frankly, I wish some of the big players with vested commercial interests in a good-performing internet (like Google, Amazon, or Microsoft) would pitch in on some investment funding to upgrade the infrastructure itself. I know Google has experimented with it on a small scale, running fiber to the door in a few U.S. cities. But I'm talking about thinking MUCH bigger. Fund a non-profit initiative that installs trans-Atlantic cables and maintains them, perhaps? If a nation wants to censor/control things, perhaps they'd reject such a thing coming to their country, but that's ok.... their loss. Done properly, I can see it guaranteeing a more open and accessible internet for all the participants (since presumably, use of such circuits, funded by a non-profit, would include stipulations that the connections would NOT get shut off or tampered with by government).

  10. That's network neutrality for you by Anonymous Coward · · Score: 1

    A network where only big players can afford fast delivery is not neutral. CDNs starve the actual network in favor of local caches. Money that would have to go to bandwidth improvements now goes to the CDNs, which in turn are only used by global players. This leaves us with an anemic network that can deliver Youtube clips quickly but chokes on broadband communication between individuals on different continents. And if that weren't bad enough, they abuse DNS to do it.

    If I type google.com into my browser, I actually want to get an english web page from a computer in the USA, not a redirect to a page in the language of my country, and not a page served by a computer in my country either.

  11. Cache poisoning in 3.. 2.. 1.. by kheldan · · Score: 1

    Sorry, I may just have woke up on the wrong side of the bed this morning.. but wouldn't doing as TFA suggests just open the door to another MITM attack method?

    --
    Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
    1. Re:Cache poisoning in 3.. 2.. 1.. by Em+Adespoton · · Score: 1

      Not really... but it would provide another Man-on-the-end attack method, where the owner of the DNS gets much more information and control regarding the endpoint. Someone who has a malicious DNS host would have much more control over how to direct traffic based on geolocation before you even reach their server. People from a specific location could be routed via a middleman to sniff/poison the data via this method.

      A man in the middle already knows your entire IP, so they gain pretty much nothing here that they didn't already have.

      So: possible attack: someone registers, say, www.facebook.co and runs the DNS. When people from Iran attempt to connect, the IP returned is for a proxy used to sniff/poison the connection, and the person is apparently redirected to www.facebook.com. When anyone else attempts to connect, the DNS passes the request to Facebook's DNS for a lookup on www.facebook.com. As a result, anyone outside of Iran investigating this fishy domain will get an apparantly standard connection to facebook, with the only warning bell being that facebook.co is registered to another entity.

    2. Re:Cache poisoning in 3.. 2.. 1.. by Em+Adespoton · · Score: 1

      An added bonus for DNS providers is that they get a bit more telemetry on where lookups for domains are coming from.

  12. Nice euphemism by Anonymous Coward · · Score: 0

    "downloading [drivers] from an international source"

    So that's what you kids are calling it these days. Heh.

  13. Yes we are saving by onepoint · · Score: 1

    What I like about this entire thing is that we can save on bandwidth, which should also lead to some power savings overall, not a lot, but just another drop, those drops could add up and become something useful in the future.

    --
    if you see me, smile and say hello.
  14. For IPv4? by jfengel · · Score: 1

    I realize that IPv4 is going to be with us for quite some time, but is this going to be worth the effort? It requires a bit of jiggery-pokery to repoint your DNS, the kind of thing that appeals to the Slashdot crowd but which your grandma will never, ever pull off. ISPs could help, but will they do so before IPv6 makes it irrelevant?

    1. Re:For IPv4? by vlm · · Score: 1

      I realize that IPv4 is going to be with us for quite some time, but is this going to be worth the effort? It requires a bit of jiggery-pokery to repoint your DNS, the kind of thing that appeals to the Slashdot crowd but which your grandma will never, ever pull off. ISPs could help, but will they do so before IPv6 makes it irrelevant?

      Its done on their side. I'm reading between the lines and trying to unfilter the dumbed down journalist-speak, but I think I could implement the same thing by configuring about 16 million bind "views" for each of a.b.c in the source ip address range a.b.c."whatever". Then bind gives a different cname for the domain inside each view, like if my src addrs is 1.2.3.4 then their bind server barfs out a cname of 3.2.1.www.whatever.com whenever someone asks for www.whatever.com and some other sorta thingy decides where each of the 16 million c.b.a.www.whatever.com domains resolves to geographically, perhaps even somewhat automatically.

      With ipv6 its somewhat simpler, if you (ISP) get a /40 or /32 or whatever, thats probably all you'll ever get. So you don't need to map out individual end user /64s, at least hopefully/probably not.

      The problem with caching is random access drive speed etc has not been increasing as fast as bandwidth used. So where a slightly tuned up desktop made a decent tolerable usable cache around 2000, around 2010 to make the cache better than directly access, you need monsterous gear and complicated setups. Rapidly it becomes cheaper to buy more bandwidth.

      The standard /. car analogy is much like the simplest cheapest and most reliable way to get 1000 horsepower is to buy a 1000 HP engine, not to fancy up a stock 100 HP civic engine. Or a better analogy might be if you wanna drive your car 400 miles across the desert, its probably a hell of a lot better engineering to install a 400 mile equivalent aux fuel cell/tank, than to deploy multiple "just-in-time" fuel caches using autonomously guided GPS equipped saturn 5 rockets along the route, although either technically would work, and the saturn 5 deployment would be very exciting and photogenic.

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    2. Re:For IPv4? by LDAPMAN · · Score: 1

      "The problem with caching is random access drive speed etc has not been increasing as fast as bandwidth used. So where a slightly tuned up desktop made a decent tolerable usable cache around 2000, around 2010 to make the cache better than directly access, you need monsterous gear and complicated setups. Rapidly it becomes cheaper to buy more bandwidth."

      Modern caching systems primarily return data from memory, not from disk. Even if you were to pull the data from disk, the disk is normally an order of magnitude faster than the internet connection.

    3. Re:For IPv4? by unixisc · · Score: 1

      I realize that IPv4 is going to be with us for quite some time, but is this going to be worth the effort? It requires a bit of jiggery-pokery to repoint your DNS, the kind of thing that appeals to the Slashdot crowd but which your grandma will never, ever pull off. ISPs could help, but will they do so before IPv6 makes it irrelevant?

      The same thought occured to me. What's more, IPv4 has different classes of addresses, so for class A addresses, the DNS servers need forward only the first octet, for class B addresses, only the first 2 and class C addresses, all 3. However, what makes this a questionable mechanism is the variable length subnetting that IPv4 uses - you could have a class A address i.e. something from 1.x.x.x to 126.x.x.x, but one that is subnetted to be /26, for instance, in which case, the DNS servers forwarding only the first 3 octets won't do much.

      Besides, IPv4 was never really distributed along geography lines - they were assigned on a first come first serve basis, which is why if you look @ IANA and which addresses are assigned to which RIR, it's simply a look-up table.

      IPv6, otoh, has had various blocks already assigned to RIRs. This helps quite a bit, and if the RIRs have a decoder ring for the first byte in their ranges to be marked for the countries in their group, that would help geographic location determination on the basis of the first 3 bytes of the address down to country. Then search within DNS servers in that area.

      This wouldn't be the final word, however, since it's possible for an American company to get, say, a /48 block from ARIN, and assign some of its subnets to its offshore branches, like, say, the Philippines. So if a company registers that way, the address normally would mention the US as the location it's to be found in, but within the address, one may find certain subnets assigned to offshore companies, so that they are within the same network. In which case, DNS servers in the Philippines would have to include the ARIN assigned addresses in their lists.

    4. Re:For IPv4? by CTachyon · · Score: 1

      I realize that IPv4 is going to be with us for quite some time, but is this going to be worth the effort? It requires a bit of jiggery-pokery to repoint your DNS, the kind of thing that appeals to the Slashdot crowd but which your grandma will never, ever pull off. ISPs could help, but will they do so before IPv6 makes it irrelevant?

      It's described in IPv4 terms, but extending it to work with IPv6 addresses should be simple enough. The trickiest part will be finding the golden CIDR mask to replace IPv4 /24. Giving up /64 is too much, since it identifies most ISP customers uniquely, and /48 has similar issues. Probably something near /32 or /40 would be appropriate, although you could probably do a lot with as little as /20.

      Other than that, the described technique is still fully relevant because IPv6 doesn't change the game in any other way: DNS still works the same way, HTTP still works the same way, and websites are still slow for the same reasons, so you have the same incentives for regional caching and the same choices in how to do it.

      --
      Range Voting: preference intensity matters
  15. Akami? by vlm · · Score: 2

    Description seems a little simplified. Sounds like an Akami presentation from over a decade ago.

    So is this a commercial competitor to Akami, or a non-commercial competitor, or a freeware / public competitor, or is it something somewhat different, like a squid proxy set up for transparent caching from 2002 or so?

    Speaking of squid, its 2011, is squid ever gonna support ipv6? There's not much software out there that doesn't support v6, and squid is probably the most famous.

    --
    "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    1. Re:Akami? by Binary+Boy · · Score: 4, Informative

      Speaking of squid, its 2011, is squid ever gonna support ipv6? There's not much software out there that doesn't support v6, and squid is probably the most famous.

      http://wiki.squid-cache.org/Features/IPv6

    2. Re:Akami? by lurp · · Score: 3, Informative

      None of the above. It's a scheme to pass your IP address to CDNs such as akamai so that they can select an edge server that's closer to you. Absent this, CDNs select an edge server closest to your DNS provider — that's fine if you're using your ISP's DNS, but in the case of an OpenDNS or Google Public DNS, that's likely a poor choice.

    3. Re:Akami? by Anonymous Coward · · Score: 1

      Yeah.... http://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=squid3

      How's that thing called google getting along for you?

    4. Re:Akami? by x3dfxjunkie · · Score: 1

      Speaking of squid, its 2011, is squid ever gonna support ipv6? There's not much software out there that doesn't support v6, and squid is probably the most famous.

      Hell, I'd be happy if it used HTTP 1.1! It's only been a standard since June 1999.

    5. Re:Akami? by Anonymous Coward · · Score: 0

      Oh... I see

      Actually, you don't seem to see much. Squid3 3.1 has only been available since the end of March 2010

    6. Re:Akami? by oobayly · · Score: 1

      Asterisk?

    7. Re:Akami? by Anonymous Coward · · Score: 0

      http://lmgtfy.com/?q=how+to+compile+squid

      Squid is one of the easier ones to compile and install...

    8. Re:Akami? by Anonymous Coward · · Score: 0

      perhaps you missed this:
      http://packages.debian.org/squeeze/squid3

    9. Re:Akami? by Anonymous Coward · · Score: 0

      It's Squid's fault Debian hasn't included the latest and greatest?
      Mosey on over here to http://www.squid-cache.org/Versions/v3/3.1/ instead.

    10. Re:Akami? by complete+loony · · Score: 1
      Here's how I'm reading this.

      So google already have local caches, and respond to DNS queries with your local cache's IP address. Just like Akami and other content networks do.

      But some global DNS services like OpenDNS will do the lookup once, getting an IP for a cache that is local to their service, and return that IP address to all users.

      So google and OpenDNS came up with a DNA protocol extension so that end users get the right address.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    11. Re:Akami? by thegarbz · · Score: 1

      So is this a commercial competitor to Akami, or a non-commercial competitor, or a freeware / public competitor, or is it something somewhat different, like a squid proxy set up for transparent caching from 2002 or so?

      Neither. Services like Akami rely on the IP address of the request to deliver the data from the closest point. This is fine if you use your local city's local ISP's DNS server as Akami will see the IP address of your city correctly and send you to the correct server. However this is quite problematic if you use 8.8.8.8 or OpenDNS as your primary DNS provider because in the past there has been no way to determine from the request *where* you are located. Akami would deliver the request any request to a user of Google's DNS server from their servers closest to California, despite the end user potentially being located half way around the world right next to their datacentre.

      This proposal works on forwarding the relevant part of the IP address required for location lookup up the DNS chain, so that when I want to download something hosted by Akami, OpenDNS or Google's DNS servers will pass my IP address to Akami's DNS server and they will in turn resolve the request to an IP address in Australia rather than California.

    12. Re:Akami? by Stupendoussteve · · Score: 1

      No, it's not. All they have done is fixed their DNS so things like Akamai (and Google's own distributed system) can function as designed.

      In the past if you switched over to Google's DNS or OpenDNS, you ended up with a slower Internet experience in some ways, as the CDNs would send data from the node located closest to the DNS server, rather than the client. If you were a user in Europe, you might very well be receiving a YouTube stream from within the US. This has changed, as the CDN can tell the location of the client apart from the DNS server the client is using and use the appropriate frontend.

      None of this has been an issue for the normal ISP-provided DNS users.

      Also of note is Akamai is not supported at the moment, so a large chunk of the CDN traffic is still broken. Also, Google's own DNS benchmarker, namebench, often shows better performance from ISP servers than OpenDNS or Google's, simply due to the location. If an ISP server is not misbehaving by hijacking typos and such, there isn't too much reason to switch (that I can see).

  16. Network-topology-aware round-robin DNS by tepples · · Score: 2

    When I open an HTTP connection to some web service, they should already have 'my' IP address

    By the time you make an HTTP connection, you've already chosen which mirror of the web service to use. According to the article, this spec would allow DNS servers, such as an ISP's DNS server resolving on behalf of the ISP's customers, to use the prefix of each user to determine which mirror to recommend. It's like a network-topology-aware version of round-robin DNS.

    1. Re:Network-topology-aware round-robin DNS by petteyg359 · · Score: 1

      By the time you make an HTTP connection, you've already chosen which mirror of the web service to use.

      Wrong. There are many requests and responses made in any transaction, and HTTP has support for this strange thing called "redirect". Even if your first connection is to a server in Djibouti, you may be redirected to a server in Canada, and then that one may again redirect you to a server in Sweden, where you'll finally be given the resource you requested.

    2. Re:Network-topology-aware round-robin DNS by NatasRevol · · Score: 1

      Which means EVERY http server has to be set up like that.

      Here, google's DNS & openDNS is set up like that & it servers millions of users. Which is slightly more effective AND efficient.

      --
      There are two types of people in the world: Those who crave closure
    3. Re:Network-topology-aware round-robin DNS by DavidTC · · Score: 2

      No, this isn't for ISP DNS, which baffled me at first also. ISP DNS servers almost always use the same 'outgoing path' as your traffic, and hence get handed the same mirror that you yourself would have been handed.

      In fact, this often gives better results than 'correct' geolocation, as DNS servers are usually closer to the network boundary. If the geolocation shows I'm in Tennessee, they might direct me to a mirror in Nashville...but what if my ISP actually connects to the internet via Atlanta, and now instead I'm going from Tennesse to Atlanta back to Nashville? However, the ISPs DNS server are likely to be in Atlanta, as they are usually right at the internet connection, so if they ask for the DNS, they get the Atlanta mirror.

      That's not what this article is talking about. This article is talking about the opposite problem, for things like OpenDNS or google DNS, where the DNS server will be somewhere else entirely from the user. Google has DNS servers...and they're in one location, not at your ISP. Everyone who currently uses them gets sent to the closest mirror to that DNS server, which is clearly stupid.

      That said, as almost everyone uses their ISPs DNS, calling this a 'global internet speedup' is pretty silly. It's a speedup for the few nerds who use OpenDNS or Google DNS.

      --
      If corporations are people, aren't stockholders guilty of slavery?
    4. Re:Network-topology-aware round-robin DNS by Score+Whore · · Score: 3, Funny

      You aren't understanding what is going on here. All Google and OpenDNS are doing is providing the authoritative DNS server with the IP address of the client. Google/OpenDNS know nothing about any possible caching or local servers. They are just making it possible for the final DNS server to possibly, assuming that whoever owns the domain you are resolving supports some kind of CDN, send you to a nearby server.

      What likely really happened here is this:

      Akami: Hey Google! You're compulsion to violate everyone's privacy is fucking up the Internet by breaking all of the CDN/Geo-based services.
      Google: But... but... we must know everything about everyone otherwise we'll not be able to sell them to our customers.
      Akami: Whatever dude, you're causing 50% congestion on the backbone links because your shit hides the actual address of the client.
      Google: Well, we've got sack-fulls of PhDs. We'll find a solution that allows us to keep spying and selling and still allows the CDNs to work.
      Akami: Look you jackasses, the system that exists today works. Your crap is just causing problems and labor for everyone else.
      Google: Na-na-na-na-na-na-na-na I can't hear you.
      Akami: Seriously. You're being a dick.
      Google: No. We've just invented this awesome thing that is going to Speed-Up! The InterNets!
      Akami: Jesus Christ! The system that was there before you broke it works. Why the fuck do you have to keep breaking shit?
      Google: Because we can and people are stupid. And we are rich. So STFU.
      Akami: Fuck. There's no reasoning with these clowns.

    5. Re:Network-topology-aware round-robin DNS by Runaway1956 · · Score: 2

      I refuse most redirects. Unless and until I examine them, redirects are pretty much dead-ends. I've not yet found such an addon for Chromium, but Firefox has had it for a long time now. Call me paranoid, but I really don't like content being downloaded to my machine from places that I've never heard of. I want all my content to come from the server on which I landed when I clicked the link. Cross site scripting is also blocked on my machine. FFS, do you have any idea what those two vectors are capable of causing? People with a clue should block all that nonsense, as part of their layered defense against malware and other exploits.

      --
      "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
    6. Re:Network-topology-aware round-robin DNS by Requiem18th · · Score: 1

      Firefox's RequestPolict.

      --
      But... the future refused to change.
    7. Re:Network-topology-aware round-robin DNS by teftin · · Score: 1

      ISPs are quite often giving their resolvers IP addresses to CDN providers for better balancing.

    8. Re:Network-topology-aware round-robin DNS by afidel · · Score: 2

      I hope this is made into an RFC and MS adopts it. We run our own primary DNS servers because AT&T has been WAY too slow to respond to security issues with their DNS resolvers and AFAIK they still don't properly handle DNSSEC requests. We tried using Google as forwarders but at least at the time they were much slower than running our own primaries (especially once cache warmed). The one drawback has been the fact that we don't always get directed to the most local server by content delivery networks (youtube is especially bad, we often can't watch an HD stream despite sitting on a mostly unused DS3). The fact that CDN's don't work correctly unless you use your ISP's DNS resolvers is not a problem of Google's making but rather of the way CDN's have chosen to design their solutions.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    9. Re:Network-topology-aware round-robin DNS by asdf7890 · · Score: 1

      I'm curious: what are Google doing to "fuck up the Internet by breaking all of the CDN/Geo-based services". So far as I know they are not doing anything to hide my network addresses, or the route between my machines and other hosts, from other servers. If they were poisoning routing tables or anything like to divert traffic through them and so hide the information other services use for geolocation, I'm sure there would have been a rather loud outcry of "we don't think that motto means what you think it means".

      (Not asking to troll or necessarily to disagree, if there is something I'd like to know what it is - it sounds like I might have missed something interesting!)

    10. Re:Network-topology-aware round-robin DNS by Score+Whore · · Score: 2

      They're not doing it to hide your address, that's just an effect of what they are doing. Google's resolvers are nowhere near the querying client. CDN and GeoIP based services are now unable to determine the nearest server based on the IP address of the resolver. Consider: If I am a customer of Xmission and I use Xmission's name servers then I will get directed to an Akamai host that is physically located in Xmission's datacenter and the content will traverse over their LAN. However if I use Google's resolver then I will get directed to an Akamai host that is near Google's resolver rather than near me. So now the content is pulled from somewhere on the otherside of the universe.

    11. Re:Network-topology-aware round-robin DNS by Meneth · · Score: 1

      Thank you. I had the same notion, but you explained it much more clearly than I could have.

    12. Re:Network-topology-aware round-robin DNS by asdf7890 · · Score: 1

      Ah, I see, I'd not thought of that. That would explain some services occasionally thinking I'm in the states, or somewhere else entirely, these days as I've started using Google's resolvers.

      Though I think it is the CDN's problem not Google's (or OpenDNS's). They've relied on a property that is not guaranteed but is commonly the case (that DNS requests come from a topologically similar place as other subsequent requests), and it is now not quite as commonly the case. As a programmer I know that if you rely on an undefined behaviour you have to accept that you will get bitten if that behaviour doesn't stay the way it once was. This will affect any DNS system were a cache in one location can share data with a cache in another rather than both pulling data from the external servers separately.

  17. Re:Ehh.... this is ok, but .... by Anonymous Coward · · Score: 0

    If a nation wants to censor/control things, perhaps they'd reject such a thing coming to their country, but that's ok.... their loss.

    You mean like, EVERY FUCKING NATION ON THE PLANET?

  18. Re:Ehh.... this is ok, but .... by MozeeToby · · Score: 1

    Quite frankly, I wish some of the big players with vested commercial interests in a good-performing internet (like Google, Amazon, or Microsoft) would pitch in on some investment funding to upgrade the infrastructure itself.

    You'd have several hundred lawsuits from several dozen companies that have a vested interest in keeping control over the existing infrastructure. You'd have antitrust investigations being called for, contract lawsuits against the cities that promised them monopoly access, and several billion dollars poured into lobbying to make sure that it cannot and will not happen.

    And keep in mind, on the low tiers the vast majority of laid fiber is dark, just waiting for someone to actually plug into it and use it. And I'd be shocked if that didn't include the transatlantic lines as well. On the higher tiers, many (most) cities don't have proper conduit installed, which means installing fiber to the front door is going to be an expensive, messy, time consuming process even if they got through the legal and bureaucratic nightmare.

  19. Re:Ehh.... this is ok, but .... by Dishevel · · Score: 0

    Getting more bandwidth to more places is great.
    Using the bandwidth you have efficiently is not a bad thing.
    Not sure how efficient use of resources is a bad thing.

    --
    Why is it so hard to only have politicians for a few years, then have them go away?
  20. conditional by shentino · · Score: 2

    I'm all for this if and only if all protocols are fully complied with.

    HTTP gives plenty of leeway and in fact was designed with caching in mind. So long as the involved parties do not violate the protocol, I'm ok with it. Cache control directives must be honored, for example. No silent injection of random crap.

    The DNS protocol must also be honored to the extent that deviations from same have not been expressly authorized. OpenDNS offers typo correction and filtering services on an opt-in basis. NXDOMAIN hijacking and whatnot is foul play.

    Just don't fuck with the protocols, and you can do whatever you want.

    1. Re:conditional by kasperd · · Score: 1

      HTTP gives plenty of leeway and in fact was designed with caching in mind. So long as the involved parties do not violate the protocol, I'm ok with it.

      This initiative is not going to be changing http at all. The client may end up at a different replica of the http service, but each of them is equally valid. The only difference is how fast you get the answer.

      The DNS protocol must also be honored to the extent that deviations from same have not been expressly authorized.

      The protocol was designed in an extensible way. If the client supports this particular extension it will send the extra information along to the server in a way that the server will simply ignore if it doesn't support the extension. If the server supports the extension and sees this extra information from the client it may pass along extra information to the client. If the client doesn't support it, then the server will never see this extra information from the client and thus not return the extra information to the client either. So if only one of the two support the extension, then everything will work out exactly the way it did before the extension was introduced. I don't know where to find the final version of the spec. I know where to find an expired draft. The protocol probably hasn't changed much since that draft. However in the draft the option code is listed as TBD, has IANA assigned an official option code for this extension?

      --

      Do you care about the security of your wireless mouse?
  21. Better idea by Lawrence_Bird · · Score: 1

    How about we get rid of all the linkages to crap sites like facebook, digg, mysapce, etc. These are the links that are almost always responsible for slow page loads for me. I rarely have any issue at all with downloads or videos, local or international. Interesting too when using noscript and some webpages literally twitch when something like facebook is blocked as they try over and over to reload and reconnect. And as others have said, these local caches are just another security risk waiting to be exploited.

  22. Alternately... by Score+Whore · · Score: 3, Insightful

    Google could just not provide a service that inserts themselves into the DNS path. The problem isn't "the internet" or DNS, it's that Google's DNS servers have no relationship to the client systems. If people were using DNS servers that had some relationship to their network -- such as the one provided by their IPS -- then this wouldn't be an issue.

    Plus not using Google's DNS gives you a little more privacy. Privacy of course being defined as not having every activity you do on the internet being logged by one of Google's many methods of invading your space (DNS, analytics, search, advertising, blogger, etc.)

    1. Re:Alternately... by mehrotra.akash · · Score: 1

      When your ISP DNS randomly redirects you to a webpage advertising their products, or typing www.google.com in the address bar leads to an ISP page with ad's and a small link to www.google.com , 8.8.8.8 does save you a lot of hassle

    2. Re:Alternately... by SuperQ · · Score: 1

      Or when ISP DNS servers are so badly managed that they take seconds to respond to lookups.

  23. Re:Ehh.... this is ok, but .... by vlm · · Score: 1

    And I'd be shocked if that didn't include the transatlantic lines as well.

    They're all lit all the time. Maybe just by second string "if we lose a strand, your strand becomes their protection ckt" but they'll be lit. I used to be in the telecom business.

    Where you find dark fiber is on shorter local hops where there simply isn't the current demand, at any reasonable cost.

    You'll never completely satisfy demand between stateside US-HI. You can supersaturate demand to the point of dark fiber between little-city and cow-village.

    --
    "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
  24. Online advertisement is to blame for a slow web. by Anonymous Coward · · Score: 1

    While this is a commendable effort, the biggest offender when it comes to horrible load times is the embedded advertising content. Most of these ad providers -- I'm looking at you Google -- deliver their content at a snails pace, delaying the delivery of the actual content.

    Case in point, I used chrome's network developers tool to analyze load time for the various elements on http://www.slashdot.org

    The top 5 longest durations go to *.doubleclick.net and range from 242 to 439ms, with the total page load time at a little under 4 seconds.

  25. Re:Ehh.... this is ok, but .... by slamb · · Score: 4, Interesting

    Isn't this little more than an expensive band-aid for the underlying bandwidth problem?

    Keep in mind that Google, Amazon, Akamai, etc. had already created geographically distributed networks to reduce latency and bandwidth. Improving the accuracy of geolocated DNS responses through a protocol extension is basically free and makes these techniques even more effective.

    Also, Google cares a lot about latency. A major component of that is backbone transit latency, and once you have enough bandwidth to avoid excessive queueing delay or packet loss, I can imagine only four ways to significantly it: invent faster-than-light communications, find a material with a lower refractive index than the optical fibers in use today, wait for fewer round trips, or reduce the distance travelled per trip. This helps with the last. Building more fiber wouldn't help with any of those and would also be a lot more expensive.

    Full disclosure: I work for Google (but not on this).

  26. Happy to answer questions by davidu · · Score: 2

    Happy to answer questions about this work.

    --

    # Hack the planet, it's important.
    1. Re:Happy to answer questions by glassware · · Score: 1

      What's the process to go about using this if I'm currently using round robin for say 10 servers? Do I need to switch to a DNS server that can obey your extra tag and select the correct closest IP?

    2. Re:Happy to answer questions by Anonymous Coward · · Score: 0

      I read the summary and don't understand.

      $ host www.example.org

      Where would a DNS server be forwarding the first three octets of my IP for this request... and why? How about this one...

      $ host -t mx example.org

      3 octets is enough to reveal to savvy miscreants, not only that that they're being investigated but in many cases, exactly who is doing it. I only read the summary but this comes over as like a crappy browser plug in idea being integrated into server code by people who don't fully understand the consequences. Tell me I'm wrong!

    3. Re:Happy to answer questions by fa2k · · Score: 1

      Hi, I asked this below, but I'll try again: How is DNS caching handled at Google's and OpenDNS's servers?

  27. Stupid workaround for stupid server code by pslam · · Score: 1

    Messing with DNS is doing it the Wrong Way. All of these CDN services are based on HTTP. When you're using them, that's an HTTP server you're talking to. It's perfectly capable of geolocating you by IP, and it can either hand you back links to a local CDN, or redirect you to another server.

    Why the hell must we mess with DNS to do this? This is a solution which only works if you use Google DNS, OpenDNS, or sometimes if you use your local ISP's DNS. What if you're just running bind for you local net vs the root servers? Bzzt. Doesn't work.

    The most insane thing about this is it's Google we're talking about here. They damn well know how to implement this entirely in their servers without resorting to DNS hacks. Why are they promoting this net-neutrality breaking, layering violating botch? We need less people to use this, not more.

    1. Re:Stupid workaround for stupid server code by KingMotley · · Score: 1

      Because it works, and there is more out there than just HTTP. This same approach will work for any protocol that uses DNS to resolve domain names. It also doesn't require a ton of server side hacks that need/should be implemented from all vendors. Easy fix, and quick to deploy requiring no end-user code/system changes. Seems like a no brainer to me.

    2. Re:Stupid workaround for stupid server code by slamb · · Score: 1

      All of these CDN services are based on HTTP. When you're using them, that's an HTTP server you're talking to. It's perfectly capable of geolocating you by IP, and it can either hand you back links to a local CDN, or redirect you to another server.

      Then it's not possible to geolocate that first HTTP request.

      What if you're just running bind for you local net vs the root servers? Bzzt. Doesn't work.

      It should work, although it may not be necessary. I see six possibilities:

      • Your local bind is configured to send queries to the authoritative servers for the domain.
        • You're using this extension: it sends along the web browser's IP address so it gets back a geolocated response for that address.
        • You're not using this extension: it doesn't send the web browser's IP address so it gets back a geolocated response for its own address. The two addresses are likely the same (or nearly so) so this distinction is irrelevant.
      • Your local bind is configured to send queries on to some other recursive DNS server. (You take advantage of their cache to reduce your DNS latency.)
        • You're using this extension and the other server relays the extra data: you get a geolocated response for your web browser.
        • You're using this extension and the other server drops the extra data: you get a geolocated response for the other server.
        • You're not using this extension and the other server adds the extra data: you get a geolocated response for your DNS server.
        • You're not using this extension and the other server doesn't add the extra data: you get a geolocated response for the other server.

      In all cases, the geolocated DNS response is at least as good as before, and in some it's an improvement, depending on how far the DNS servers are from you. If there's a latency degradation from this change, it'd be in the other recursive DNS server being slower to respond because the only cached responses it has are for different subnets. You can imagine techniques to mitigate that effect, though I haven't checked if the described work does so.

      Full disclosure: I work for Google, but not on this.

    3. Re:Stupid workaround for stupid server code by anom · · Score: 1

      If you're running bind for your local net, then you don't need this as your DNS resolver is already located close to you. The problem arises when DNS resolvers are utilized that are not "close" to the clients they serve and therefore CDN's will often end up picking a CDN replica close to your resolver rather than close to you.

      Obviously this problem grows as does the distance between you and your resolver -- if you're using a huge resolving service like Google DNS or OpenDNS, then you are much more likely to be far from your resolver. If you're using your ISP's resolver, then it could be just a few hops up the network path, or it could be across the country (as some ISP's will just use a "bank" or two of resolvers).

      This stuff is done in DNS for a variety of reasons. If you use intelligence at the HTTP layer, you:

      1. Obviously have a non-optimized initial server choice, as once you're communicating over HTTP you're already talking to a specific replica. This will likely apply for each and every new CDN-ized domain you use.

      2. You require the client to add significant intelligence to their website in order to create all the internal links to point to a "good" server. Obviously, it's going to be harder to sell your services if the client has to rewrite a bunch of code and can't just repoint their main domain at your IPs.

      3. And IMO most importantly, this removes the server selection choice from being under the sole control of the CDN provider. If this stuff is logic'd through the main HTTP page of the website, the CDN must expose its server selection strategy to the client, which is likely proprietary business knowledge. Furthermore, the server selection map is dynamic and rapidly changing based upon internet link congestion and server load, and obviously this data would have to be pushed to the client website as well. Also, if you're thinking you could just point the initial IP to a CDN-hosted HTTP server and issue HTTP redirects from there, then you've just eaten up two whole RTT's -- not a good way to speed up webpages.

      Also, to those that say this aids censorship, I'd have to call BS. A country wishing to censor its own users can easily implement a "use our dns resolvers only" policy using a simple firewall rule and watch all the traffic/rewrite dns responses anyways.

    4. Re:Stupid workaround for stupid server code by Anonymous Coward · · Score: 0

      Yes. Can anyone explain why DNS tricks are better than HTTP redirects? Is this just for the cosmetic nicety of retaining the same host/URL in the browser address bar regardless of which physical server is sending the content?

    5. Re:Stupid workaround for stupid server code by pslam · · Score: 1

      And here we have the real reason why this is being promoted:

      3. And IMO most importantly, this removes the server selection choice from being under the sole control of the CDN provider. If this stuff is logic'd through the main HTTP page of the website, the CDN must expose its server selection strategy to the client, which is likely proprietary business knowledge.

      It breaks DNS. It certainly breaks my local DNS installation, for starters. It also means that *everyone* must use this DNS hack because service will be degraded unless you do.

    6. Re:Stupid workaround for stupid server code by pslam · · Score: 1

      Because it works, and there is more out there than just HTTP. This same approach will work for any protocol that uses DNS to resolve domain names.

      Except that this is only used for HTTP. I do not know of any non-HTTP examples.

    7. Re:Stupid workaround for stupid server code by anom · · Score: 1

      "It breaks DNS" seems like a pretty strong comment to me and I'm not following how exactly it's going to do this. If you have a local DNS installation (I assume you're talking about dns /resolvers/ here?) that local machines use, there is absolutely no need for you to implement this, as any CDN basing a server selection choice on your local DNS installation will be well-guided. Your resolver won't send the applicable EDNS option, and the authoritative DNS server won't care that it's not there -- it'll just base it's choice on the resolver's IP as has happened for years.

      If you're running an authoritative DNS server, then you're not going to get the EDNS field from google/opendns because they're not going to send it to you, and if you did get it, it would only be a problem if you had a backwards DNS server that pukes on EDNS.

      How is it breaking things for you?

    8. Re:Stupid workaround for stupid server code by Anonymous Coward · · Score: 0

      FTP? Smtp? Distributed file shares? SQL server mirrors? NNTP? Ntp? I could probably list a dozen more.

    9. Re:Stupid workaround for stupid server code by pslam · · Score: 1

      FTP? Smtp? Distributed file shares? SQL server mirrors? NNTP? Ntp? I could probably list a dozen more.

      Yes, that's a list of common internet protocols. I do not know of any example of anyone actually using geolocated DNS to CDN them. Do you have a concrete example?

    10. Re:Stupid workaround for stupid server code by slamb · · Score: 1

      Yes: Gmail (IMAP and SMTP), Google Chat (XMPP), etc. Try it out...do the DNS lookups yourself from different places.

    11. Re:Stupid workaround for stupid server code by afidel · · Score: 1

      NTP obviously would be one since pool.ntp.org would normally return a list of pool members that are closest to whatever google DNS server is responding to your anycast request instead of those that are closest to you.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    12. Re:Stupid workaround for stupid server code by pslam · · Score: 1

      Yes: Gmail (IMAP and SMTP), Google Chat (XMPP), etc. Try it out...do the DNS lookups yourself from different places.

      So, it's only Google doing it?

    13. Re:Stupid workaround for stupid server code by slamb · · Score: 1

      So, it's only Google doing it?

      Probably not. I just gave a couple I knew off the top of my head, and I'm a Google software developer. If you want a non-Google non-HTTP example...hmm, I'd guess MMORPGs would do the same thing. I don't play them myself, but WoW, Everquest, City of Heroes, etc. If I knew hostnames I'd give DNS results to prove it. In any case, geolocating through DNS is a general technique that many sites use for HTTP, at least one company uses for several non-HTTP products, and many others could use for a variety of protocols in the future.

    14. Re:Stupid workaround for stupid server code by Anonymous Coward · · Score: 0

      It won't work when you're not using DNS.

      How do you think they implemented 4.2.2.4? 4.2.2.4 is always closest to you in network terms. Why not build on that?

      Seems like a no brainer to me.

      As in no brain was used to come up with this?

  28. Local DNS cache by Wowsers · · Score: 1

    Maybe it's about time the Windows operating system was given the ability to cache DNS queries locally BY DEFAULT. It would speed up searches for most used sites by the user, and take the load of the internet from running requests for sites the user keep on visiting.

    --
    Take Nobody's Word For It.
    1. Re:Local DNS cache by sgt+scrub · · Score: 1

      Maybe it's about time the Windows operating system was given the ability to cache DNS queries locally BY DEFAULT and open Windows back up for DNS cache poisoning which was the reason is was disabled BY DEFAULT.

      FTFY

      --
      Having to work for a living is the root of all evil.
    2. Re:Local DNS cache by Anonymous Coward · · Score: 0

      It still does this by default.

  29. It already does by _0xd0ad · · Score: 1

    If you went out of your way to Disable Client-Side DNS Caching, that's hardly something you can blame Windows for...

  30. Akami? by Anonymous Coward · · Score: 0

    Just to reuse the title from above, for more effect. I am guessing Akami owns the easy and obvious ideas in pretty tight patents. That is one of the reasons they have limited competitors.

  31. How is this new again? by Vrtigo1 · · Score: 1

    So...the summary states "they've reworked their DNS servers so that they forward the first three octets of your IP address to the target web service". Uh, doesn't my browser send my WHOLE ip address to the web service when I make a HTTP request anyway? How is this different/better?

    If what they meant to say is that the resolver sends the first three octets of my ip address to the destination's name servers when doing a recursive lookup, then how is this any better than using any old DNS? In other words, the big advantage to Google DNS for example is that it's free and fast. If their DNS server now has to ignore any cached records and do a recursive lookup for EVERY request, doesn't that negate the speed advantage? Obviously once someone in my /24 requests www.itunesdownload.akamai.net, then that specific IP should be cached for all requests from the same /24 for the TTL specified by the site operator, but for all other sites that will probably not have been hit recently, and thus not cached, I only see this adding more latency.

    They should just do it in the web stack instead of trying to do it down in layer 4. User navigates to the download page, then the webserver has your full IP, geolocates you and redirects you to a download from a local server.

  32. How I envy you... by juancn · · Score: 1

    If you have a 10 or 20Mbps connection, and yet a download is crawling along at just a few hundred kilobytes

    I would love to have a connection that "crawls along at just a few hundred kilobytes (a second)", most of the times, when it crawls, it does so at a few tens of kilobytes a second (sometimes even less than that).

  33. I love the posted example by Anonymous Coward · · Score: 0

    >(downloading software or drivers from a Taiwanese site is a good example)
    not if you live in Taiwan

  34. That is very good news. by sgt+scrub · · Score: 1

    For Akamai.

    --
    Having to work for a living is the root of all evil.
  35. I saw the article title and it read.. by SuperCharlie · · Score: 1, Insightful

    Evil and OpenDNS Work On Global Internet Speedup.

    I think from now on simply replacing the word Google with Evil should be an auto-correct feature.

    1. Re:I saw the article title and it read.. by Kozz · · Score: 2

      Evil and OpenDNS Work On Global Internet Speedup.

      I think from now on simply replacing the word Google with Evil should be an auto-correct feature.

      And who, exactly, is forcing you to use OpenDNS?

      --
      I only post comments when someone on the internet is wrong.
    2. Re:I saw the article title and it read.. by Anonymous Coward · · Score: 0

      While I no longer want to defend Google and claim they aren't evil, what exactly do you call Microsoft, Apple, Sony, Oracle and Facebook who are all certainly no less evil than Google.

  36. To save two TCP setups and teardowns by tepples · · Score: 4, Informative

    Even if your first connection is to a server in Djibouti, you may be redirected

    Which costs a TCP setup and teardown to Djibouti.

    to a server in Canada, and then that one may again redirect you to a server in Sweden

    Which costs a TCP setup and teardown to Canada.

  37. Latency vs. bandwidth by aharth · · Score: 1

    There are two factors that affect the performance of web (HTTP) lookups: latency and bandwidth. Latency depends on the distance between client and server. You won't be able to send data faster than the speed of light. Bringing the data closer to the client helps to reduce latency, especially for small lookups. Bandwidth becomes the limiting factor when you transfer (large amounts of) data over under-dimensioned pipes. In general, I'd be a much more happy person if people would use HTTP caching headers (Expires and such) more often, as then a Squid proxy can bring substantial performance gains.

  38. Re:Ehh.... this is ok, but .... by Anonymous Coward · · Score: 0

    No, they're trying to turn it into cable TV. One way delivery, only "approved" content providers get distributed, everything that's not on the official local CNS gets throttled way down. Easier censorship is just a side benefit

  39. Not an Internet Speedup by GameboyRMH · · Score: 1

    An Internet speedup would involve adding the ability to carry more bytes per second, analogous to changing your delivery vehicles from donkey carts to vans. This is just improving the logistics of the donkey cart-based delivery service.

    --
    "When information is power, privacy is freedom" - Jah-Wren Ryel
  40. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  41. What we need are shorter web pages by Animats · · Score: 2

    What we need is less junk in web pages. The amount of dreck in web pages has gotten completely out of control. The home page of Slashdot has 3424 lines of HTML, not counting included files. This is not unusual. I'm seeing pages over 4000 lines long for newspaper stories. Pages with three to five different tracking systems. Hidden content for popups that's sent even when the popup isn't being loaded. Loading of ten files of CSS and Javascript for a routine page.

    CSS was supposed to make web pages smaller, but instead, it's made them much, much bigger. Being able to include CSS from common files was suppose to improve caching, but instead, many content management systems create unique files of CSS for each page.

    And you get to pay for downloading all this junk to your smartphone. It doesn't matter what route it takes through the backbone; eventually all that junk crosses the pay-per-bit bandwidth-throttled air link to the phone.

    Where bandwidth really matters is video. There, the video player already negotiates the stream setup. That's the place to handle choosing which source to use. Not DNS.

    1. Re:What we need are shorter web pages by Anonymous Coward · · Score: 0

      CSS has made Web pages smaller. Use something like Lynx, and you won't get any of that extra crap. Just imagine if the only alternative was for people to shove that crap into style attributes! :-)

    2. Re:What we need are shorter web pages by hamsjael · · Score: 1

      Could'nt agree more. Take a look at the HTML for http://openbsd.org/ Thats just beautiful! Another reason why i trust their software above anybody elses

  42. Looks OK, but what about anycast? by fa2k · · Score: 1

    I was preparing to hate this (I don't trust Google that much & OpenDNS do some questionable things), but I can't find anything wrong with this from a privacy or openness perspective. I think there has already been huge DNS pools that return a random set of records, so the idea of DNS being universal and reproducible is gone, if that idea ever existed (and I see no reason why that would be a problem).

    Isn't this what anycast is supposed to solve? For example when using 6to4, one can specify a single, globally known address, but it takes you to a local 6to4 gateway (if it happens to work at a given ISP..). Would anycast support commercial entities setting up a CDNs with a few anycast addresses, that route to the nearest server farm? I don't know if I prefer this, since it requires putting some "intelligence" in the routers. Going by the adoption rate of IPv6, this wouldn't be supported by ISP before 2030 anyway...

    Sorry for researching this, but if anycast is better supported in IPv6, then that could be why the explanation page lacks any mention of IPv6. Sites would have to supply a few normal addresses in addition to the anycast address in DNS for redundancy, but browsers could try the anycast one first for speed. I think this would be a good solution, but I don't know if it's better than Google and OpenDNS's suggestion.

    1. Re:Looks OK, but what about anycast? by Anonymous Coward · · Score: 0

      Anycast isn't a good solution for TCP, since routing topology changes in the backbone can change which anycast endpoint your packets end up at, which breaks your TCP connection.

    2. Re:Looks OK, but what about anycast? by petermgreen · · Score: 1

      Anycast works great for protocols like 6to4, DNS or NTP where each packet is a complete transaction and it really doesn't matter if all your packets end up at the same server. It isn't so good for TCP where the client and server have shared state. In the worst case where a route is flapping you may never maintain a connection for more than a few seconds as your packets get repeatedly sent to different server.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  43. How would caching work? by fa2k · · Score: 1
    (not related to my previous post:) How does this work with DNS caches? Say Ebay implemented this and gave back A records depending on the client IP address. If user A was using Google DNS in Norway and requested DNS records for Ebay, then Google could
    • a) Cache the reply and return those for all other users (B,C,D...). This would mean that all users of that Google DNS server, maybe over all of Europe, would get the A records for Ebay's Norway server (I don't think Ebay has a server in Norway, but never mind that)
    • b) Perform a new request to Ebay for each user of its DNS service, but this would slow down DNS requests!

    So which one is it? Does google have a separate cache for each /16? I'm interested to know how they deal with this. I guess it's not a dealbreaker, but all options involve some trade-offs.

  44. Re:Ehh.... this is ok, but .... by afidel · · Score: 2

    I don't think that's true at all, many transoceanic links have dark pairs. I know the Google-cable was going to be only half lit at installation. The existence of dark fiber on transoceanic links is driven by many of the same economics as dark fiber on land, only magnified since the cables are so much more expensive, the installation makes trenching look cheap, and the lead times are measured in quarters instead of weeks.

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  45. ONLY PROBLEM IS, it "chokes" by Anonymous Coward · · Score: 0

    w/ large HOSTS files (Windows LOCAL DNS clientside cache service).

    YES - Windows LOCAL DNS CLIENTSIDE CACHE SERVICE "chokes" with larger HOSTS files & lags you. I noted this to MS' Senior mgt. in their "Windows Client Performance Division" in fact (Foredecker/Mr. Richard Russell who used to post here quite a lot in fact) here on this very website years ago:

    http://slashdot.org/comments.pl?sid=1467692&cid=30384918

    Along with the fact that a SMALLER & FASTER/MORE EFFICIENT BLOCKING "IP ADDRESS" CAN STILL BE USED IN Windows 2000/XP/Server 2003!

    (Where it could be used in VISTA (& onwards in Win7/Srv2k8) up until MS "Patch Tuesday" on 12/09/2008)

    That FASTER/BETTER one, is 0 - Used as the blocking address (vs. the largest/slowest in the 127.0.0.1 loopback adapter address, OR the slightly better & just as compatible 0.0.0.0 blocking address (no loopback hit is incurred there either mind you)).

    He never got back to me, though he said he would here, AND in email... I didn't like THAT very much!

    Still It's nice to see that GOOGLE & OPENDNS are doing this though! (both of whom provide DNS services, OpenDNS also filters vs. phishing/spamming & possibly malware (Norton DNS does for sure on the latter though, so I use it alongside OpenDNS + ScrubIT DNS in my routers &/or IP stack settings)).

    APK

    P.S.=> HOWEVER/"Bottom-Line" here, is this: Nothing GOOGLE &/or OpenDNS can do can resolve IPAddress-to-HOSTS/DOMAIN names, as fast as locally hardcoded favorites in the HOSTS file either... that's not all I use it for, but mostly for blocking out 1,580,313++ KNOWN bad sites/servers/hosts-domains, botnet C&C servers, sites KNOWN to serve up malicious script content or malware-in-general (for security) AND, adbanners (For more bandwidth/speed that I pay for) which also lends not only to speed online, but also security (since adbanners HAVE been found to house maliciously scripted content as well)...

    ... apk

    1. Re:ONLY PROBLEM IS, it "chokes" by Anonymous Coward · · Score: 0

      That's because you're a fucking idiot.

  46. Re:Ehh.... this is ok, but .... by lennier · · Score: 3, Insightful

    Isn't this little more than an expensive band-aid for the underlying bandwidth problem?

    Not really. There is always a finite quantity of bandwidth. It only becomes a "problem" when you have applications which assume infinite bandwidth or are forced to assume this for legal or political rather than technical reasons.

    Like, oh let's just say for example, streaming video.

    Streaming is the anti-caching. It's a terrible technical non-solution to a legal problem. It clogs the tubes and wastes bandwith by design just to retain control over the obsolete idea of "broadcasting" so that copyright control and advertisements can be retrofitted into the stream.

    But doing video right would require re-engineering our entire economy -- which will have to happen sooner or later when the IP crash comes -- so we'd rather just break the Internet by design and then attempt to retrofit some kind of weird fixup after the fact to make some preferred partners work sort-kinda okay.

    --
    You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
  47. Why not just use Anycast? by tomtomtom · · Score: 1

    Why would they use this rather involved mechanism rather than anycast IP addressing? TFAs don't go into why they've gone to the effort of reimplementing something which essentially already exists.

  48. Re:Ehh.... this is ok, but .... by SuperQ · · Score: 1

    Sorry, but you have no clue what this is about. This has very little to do with bandwidth and much more to do with latency.

    Say you live in Germany.

    From California to Germany you're talking about 150ms minimum. If you're working with an interactive site like Gmail or Google maps the experience is going to suck. Say it takes the server 100ms to do the work to respond to your request. That's already faster than most website servers are designed to respond to. This means that 250ms is the time it takes to get, process, and respond to a single request. This means you can only really do things at a rate of 4 updates per second. This is very slow for highly interactive web apps.

    If a site can redirect you to a server in europe you can cut 125ms off that request. That's half of the time. It's also below the 190ms it takes your brain to respond to visual changes.

    http://en.wikipedia.org/wiki/Mental_chronometry

  49. Adhominem attacks? Please... lol! apk by Anonymous Coward · · Score: 0

    I'm not the idiot who designed the local DNS clientcache service in Windows that "flakes out" when it encounters a largish HOSTS file (this problem does NOT occur in Linux, mind you, either).

    ---

    Now, as to your off-topic adhominem attack, cowardly little ac troll? Well, time for an application of "ReVeRsE-PsyChoLoGy":

    ".toidi gnikcuf a er'uoy esuaceb s'tahT" - by Anonymous Coward ANOTHER "ne'er-do-well" /. COWARLY OFF-TOPIC ADHOMINEM ATTACK UTILIZING TROLL on Tuesday August 30, @07:31PM (#37259622)

    "???"

    Uhm... Could we get a translation of that off-topic "troll-speak/trolllanguage" of yours, please?

    ---

    * And, you're an off-topic troll - no questions asked...SEE MY SUBJECT LINE ABOVE!

    APK

    P.S.=> Yes, it must have just have been another off-topic done nothing of significance with his life troll spewing his off-topic b.s. again & not contributing to the ongoing conversations. Oh well - No biggie!

    (My "ReVeRsE-PsYcHoLoGy" template, below, for trolls - Courtesy of this code template of mine, by "yours truly", generating YOUR response in less than 1 second flat):

    ---

    #TrollTalkComReversePsychologyKiller.py (Ver #2 by APK)

    def reverse(s):
        try:
            trollstring = ""
            for apksays in s:
            trollstring = apksays + trollstring
        except:
            print("error/abend in reverse function")
        return trollstring

    s = ""
    print reverse(s)

    try:
      s = "Insert whatever 'trollspeak/trolllanguage' gibberish occurs here..."
      s = reverse(s)
      print(s)
    except Exception as e:
      print(e)

    ---

    ... apk

    1. Re:Adhominem attacks? Please... lol! apk by Anonymous Coward · · Score: 0

      You're the idiot who thinks a 14 MB hosts file is "largish" - yes, I read enough of the thread you linked to to know why Foredecker stopped replying to your shit - partly due to the fact that you were "pushy and obnoxious" (his own words) and partly just due to the fact that you're a rabid troll (obviously).

    2. Re:Adhominem attacks? Please... lol! apk by Anonymous Coward · · Score: 0

      That's all foredecker could say after being smoked so badly by apk to the point he had to admit apk was spot on correct in his points about the 0 blocking address producing smaller hosts files and that it should be put back into Vista, Windows 7, and Windows Server 2008 as well as the fact that the DNS clientside cache service in Windows has problems in being made a fixed size where by comparison Linux has no such issues with large hosts files. Top marks to apk on that much for getting the absolute technical best of one of their senior management personell whom I understand has a comp. sci. degree from what I read there. If Foredecker's indicative of the technical expertise at Microsoft in their senior management that he has to resort to adhominem attacks as you have troll, then it's truly no small wonder they're so afraid of Linux and open source.

    3. Re:Adhominem attacks? Please... lol! apk by Anonymous Coward · · Score: 0

      You ARE apk. Quit pretending like you're fooling anyone, retard.

  50. Re:No alternative by thegarbz · · Score: 1

    You forget the reason why these services popped up to begin with. In general often your ISP can't be trusted. There are ISPs out there who run DNS servers which break some of the fundamental functionality of DNS used by various applications, such as the ability to honestly say "no server found" rather than directing you to a search page.

    Then there's ISPs who are too incompetent to run a DNS server providing an undersized box which can't cope with basic traffic. It's sad that in some cases Google's DNS servers actually respond faster than ones located in your own city.

  51. Everyone allready does this. by Anonymous Coward · · Score: 0

    I personally use a 'Local Cashe' of all of the music, and videos, that I may wish to enjoy. I have found that this does indeed resolve any bandwith issues that are associated with repeatedly streaming content.

    I would personally like to see how 'Their Plan to Speed up the Internet' avoids upsetting the RIAA...

  52. IPv6? by Nethead · · Score: 2

    How are the first three bytes of 2001:470:a:6bb:21f:29ff:fe87:88c0 going to tell them anything about my location?

    --
    -- I have a private email server in my basement.
    1. Re:IPv6? by unixisc · · Score: 1

      By octets, it was clear that they were referring to IPv4, since the IPv6 'segments' you have - 2001, 470, etc are not octets. As a post above asked, is it even worth the effort?

      The second word in your address - 470 - tells one that it's issued by ARIN, and so a search on domains under ARIN would pinpoint the subscriber of that particular address, and whether any of the sub-nets fall outside ARIN's geography.

    2. Re:IPv6? by Anonymous Coward · · Score: 0

      How are the first three bytes of 2001:470:a:6bb:21f:29ff:fe87:88c0 going to tell them anything about my location?

      First of all, they don't care about your location. Since all the traffic is going through your IPv6 over IPv4 tunnel server at 216.218.226.238, what matters is the location of that tunnel server. Choosing a webserver closer to you doesn't help, they need a webserver closer to the tunnel server.

      So, how does the first three bytes 2001:400::/24 help identifying which webserver is closest to that tunnel server? The answer is, it doesn't. However when the article says the first three bytes of the address is communicated, then that is an oversimplification of what actually happens.

      The client (which in this case is the recursive resolver, such as Google Public DNS or OpenDNS) can tell the server (which in this case is the authoritative server for the domain you are looking up) exactly how many of the most significant bits it wants. The protocol has a 16 bit field to indicate which kind of address is being communicated (currently only two of the possible 16 bit values have been assigned a meaning. 1 means IPv4 and 2 means IPv6), an 8 bit field to indicate how many bits are being communicated from client to server, and an 8 bit field to indicate how long a prefix the answer is considered optimal for.

      The recursive resolver need to decide how many bits it wants to send. For IPv4 the appropriate compromise seems to be 24 bits. 16 bits would be too short to give a reasonable granularity. Any valuer from between 17 to 23 would have to be padded with zeros up to 24 bits anyway. And 24 bits doesn't compromise your privacy, after all you are going to connect to the webserver anyway at which point it will know your full IPv4 address. Since it is going to know all of it, knowing 3/4 it a bit earlier is no big deal. The reason for supporting less than the full address probably is to avoid meaningless comments about how this violates privacy. Once the support is in the protocol they may as well truncate the addresses to 24 bits by default, as you are not going to need anymore than that to identify the closest server since prefixes longer than 24 bits are generally not advertised through BGP either. For IPv4 it would have been more efficient to communicate the full address and leave out the field indicating the length. The server will then tell the client how many of the bits it actually cared about when deciding which reply to send. The recursive resolver will use this for caching. That way it knows whether the cached entry is suitable for a later query from a different client.

      For IPv6 the appropriate prefix length is much longer. If they use this over IPv6 already, I am sure they are communicating at least 48 bits of the address, maybe even 56. I don't see any reason not to go all the way to 64 bits. It's just two bytes more than the 48 bits, so even if 99% of the times they only care about 48 bits, it is still worth to have those last bits in those rare cases where it does make a difference. Sure the 64 bits is enough to identify exactly which LAN it came from, but they are going to know that once you initiate an HTTP connection anyway. Sending 64 bits saves you 8 bytes in the request compared to sending the full 128 bits. That means the one byte spend on the length field is worth it in terms of bandwidth used, but that is really minor.

      The article didn't mention how many bits where used from IPv6 addresses because whoever wrote it assumed the readers didn't care (probably because the author didn't care either). But the protocol designers did care to make the protocol work with both IPv4 and IPv6.

      The point where it gets really interesting is when they receive requests for IPv6 addresses over IPv4 or wise versa. The protocol has no problem with it, but how do they figure out which of the IPv4 addresses is closest to you when they only know your IPv6 address. In your case even knowing the IPv4 address of the tunnel server won't tell the

    3. Re:IPv6? by Nethead · · Score: 1

      2001:470:a:6bb::/64 is an H-E tunnel (and seemingly oddly, a host address.) I can't remember if they do swippage on it, or even if there is SWIP for IPv6.

      --
      -- I have a private email server in my basement.
    4. Re:IPv6? by Anonymous Coward · · Score: 0

      Actually the 2 first bytes of most IPv6 addresses are sufficient for a coarse but sufficient (for the kind of usage in TFA) geolocalisation, as regional registries get whole /16 ranges. 3 may be necessary for old IPv6 assignments (like the ones in 2001::/16)

      In your own example, 2001:400::/24 is allocated to ARIN, so chances are pretty high you are in North America.

    5. Re:IPv6? by Anonymous Coward · · Score: 0

      By octets, it was clear that they were referring to IPv4, since the IPv6 'segments' you have - 2001, 470, etc are not octets.

      Nonsense. An octet is the unit in which the sizes of everything in the IP protocols are measured. If you look at the IPv6 spec you'll see that the word octet is used 92 times in the spec. An IPv6 address is 16 octets long. The first three octets of the above address are 20, 01, and 04.

    6. Re:IPv6? by Anonymous Coward · · Score: 0

      Actually the 2 first bytes of most IPv6 addresses are sufficient for a coarse but sufficient (for the kind of usage in TFA) geolocalisation, as regional registries get whole /16 ranges.

      That would only work if entities with a network spanning multiple regions got a range from each regional registry and used addresses in the region in which they are allocated.
       

      In your own example, 2001:400::/24 is allocated to ARIN, so chances are pretty high you are in North America.

      2001:470::/32 however is allocated to Hurricane Electric. It is a North American company, but they are using parts of that range in Europe and Asia as well. So even knowing the first 32 bits of the address is only sufficient to narrow it down to three of the five regions.

      Even if it did work it is not sufficiently fine grained for Google. Google don't want the latency from sending traffic between Northern Europe and Southern Europe or between the East Coast of USA and the west coast of USA.

    7. Re:IPv6? by unixisc · · Score: 1

      Sorry, the term 'octet' applies to just IPv4. Which IPv6 specs are you referring to? RFCs? IPv6 allows one to use combined formats, like 2001:470:a:6bb:21f:29ff:254.135.136.192 for the above address, in which case, octets would refer to the last 4 bytes in that address, the way they are represented. Otherwise, an IPv6 address is eight groups of four hexadecimal digits, each group representing 16 bits. While it does contain 8 bits, which could be technically described as octets, since the grouping is done in groups of 4 hex digits, the term 'octet' is not used here. Wonder what the appropriate term would be to describe a double-octet?

      At any rate, giving it just 20, 01 and 04 will only tell the router that the address was issued by ARIN, nothing more. In case of ARIN, it may seem adequate, but if you get a RIPE address, like 20, 01 and 06, that won't tell one whether the nearest DNS server is in Lisbon, Vladivostok or Damascus.

    8. Re:IPv6? by unixisc · · Score: 1

      Yeah, and then cost considerations would kick in. Why would a company want to buy different address ranges from, say ARIN, APNIC and LACNIC, when it could just buy a single /48 from ARIN, and assign certain subnets (bits 49-63) to its Asian and Latin American offices?

    9. Re:IPv6? by unixisc · · Score: 1

      Thanks for describing this whole thing really well. 48 bits of the address should be enough to determine a network, but as someone pointed out elsewhere, an organization that is based in 2 or more of the RIRs would either be getting separate allocations of addresses from each, or, more likely, they'd get a single /48 range from their local RIR, and then assign certain subnets to their subsidiaries elsewhere. In which case, depending on how they implemented it, all 64 bits of the network address would be needed. But you're right - 128 bits should never be needed.

  53. He agreed w/ my points though, lol! by Anonymous Coward · · Score: 0

    OR, did he not state that a larger file (in this case, a HOSTS file) would take longer to read?

    APK

    P.S.=> Do I have to quote he saying that? No, don't think so - not yet @ least...

    HOWEVER, just for laughs: Well - Let's let a little TRULY anonymous COWARD see what he has to say in rebuttal to that point I noted above, & then, I will quote he in that much... making YOU out, just "too, Too, TOO EASILY" as per your trollish cowardly usual, to be the FOOL once again (as always on YOUR part)...

    ... apk

  54. Re:Ehh.... this is ok, but .... by Anonymous Coward · · Score: 0

    I remember going to the global crossing data centre in chile and seeing that google had (apparently) purchased 1/4 of the deep sea fibre around south america. But i don't hink they are thinkimg altruistically when they purchased it, and that was 4 years ago

  55. What's the point? by Anonymous Coward · · Score: 0

    This seems pointless.
    1. A smart ISP can use a caching proxy like squid. This speeds up content for anyone.
    2. The webserver knows where you connect from anyway, there is no need to tell it.
            (It can get your ip address from the socket, it knows for how else would it be
            able to send the page back to you?)
            So it can redirect you, if it knows that a closer server has the same content.

    No need for this newfangled protocol trickery.

  56. Re:Ehh.... this is ok, but .... by Anonymous Coward · · Score: 0

    Full disclosure: I work for CDNetworks and have been part of this initiative.

    As rightly pointed out, content delivery networks already have a widely distributed platform and use intelligent algorithms to route user traffic to the "closest" CDN server. These algorithms use geo-location whenever possible. But in some cases, it is hard to figure out the location of the end user. This initiative aims to address that.

    To get an understanding of the inner workings of the technology, you can read my blog here: http://www.cdnetworks.com/blog/global-internet-speedup-initiative-a-look-under-the-hood/

    Also, this is doesn't cost anyone, anything. It is just a more transparent communication between the CDN provider like CDNetworks and DNS provider like Google which enhances the user experience.

    Arijit

  57. Re:New GNAA President paz is Elected by JabberWokky · · Score: 1

    I actually tried to read it out of curiosity. The links are dead.

    It's official: according to Netcraft, GNAA is dead. Or at least 404ing in their cut and pasted diatribes. Even the new ones.

    --
    "$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
  58. U R A douchebag by Anonymous Coward · · Score: 0

    Foredecker had to admit apk's right that a smaller faster hosts file results using 0 over 0.0.0.0, bigger/slower, or 127.0.0.1 worst of all is slowest/worst and apk's right that it ought to be put back into vista and windows server 7/2k8 too because no reason is offered for it not to be.