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!
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
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
And the list goes on....