Slashdot Mirror
Content-Centric Networking & the Next Internet
waderoush writes "PARC research fellow Van Jacobson argues that the Internet was never designed to carry exabytes of video, voice, and image data to consumers' homes and mobile devices, and that it will never be possible to increase bandwidth fast enough to keep up with demand. In fact, he thinks that the Internet has outgrown its original underpinnings as a network built on physical addresses, and that it's time to put aside TCP/IP and start over with a completely novel approach to naming, storing, and moving data. The fundamental idea behind Jacobson's alternative proposal — Content Centric Networking — is that to retrieve a piece of data, you should only have to care about what you want, not where it's stored. If implemented, the idea might undermine many current business models in the software and digital content industries — while at the same time creating new ones. In other words, it's exactly the kind of revolutionary idea that has remade Silicon Valley at least four times since the 1960s."
Did he just reinvent magnet links?
Give me Classic Slashdot or give me death!
Why does he say "it will never be possible to increase bandwidth fast enough to keep up with demand"?
When I want to watch streaming video, I fire up Netflix and watch streaming video. When I want to download a large media file, I find it on bittorrent and download it. The only time I've noticed any internet slowdowns, it's been in my ISP's network, and it's just a transient problem that eventually goes away.
Sure, Netflix has to do some extra work to create a content delivery network to deliver the content near to where I am, but it sounds like the internet is largely keeping up with demand.
Aside from the IPv4->IPv6 transition (we've been a year away from running out of IP addresses for years), is there some impending bandwidth crunch that will kill the internet?
it will never be possible to increase bandwidth fast enough to keep up with demand.
I've been hearing that since I got on the net in '91. Tell me a new lie.
Its an end time message. "Repent, for the end is near". Yet, stubbornly, the sun always rises tomorrow.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
See http://en.wikipedia.org/wiki/Uniform_resource_name . This is a very old [and good] idea.
For example: urn:isbn:0451450523 is the URN for The Last Unicorn (1968 book), identified by its [ISBN] book number.
Of course [as the dept. notes] you still need to figure out how to get the bits from place to place, which requires a network of some kind, and protocols built on that network which are not so slavishly tied to one model of data organization that we can't evolve it forward.
Koans and fables for the software engineer
But, of course, it's all going to be running on top of TCP/IP. This isn't a replacement, it's just another widget you run on the tubes.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Any idiot can have a pile of ideas. The implementation is what matters.
Too bad the idea pays 95%, the implementation 5%
So back in the day, we had a thing called the mbone, which was multicast infrastructure which was supposed to help with streaming live content from a single sender to many receivers. It was a bit ahead of its time, I think, streaming video just wasn't that common in the 1990s, and it also really only worked for actually-simultaneous streams, which, when streaming video did become common, wasn't what people were watching.
The contemporary solution is for big content providers to co-locate caches in telco data centers, so while you still send multiple separate streams of unsynchronized, high-demand streaming content, you send them a relatively short distance over relatively fat pipes, except for the last mile, which however only has to carry one copy. For low-demand streaming content, you don't need to cache, it's only a few copies, and the regular internet mostly works. It can fall over when a previously low-demand stream suddenly becomes high-demand, like Sunday night when NASA TV started to get slow, but it mostly works.
TFA (I know, I know...) doesn't address moving data around, but it seems like this is something that a new scheme could offer -- if the co-located caches were populated based purely on demand, rather than on demand plus ownership, then all content would be on the same footing, and it could lead to a better web experience for info consumers. That's a neat idea, but I think we already know how both the telcos and commercial streaming content owners feel about demand-based dynamic copy creation...
2*3*3*3*3*11*251
"not where it's stored."
So we should make the Internet into Plan 9?
deleting the extra space after periods so i can stay relevant, yeah.
And the list goes on....
Magnet links only use the hash, so there's a possibility of hash collisions. He's proposing an identifier + resolver scheme ... which again, has been done many, many times already.
Eg, ARK or OpenURL
Or, we get to the larger architecture of storing & moving these files, such as the various Data Grid implementations. (which may also allow you to run reduction before transfer, depending on the exact infrastructure used).
Build it, and they will come^Hplain.
Any time someone talks about Content Centric networking or routing, there are always a bunch of people saying that it's basically the same as distributed hash tables, multicast, a cache, etc.
However, it may use such technologies, but it isn't the same.
Content Centric is all about having distributed publish/subscribe, usually on a lower network layer.
The content part in the name means that there is being looked at the content itself for routing, not some explicit addressing. For instance, to give a very simple example you can send out a message [type=weather; location=london; temperature=21], then anyone subscribing to {location==london && temperature>15} will receive this message.
The network is typically decentralized, and using this kind of method can give a number of interesting efficiency benefits.
This is currently mostly being used in some business middleware; ad hoc networking stuff and some grid solutions. None of those particularly large.
The real problems with widespread use of this technique are the following:
* It's unnecessary: IPv6 is completely necessary, somewhat doable in terms of upgrading, and almost nobody is using it even now. This is someone suggesting a whole new infrastructure for large parts of the internet. The fact is, this would possibly be more efficient than many things that are being done now, but in reality nobody cares about it. Facebook and youtube (ok Google) would rather just pay for the hardware and bandwidth than give up control.
* Security is still unclear, it's easy to do some hand-waving about PKI, but it's hard to come with a practical solution that works for many.
Agreed, that's the only realistic approach. Build support for URNs into browsers, get the caching infrastructure in place so that URN'ed data migrates seamlessly to follow demand, and finally get people to migrate from URLs to URNs.
And while we're at it, get rid of the "TLD" concept altogetherm, com vs. org vs. net vs whatever. Names should be doled out to match the jurisdiction of regional naming authorities,with a special "top level". So you might have:
* /i/google internationally-registered name
* /us/tomshardware -- nationally-registered trademark/servicemark in the US (similar for /ca, /fr, /de, etc.)
* /us/gov/fbi -- federal-level US agencies
* /us/ny/empirestatebagels -- businesses registered at the state level only
* /us/ny/gov/dmv -- state-level US agencies (New York Dept of Motor Vehicles)
* /us/ny/nyc/gov/cityhall -- city-level agencies
The wrangling over the specifics would be fun. :-)
Koans and fables for the software engineer
This has been proposed before. It's already obsolete.
The Uniform Resource Name idea was supposed to do this. So was the "Semantic Web". In practice, there are many edge caching systems already, Akamai being the biggest provider. Most networking congestion problems today are at the edges, where they should be, not at the core. Bulk bandwidth is cheap.
The concept is obsolete because so much content is now "personalized". You can't cache a Facebook page or a Google search result. Every serve of the same URL produces different output. Video can be cached or multicast only if the source of the video doesn't object. Many video content sources would consider it a copyright violation. Especially if it breaks ad personalization.
As for running out of bandwidth, we're well on our way to enough capacity to stream HDTV to everybody on the planet simultaneously. Beyond that, it's hard to usefully use more bandwidth. Wireless spectrum space is a problem, but caching won't help there.
The sheer amount of infrastructure that's been deployed merely so that people can watch TV over the Internet is awe-inspiring. Arguably it could have been done more efficiently, but if it had been, it would have been worse. Various schemes were proposed by the cable TV industry over the last two decades, most of which were ways to do pay-per-view at lower cost to the cable company. With those schemes, the only content you could watch was sold by the cable company. We're lucky to have escaped that fate.
Yes, and if you read that link you discover that he has been pushing this idea since 2006. So, while he has some good credentials to say that the sky is going to fall, he has been saying it for six years now. The sky hasn't fallen and the only sign that it might is the complaints of cellphone vendors, ISPs, and content producers whose profits have not risen as fast as they thought they would and/or would like them to.
The truth is that all men having power ought to be mistrusted. James Madison
There is not only a cost of deploying the new tech, but also the cost of change. That cost of change is REALLY high as the current methods are deeply seeded. IPv6 isn't "there" yet... and the experience has been dizzying for many. Now there's another new approach? It may be better, but people don't want the change. Something catastrophic will have to cause such change and...
Yeah, like Y2K. Oh, wait....
I know! Let's get Apple to build it. Apple people will pay obscene sums for shiny new stuff with Apple logos on it.
Britain did that with their original domain name system. Email would have been uk.ac.somewhere.faculty.department.researchlab@student, and a web page would have something similar.
Aren't DNS hostname just the same thing as he is proposing. You send out a request for the name, and any one of many machines may send back the reply?
All they would have to do is add support for encrypted hostnames. Encrypt the name using a public/private key and send it to the secure port of the domain name server.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
I have a feeling that the current crop of PARC researchers are not as bright as their peers 20 or 30 years ago
They do not give us any new insight on what's beyond the horizon, nor demonstrate to us what their visions are leading to, unlike their peers 20, 30 or 40 years ago had done
Muchas Gracias, Señor Edward Snowden !