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."

Comments

Magnet links?

[Hatta]

Did he just reinvent magnet links?

Re:Magnet links?

[vlm]

Did he just reinvent magnet links?

Closer to a reinvention of freenet.
Or maybe reinventing mdns
Or maybe reinventing AFS

Its been a pretty popular idea for a couple decades now.

Re:Magnet links?

[fuzzyfuzzyfungus]

" (In Jacobson’s scheme, file names can include encrypted sections that bar users without the proper keys from retrieving them, meaning that security and rights management are built into the address system from the start.)"

It sounds like he made them worse; but otherwise pretty similar to magnet links or the mechanisms something like Freenet uses.

Perhaps more broadly, isn't a substantial subset of the virtues of this scheme already implemented(albeit by an assortment of nasty hacks, not by anything terribly elegant) through caches on the client side and various CDN schemes on the server side? URLs haven't corresponded to locations, rather than to either user expressions of a given wish, or auto-generated requests for specific content, in the majority of cases for a while now(and, on the client side, caching doesn't extend to the entire system, for security reasons if nothing else; but it already covers a lot of common web-resource request scenarios).

Now, in a perfect world, "we have a pile of nasty hacks for that" is an argument for a more elegant solution; but, in practice, it seems to be closer to equivalent to "we already have stuff that mostly works and will be cheaper next year", which can be hard on the adoption of new techniques...

Re:Magnet links?

[Anonymous Coward]

Is your actual premise here that Van Jacobson, a major contributor to TCP/IP and inventor of the modern flow control it is based on, somehow doesn't have the foggiest idea how the infrastructure HE HELPED FUCKING INVENT works?

Re:Magnet links?

[cayenne8]

My concern is, whenever I hear about "re-inventing the internet"...is that if we do it, this time around, all the government types will want to have protocols in there to assure no anonymity, tight control...and likely make it difficult for the avg person to hook a computer to the internet of the future, and become a true peer.

The genie is out of the bottle, even still today on current internet setup....I'd not count on the govt types allowing the next one, to have a genie....by force of law.

Re:Magnet links?

[Jah-Wren Ryel]

I think the whole thing falls under the "I have a great idea, but I actually don't have the foggiest idea how infrastructure works now, but hey, I need to a BIG SEXY CONTROVERSIAL headline."

Imagine if even a tenth of the fucking morons out there who pontificate on subjects for which they had no real knowledge at all actually did have that knowledge. My God, we'd probably be terraforming Pluto by now!

The irony is strong in this one.

Anyone pontificating about internet infrastructure who doesn't know Van Jacobson is a fucking moron.

Isn't the internet already meeting demand?

[hawguy]

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?

Re:Isn't the internet already meeting demand?

[ShanghaiBill]

the demands of each individual user aren't likely to increase much beyond that.

I think your thinking is way too constrained. If the bandwidth was available, then people could have immersive 3D working environments, and tele-commuting could be far more common. This would result in much less traffic on the roads and a huge reduction in CO2 emissions and oil imports. This is not science fiction. I have used Cisco's "Virtual Meeting Room" and it is pretty good.

You also need to think about things like "Siri", that send audio back to the server for processing, because there isn't enough horsepower in a cellphone. I could see "smart glasses" of the future sending video back to a server. That will require huge bandwidth.

If the bandwidth is available and affordable, the applications will come.

Boring

[vlm]

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.

Re:Boring

[JoeMerchant]

Two words: Dark fiber. Laying absurd capacity of trunk line is no more expensive than burying an old copper wire bundle.

Sounds like the principle behind URNs

[QilessQi]

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.

Dynamic caching?

[Urban Garlic]

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...

But I *DO* care where my content comes from!

[jmac880n]

There is a huge chunk of the Internet that cares very much where the content came from:

• Who exactly is asking me to transfer money out of my account?
• Did this patch that I downloaded come from a reputable server? Or will it subvert my system?
• Is this news story from a reputable source?

And the list goes on....

Re:But I *DO* care where my content comes from!

[Hatta]

Who exactly is asking me to transfer money out of my account?
        Did this patch that I downloaded come from a reputable server? Or will it subvert my system?
        Is this news story from a reputable source?

None of these depend on the location of the data, only the identity of the author. If you can verify the integrity of the data, where you get it is irrelevant.

Not a new idea, or a useful one

[Animats]

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.

Re:CCN is not $other_technology

[w_dragon]

There are a couple other little issues:

You need to be able to find things somehow. This requires either some set of central servers, which somewhat defeats the purpose, or a method of broadcast communication that isn't blocked by your ISP. There's a good reason your ISP blocks UDP broadcast and multicast packets - on a large network broadcast leads to exponential packet growth.

For most of us the most limited part of the internet infrastructure is the link from the last router to our house. Picking up my youtube cat videos from my neighbour rather than from a cache server on my ISP's backbone may seem like a good idea, but in reality you're switching traffic from a high-capacity link between my street's router and my ISP, to a low capacity link between my neighbour and our router.

If you're going to cache things on my computer you're going to be using my hardware. That hardware isn't free, and neither are the bits you want to use my internet connection to send. How am I going to be compensated?