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."
Looks like someone forgot to check the little box marked "Post Anonymously."
> 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.
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).
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.
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
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.
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.
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.
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.)
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).
Happy to answer questions about this work.
# Hack the planet, it's important.
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.
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.
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.
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.
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.
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.
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
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
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.