Driving to a Content-Centric Internet

Burt Kaliski | Oct 18, 2012
I’ve never been all that handy with car engines, although there was a time when I knew how to adjust a carburetor with a screwdriver while the engine was running to keep the car from stalling.   (Let’s not get into the time when I thought I knew how to adjust an overheating radiator with the engine running …)

Nowadays, I just turn on the ignition and drive, thinking much more about where I’m going than what’s going on under the hood.  That part I leave to the repair shop to take care of. 

You might say my experience with automobiles has become driving-centric rather than vehicle-centric.  

Internet pioneer and PARC research fellow Van Jacobson made a similar point as this month’s Verisign Labs Distinguished Speaker.  Users just turn on the Internet and browse.  A URL such as http://www.youtube.com/watch?v=3zOLrQJ5kbU, once more broadly understood a scheme (“http://”) followed by a domain (“youtube.com”) followed by a path (“watch”) and a query string (“v=3zOLrQJ5kbU”) – a carburetor, a radiator and a transmission, if you will – is now more often seen as a name, a way to refer to an object.  User experience, once protocol- or communications-centric, has become content-centric.

Why the change?  Internet users, like drivers, have a goal in mind:  to go somewhere, to do something.  They think much more about where they’re going than what’s “under the hood” of the Internet:  how a domain name is resolved into an IP address (whatever that is), how an HTTP connection is established, how the server processes the path and query string to produce the object or content of interest.  These things are still quite important (and challenging to implement well); domain names give users confidence about where they’re going, and the resolutions, connections, and services make sure they get there.  But typical users (the ones who are not Internet aficionados) are more interested in the object they’re getting to, and they should be.  The technology works well enough that users can take it for granted.  

Van started his talk pondering why one younger user he spoke to wasn’t really interested in understanding Van’s explanation of http: and all the rest of a URL:  she was just interested in what the URL represented.  As one of the original contributors to TCP, Van began with the process as the central point of understanding.  But if you change perspective to the outcome, he continued, you can get to a different view on how networks can operate.  In particular, instead of just moving packets to the next node, a network node could try to understand what a user was actually looking for, and keep a copy of the relevant for the next user who asked for the same thing.  As long as it fulfilled the user’s intent, the difference in process didn’t matter; the outcome would be the same.

As one use case of an approach of this type called Named Data Networking (NDN), Van offered a solution to the classic problem of distributing one’s slides to interested audience members.  With an appropriate implementation of NDN, Van described, audience members could send a request for the slides, for instance using on a string given in the talk, e.g.,

want ‘/parc.com/van/slides.pdf’

Any of their peers who already had the slides could then respond with a copy (either of the full set, or of individual pages), or the request could be routed to an intermediary or to Van’s computer if a copy wasn’t already available in the room.

I suppose that this is how, absent technological assumptions, I would think today’s Internet worked anyway:  You just got what you were looking for in whatever way made the most sense.  My car goes the direction and speed I tell it to even if I don’t know what’s going on under the hood.  But that’s because such a complex vehicle is engineered so well.  Engineering and operating such a complex system, whether NDN, DNS, or network communications more generally should be the real challenge.  Using and enjoying the system needn’t be.

One of the reasons we invite great technology leaders like Van to the Verisign Labs Distinguished Speaker Series, is because it helps us – and the audience we gather – to get a better perspective on potential technology changes.  For this purpose, we are interested in both process and outcome – and not just process in terms of how the protocols work, but how the research is emerging.  Van gave helpful insights about NDN that explain where it fits in the evolution of the Internet.  While I’m not sure where NDN and its variants will take us, it’s good to have a front seat for the ride.

What technology changes do you see coming that change your perspective on the Internet?