We all know what happens if we pour water too quickly into a funnel. We quickly find ourselves on the floor with a roll of paper towels cleaning up the mess. This is the problem Van Jacobson helped solve in the late 1980s. Instead of water, consider the flow of data. The problem was traffic congestion on the Internet.
The original TCP/IP worked fine on the campus, connecting various hosts like computers and shared resources such as printers and plotters. But when those local networks, often operating at 10MB, were connected with other local networks via the long distance lines of the day, often operating at 56kb, the result was a traffic jam and a lot of frustrated users.
You can see the funnel effect in a graphic taken from Congestion Avoidance and Control, a paper written in 1988 by Jacobson, then at Lawrence Berkeley Laboratory, and Michael J. Karels of the University of California at Berkeley.
As Jacobson explains it, the problem was that the error correction and repair facilities built into TCP/IP were not sophisticated enough to handle the bandwidth mismatch.
The solution by Jacobson and his collaborators added algorithms allowing for the detection of the "overflow" condition. In response, the sender would reduce its speed by 50%. Although overflow would trigger another 50% speed reduction and so on. These algorithms helped the Internet survive a major traffic surge in the last 80s, and are used in over 90% of Internet hosts today.
They also helped place Jacobson on most lists of Network Innovators, including the list of 2012 inductees to the Internet Society's inaugural Hall of Fame. Jacobson is now a research fellow at PARC. His resume includes work as Chief Scientist at Cisco Systems and later Packet Design Networks. He was awarded the 2001 ACM SIGCOMM Award for outstanding lifetime contribution to the field of communication networks.
Today Jacobson is working on; you guessed it, network congestion. But this is a different kind of congestion and Jacobson is proposing a different kind of solution. Jacobson explains that today's problem comes from the fact that the Internet was designed as a communications network, not a media distribution network.
That changed with the introduction by Tim Berners-Lee, another Network Innovator, of the World Wide Web. With the creation of the web, Internet communication because less of a dialog between hosts and more of a broadcast, with many users receiving the same information upon request. The advent of Internet streaming of audio and video has made this pattern even more obvious. And with hundreds of millions of new devices and people coming online every year, data demand is exponentially skyrocketing: global IP demand for data is nearing 30 exabytes – 30 billion gigabytes! – per month. To the extent that this is broadcast traffic, the same data packets are being fed over and over again. Jacobson explains:
VJ: There's a problem in solving that problem over a conversational structure. It's a really poor fit. If you can envision doing broadcast radio by having every listening make a phone call to the radio station, that's essentially what we have to do on the Internet. In order to consume some web content you're making a phone call to the server. If it's really popular content millions and millions of people are making their individual calls to that one server. And trying to scale that up so it's not really a server but a huge distributed presence is why people buy millions of load balancer boxes and switch infrastructure.
Jacobson says the key to reducing the wastefully redundant traffic is Content-Centric Networking ("CCN"), in which the key object is the content itself, rather than the end points ("hosts") of the communication. While traditional host based traffic is based around host names ("URLs") which resolve to host addresses; CCN is based on "Named Content".
If you think about it, we are already operating on this model. We rarely go just to YouTube, for example. We follow a link to a specific video, represented by the coding which appears after the top level domain on the URL. That could be the name of the content. And while we are told that 60 hours of video is uploaded to YouTube every minute, in truth few get more than a handful of views. For the top 50 or 100 at any time of course, the story is very different. Duplicate packets containing these video streams can flood the network amounting to a significant portion of all traffic. Jacobson asks:
VJ: What if we could, rather than announcing the end of routes to IP addresses, we could announce the routes to the information that's held on some router? NYTIMES isn't the IP address that's nytimes.com, it's the collection of information NYTIMES. And what you inject into the network is the name NYTIMES and what you are saying is, "If you want any of the information starting with NYTIMES send the packet this way because I have some of that."
Along with the content naming scheme, that other key piece of a named content implementation is a Content-Centric Router, which Jacobson says, is one with a "content store" making it capable of caching packets which pass through and recognizing subsequent requests for the same information.
It is clear that consumers want broadcast content and the content creators want to provide it. Jacobson says because of that he has no doubt that Content-Centric Networking will be adopted. What remains uncertain is the question of who will pay for what. Today, broadcast content creators generally provide the infrastructure, usually through a combination of massive server facilities and distribution agreements with content distribution companies like Akamai Technologies, InterNAP Network Services and Keynote Systems. With CCN those costs are greatly reduced or even eliminated.
But someone must buy, deploy and maintain the Content-Centric Routers and that is where the ISPs and backbone companies come in. The costs which the content generators now bear will be transferred to them and that will demand changes in pricing models.
Jacobson says all the major router makers are working on the technology and early indications are that the incremental costs over current router models will be minimal. CCN, he notes, "runs on top of TCP/IP. It doesn't replace it." The ISPs, he believes, will have to adopt the technology and take responsibility for moving content as close to the consumer as possible. Otherwise, he says, they will be overwhelmed by demand that even the fattest of pipe can handle.