Aaron Huslage

My mind was recently blown. I’ve been thinking a lot about the growth of the future Internet and I think I’ve found the way forward in a relatively new project to revolutionize how machines talk to each other on the Internet. This is really geeky stuff, but the paradigm shift that this new protocol provides is astonishing in its implications.

Some background for those who know little about how the Internet works.

The Internet was built on top of telephone networks that were already showing their age. The main protocol of the then ARPAnet, TCP/IP, was built upon ideas formed at the beginning of packet switched networking. Simply put, the protocol defines IP addresses and some basic communication mechanisms (TCP and UDP) for one machine to talk to another. This protocol persists today. Every machine on the planet that is hooked to the Internet (and many that are not) possesses an IP address that looks like this: 10.61.37.209.

In the 1980s as the user base of the net started to expand, engineers decided that remembering all of these IP addresses was becoming difficult. The impossibility of keeping hundreds of these little addresses up-to-date in ones mind or in some text file surfaced the need for another layer to make this thing scale. The Domain Name System (DNS) was born. Put simply, DNS builds on the existing protocols of the Internet with a new application that maps human readable names like google.com with brutish IP addresses. The average user of the Internet doesn’t even have to care about IP addresses anymore. Neat trick.

The problem with DNS is not that it doesn’t scale or that it doesn’t make things easier, it certainly does. The problem is that the names that it presents mean absolutely nothing to the network. You type ‘google.com’ into your browser and a whole bunch of stuff happens in the background to make that page appear. The fundamental nature of the beast, though, is connecting your IP to google.com’s IP and letting your two computers have a conversation.

The Internet was designed for one machine to share information with exactly one other machine. There are other protocols that can be used to connect one machine to many machines (like IP Multicast), but they go unused on the wide Internet and are generally limited to local networks.

This is the part of the Internet that doesn’t scale. We’ve made great strides to accommodate the growth of the net with modern routing algorithms and load balancing techniques, but the fundamental thing is still the same. We need a new way for the content itself to be addressed directly, regardless of what machine it lies on or even where in the world it is. The network should be content agnostic, but remain simultaneously content aware. This is where the shift needs to occur on the future Internet. IP is dead.

Enter Content-Centric Networking, or CCN. This project is run by Van Jacobson at the illustrious PARC in Palo Alto, CA. PARC is famous for many things, but most notably for popularizing the user interface that you’re using to read this page with. Van Jacobson was a major contributor to the initial project that came up with IP in the first place. In other words, CCN is being spearheaded by on of the very authors of the spec that its trying to replace. Nice hack.

CCN replaces IP addresses with names for content. These names mean something to the network, in fact they are the only thing that lets stuff speak on the network. This sounds like a simple idea, but it is insanely powerful. By simply replacing the address 74.125.127.100 with the name “google.com” we enable any device, or any person for that matter, to no longer care that the content that I’m asking for is on a machine in a data center in (in this case) northern Virginia. In fact, that content could be many places in the world simultaneously and I don’t really have to care anymore. The network simply provides the content through whatever channels are available at the time I asked for it.

This new paradigm is radical and changes everything. Abstractions like DNS and load balancing are no longer necessary in a world of a CCN-based Internet. Content can come from anywhere at any time. This enables devices (and the people that use them) to carry content with them and provide it to anything else around them that wants that content.

One example of this would be networking the un-networked world. Let’s say I have an AT&T iPhone and I’m travelling to some remote place. This remote place has no cell signal, but other people in the area have devices that are interconnected with each other. There is a well-trafficked highway with a cell signal within range of one of these people. I can still read my email with the help of CCN. My device doesn’t need to care where the data comes from anymore, it just puts out a request (or Interest as it’s called in CCN-ese) for it and waits for a response.

Upon registering the intention for a certain piece of email, the network looks around for a way out and sees that someone on the highway is allowing people to talk through their T-Mobile cell phone. The request is passed up the chain to some machine that has a copy of that email (it doesn’t need to be my server, it can be any machine on the network that has seen this email in the past). The email is passed back down the chain, through someone’s Verizon cell phone, and eventually ends up on my AT&T iPhone.

This isn’t some pipe-dream. Bits are just bits in the CCN world and can live in a cache, or on some server or on a router on the network. As long as the content is valid, it’s sitting there waiting to be consumed. If I were looking for CNN.com, that content would be in caches all the way up the chain and my response times would be very low because the cell phone passing by on the highway would only have to ask the cell tower to send it the data.

The idea of replacing IP addresses, which no user in the world cares about, with names for content, which every user in the world cares about, is not new. CCN is the current best approach that I’ve found to the problem of fixing the Internet. It will take years for this new protocol to catch on, and Van Jacobson has thought about that a lot. In fact, CCN is set up so that it can be used on the Internet as it exists today! The protocol is being worked on in full public view and they are asking for contributions to their open-source reference implementation.