The Next Internet? Inside PARC’s Vision of Content Centric Networking

The Internet may be hurtling toward collapse under the strain of too much traffic. But PARC research fellow Van Jacobson thinks he knows how to fix it.

He’s done it before. Back in the mid-1980s, when the Internet was seeing its first modest surge in usage, Jacobson noticed that data packets were piling up on the message routers of the day, like cars waiting for cross-traffic to clear before entering an intersection. Working with fellow Berkeley computer science instructor Mike Karels, he came up with a small change to the Transmission Control Protocol (TCP) that, in essence, allowed packets to ease into the intersections gradually, curing the congestion. Later, Jacobson also came up with a way to compress the “headers” or address sections of Internet Protocol (IP) packets from 40 bytes down to about 3 or 4 bytes, which made a big difference at a time when so many packets were still squeezing through narrow telephone lines.

But the challenges the Internet is facing today are very different, and call for a much broader solution, Jacobson believes. He argues that the global computing network was never designed to carry exabytes of video, voice, and image data to consumers’ homes and mobile devices, as it’s now doing, and that it will never be possible to increase wireless or land-line bandwidth fast enough to keep up with demand. In fact, he thinks 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.

Jacobson’s alternative is called Content Centric Networking, or CCN, and it’s grown into the single biggest internal project at PARC, the Xerox-owned research center that’s famous as the birthplace of graphical computing, laser printing, and the Ethernet standard. If the ideas behind CCN were broadly adopted, PARC researchers believe, it would speed the delivery of content and vastly reduce the load on the networking equipment at the Internet’s core.

It would also pose a challenge to the model of utility-style storage and processing that’s come to be known as cloud computing. And that 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 just the kind of revolutionary idea that has remade Silicon Valley at least four times since the 1960s. And this time, PARC doesn’t want to miss out on the rewards.

“When there is widespread adoption of CCN there will be lots of opportunities to build valuable businesses on top of it that are really impossible to foresee today,” says Teresa Lunt, vice president of PARC’s Computing Science Laboratory. “The main reason we’re investing is because we’re in love with the technology, and we want CCN to make it out into the world…[but] we know that PARC will be able to participate in the upside as well.”

Replacing “Where Is It?” with “Who Wants It?”

To understand why Content Centric Networking is so different, you have to start by looking at today’s Internet, which was designed back in the days when there were only a handful of machines that needed to talk to each other, and the network was used mainly for short bursts of point-to-point communication. In this established scheme, every piece of content has a name, but to find it you have to know in advance where it’s stored—which means the whole system is built around host identifiers and file hierarchies like (The first part of that URL gets translated into the IP address, which leads to the server at St. Louis, MO-based Contegix where Xconomy’s content database is hosted. The rest refers to the sub-sub-sub-folder on that server where WordPress, our content management system, stored this page.)

The fundamental idea behind 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. Rather than transmitting a request for a specific file on a specific server, a CCN-based browser or device would simply broadcast its interest in that file, and the nearest machine with an authentic copy would respond. File names in a CCN world look superficially similar to URLs (for example, /…) but the data in a name is used to establish the file’s authenticity and provenance, not to indicate location.

It’s easy to see how much sense this makes compared to the current client-server model. Say I’m using my Apple TV box to browse my Flickr photo collection on my big-screen TV. To get each photo, the Apple TV has to connect to Flickr, which is hosted on some remote data center owned by Yahoo—it could be in Utah or North Carolina, for all I know. The request has to travel from the Apple TV over my Wi-Fi network, into Comcast’s servers, then across the Internet core, and finally to Yahoo. Then the photos, which amount to several megabytes each, have to travel all the way back through the network to my TV.

But the photos on Flickr are just copies of the originals, which are stored on my camera and on my laptop, about 15 feet away from my TV. It would be much smarter and more economical if the Apple TV could simply ask for each photo by name—that is, if it could broadcast its interest in the photo to the network. My laptop could respond, and I could keep browsing without the requests or the data ever leaving my apartment. (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.)

“The simplest explanation is that you replace the concept of the IP address as the defining entity in the network with the name of the content,” says Lunt. “Now all the talk in the network is about ‘Have you seen this content?’ and ‘Who needs this content?’ as opposed to ‘What is the routing path to particular terminus in the network?’ It’s a simple idea, but it makes a lot of things possible.”

For example, now that memory is so much cheaper than when the Internet was first built, it’s becoming more economical to cache popular content at many places throughout the network. This minimizes the distance content has to travel to reach end users, and hence the amount of bandwidth consumed. Lunt uses a real-world analogy. “It used to be that if you had a store and you needed a product, you called up the factory for delivery and they sent a truck,” she explains. “That model works for a small business in one town, but it doesn’t scale up to a nationwide or global network. So people have built warehouses where you can cache a lot of stuff, and then people order from the nearest warehouse. You can have a very efficient system without having to go back to the factory for each order.”

Similarly, in a content-centric network, if you want to watch a video, you don’t have to go all the way back to the source, Lunt says. “I only have to go as far as the nearest router that has cached the content, which might be somebody in the neighborhood or somebody near me on an airplane or maybe my husband’s iPad.”

Of course, caching data at different points in the network is exactly what content distribution networks (CDNs) like Akamai do for their high-end corporate clients, so that Internet videos will start playing faster, for example. But in a content-centric world, Lunt says, the whole Internet would be a CDN. “Caching becomes part of the model as opposed to something you have to glue onto the side.”

Tinkering with Applications

Computer scientists have been discussing the idea of name-based (as opposed to location-based) networking since the 1970s. But the proposal began to pick up steam in 2006. That’s when Jacobson, who’d done stints as head of the Network Research group at Lawrence Berkeley National Laboratory and as chief scientist at Cisco Systems and Packet Design, joined PARC to lead a new Content Centric Networking research program.

PARC had been operating as a contract R&D lab—independent of Xerox, but wholly owned by it—-since 2002. Its business model is to build internal intellectual property and expertise, often with the help of government funding and university collaborators, and then to get the technologies to market through spinoffs or commercialization agreements with industry partners. In 2006, for example, PARC licensed some of its natural language search technology to a spinoff called Powerset, which was acquired by Microsoft in 2008 for $100 million.

In 2009, after three years of design work, Jacobson’s team released CCNx, an open-source software implementation of the protocols needed to build research-stage content centric networks. The next year they released an Android version of CCNx, optimized to run on smartphones, and joined the Named Data Networking (NDN) initiative, a network of 11 university labs that won $8 million in National Science Foundation funding for further development of the CCN idea.

It’s unlikely any of that could have happened if Jacobson had tried to develop his ideas inside a company like Cisco or Packet Design. “Having worked at both large companies and startups, I came to PARC to make Content Centric Networking a reality,” Jacobson said in a 2010 statement. The lab “understands the importance of openness and collaboration to achieve success for new network architectures,” he said.

In that vein, PARC hosted the first meeting of the Emerging Networks Consortium this spring. It’s a group of big companies like Alcatel-Lucent, BT, France Telecom-Orange, Huawei, Panasonic, and Samsung who want to experiment with CCN technologies and have agreed to share what they’re learning. “That has been a good validation for us that it’s not just us or the academic sector” who are interested in CCN, says Jatinder Singh, PARC’s director of mobile innovation strategy. “A lot of these industries are actively tinkering with use cases they might want to implement.”

What might those cases be? To be clear, no one is talking yet about replacing the existing Internet with a content-centric system. That would be impractical, not to mention expensive. (And in practice, a new networking standard would probably be implemented as an “overlay” on the existing TCP/IP-based Internet, just as the Internet started out as an overlay on the telephone network.) Rather, Lunt and Singh say the CCN approach is likely to turn up first in specific applications on the edges of the network. Then, if it’s successful enough, it might filter back toward the center.

The world of wireless medical devices is one area PARC is eyeing. The traditional TCP/IP-based approach would be to equip these devices to connect to the Internet via Wi-Fi; collect their data on a centralized server; then retrieve the data from PCs or smartphones. But that comes with privacy and security hazards—and there are no common standards yet for formatting or exchanging medical data. “The medical device ecosystem is sort of fragmented,” says Singh. “You have vendors producing blood pressure monitors and scales and glucose meters, but so far there isn’t a clear mechanism for aggregating data across those devices.”

On top of that, it’s overkill to send health data up to cloud servers if it’s only needed within the confines of a single home or clinic. Imagine, instead, that your CCN-equipped smartphone is constantly polling your scale, your sleep monitor, and all your other home health devices for new data. Then when you visit your doctor, the office network pulls the stored data directly from your phone. “Using smartphones as hubs, we are looking at how CCN can allow data to be gathered, contextualized, and shared in a secure fashion,” says Singh.

Members of the Emerging Network Consortium also have some very different applications in mind, including using CCN-based networks to ease the burden on cellular networks. That could work either by using CCN-based networks for “backhaul” of data between wireless towers, or by offloading mobile data from 3G and 4G networks onto CCN-based Wi-Fi networks. “Voice over CCN” is another possibility, as are lighting and environmental control systems for buildings and home media sharing—pairing TVs, PCs, tablets, and smartphones with one another without the need for a central Wi-Fi hub.

Twitter Without Twitter, Facebook Without Facebook

If it all sounds very speculative, that’s because it is. At this stage, companies like Samsung may be investigating CCN mainly as a hedge against uncertainty. “The technology industry is so fast-paced that they know that whatever their cash cow is this year, in five to 10 years it’s going to be something else,” says Lunt. “They have to be constantly looking for the next big thing … Samsung makes equipment for carriers, they make handsets, they make consumer devices. CCN could mean a whole new set of businesses for them.”

But Content Centric Networking could also mean a whole new set of challenges for companies in the content business. Apple, Amazon, Microsoft, Facebook, Google, Twitter, Netflix, and their ilk have spent hundreds of billions of dollars building siloed, centralized, proprietary storage and distribution infrastructures, designed wholly around the client-server model and often reachable only via tollbooths like the iTunes Store or Xbox Live. (See my colleague Greg Huang’s recent take on the Four Horsemen of the Consumer Apocalypse.)

In a CCN world, consumers would probably still have to look at ads and pay for movies, music, books, apps, and the like, but they might not be so dependent upon a few giant cloud operators.

“One of the things that’s intriguing about not having to go to the source is that you could start to think about implementing applications differently,” Lunt says. “You could build apps that don’t have any notion of a server at all. So you could have Twitter without Twitter or Facebook without Facebook—that is, without having to have a major investment in hosting content, because the network is caching it all over the place.”

Such architectures might give users more control over privacy and security of their data, and let them share their own data across devices without having to go through proprietary services like Apple’s iCloud, PARC executives say.

“What Apple is trying to do with iCloud is to say: You shouldn’t have to care which device you got an app on, or which device you took a photo on, whether it was your iPad or iPhone or MacBook Air. You just want your content to be on the other devices when you want it,” says Steve Hoover, CEO of PARC. “That validates our vision. But the way they are solving that puts more load on the network than it needs to, and it requires consumer lock-in. So Apple may be a user of this [CCN] technology one day, because it will make it easier. On the other hand, they could also hate it, because it will make it a lot easier for other people to provide that capability of getting the content whenever you want.”

Already, there’s at least one startup, Cambridge, MA- and New York-based Silver Lining Systems, that says it’s using concepts from Content Centric Networking to solve performance problems in data centers and virtualized computing environments. (The company includes former Verizon, Netezza, and Endeca executives, according to the Boston Globe. It isn’t working directly with PARC.) The CCN initiative could eventually lead to PARC spinoffs as well, though nothing formal is in the works. “There could be a B2C play, an Akamai for consumers,” Hoover speculates. “Right now, for example, I have photos on Photobucket, Shutterfly, and Flickr, and I have to think about where those photos are before I can go get them. Somebody could build a CCN layer that interfaces with every photo-sharing service out there, and every time you upload a photo, they manage that for you.”

How much might consumers be willing to pay for such a service? It’s hard to know until someone builds it. Hoover says PARC’s job is to help companies move in that direction.

“When Bob Metcalfe sat in this building and drew Ethernet on a paper napkin, there wasn’t even an Internet, so nobody could have predicted that the business model [for the Internet] was going to be Google search and advertising,” Hoover says. “We can sit here and speculate about where the tollbooths will go, but to me, it’s more about whether there are pockets of money out there ready to address problems that people have now. The tollbooths will go where they need to be.”

Wade Roush is a freelance science and technology journalist and the producer and host of the podcast Soonish. Follow @soonishpodcast

Trending on Xconomy

By posting a comment, you agree to our terms and conditions.

21 responses to “The Next Internet? Inside PARC’s Vision of Content Centric Networking”

  1. hhemken says:

    “How much might consumers be willing to pay for such a service?”

    We all know the answer: Nothing. They (we) will want to pay nothing. Somebody else will have to pay for that vast new caching infrastructure. Now that web advertising seems to be collapsing, the “who pays for it?” question seems like an enormous gaping hole in the model.

  2. patpentz says:

    this would also be great for a email address replacement (and physical mail). Instead of addresses like [email protected] or ‘John Doe, 130 Park Place, Denver, CO’, we would simply send email or physical mail to ‘John Doe’; additional text to select only the correct John Doe. Change of address becomes trivial, and transparent to others. Actual address is hidden, also.

    • H. says:

      Never mind replacing email addresses – it could easily replace email itself (just to give one example). Just write some text in your favourite word processor, set it to be accessible by your good buddy John Doe, then sit back and relax while the document is automatically stored in the internet-based cloud and John scribbles his response on top of it. Want to do IM too? Just type faster. Security? Standard. Top quoting? Redundant. And no more ‘your message was rejected because your attachments were too big’ either. All the benefits of email and IM combined; none of the current jumping-through-hoops drawbacks. I imagine the MS Outlook team wouldn’t be too happy, but hey, can’t please everyone.

  3. R. says:

    This article feels like reading about the Internet in the late 90s. Aside form the smartphone-based, personalized edge applications, how is this proposal different from the existing CDN industry? Very few big companies use a purely centralized model anymore. They’re all using Akamai or one of its competitors.

    • H. says:

      In addition to being standards-based rather than vendor-specific, the really big difference it that scales all the way from the giant video distributors all the way down to individual users. Instead of a content provider having a single master server and relying on a bunch of ‘dumb’ cache servers dotted around the world to reduce latency, you treat all servers as equal peers, replicate data across them according to whatever propagation rules are appropriate and rely on crypto where necessary to determine who has rights to access a particular resource. It’s a bit like the difference between centralized source control systems like Subversion and distributed ones like Git – the latter blast the former out of the water for power, flexibility and multi-user support.

      I’m a little surprised the Parc folks didn’t mention the next logical step. Today’s consumer desktops are becoming more and more like a miniature version of the internet itself: a random assortment of untrusted applications, each sandboxed to prevent it causing mischief amongst the file system and its peers. In addition, users themselves are moving away from owning a single general-purpose PC to possessing multiple task-optimised devices (smartphone, tablet, smart TV, games console, NAS, etc). Apply the same “describe what it is, not where it’s stored” philosophy to users’ files, and various problems such as having ready access to your data from any of your devices, worrying about whether or not your backups are up-to-date, or viewing a document’s entire change history become non-issues: your data gets replicated and secured across your devices/home cloud/internet cloud according to whatever standard rules you specified when you set your network up. This might even be a better way for CCN to get its foot in the door: start at the individual user level and gradually work up.

      So, lots of opportunity to radically consolidate and simplify how consumer computing works today. It’s mostly a matter of working out the practical implementation issues (synchronization and security models, etc.), and figuring how the heck to get major vendors like Apple and Microsoft and Facebook and Twitter to buy in when so much of their current business models are based on user lock-in and system balkanization. But if anyone can figure it, I reckon the Parc folks can.

  4. Rob Raisch says:

    We looked pretty extensively at the idea of authoritative naming of resources back in the early 90’s while developing the IETF “Uniform Resource Names” draft – see – and came to the conclusion that the idea of truly authoritatively naming a resource wasn’t really viable because we couldn’t think of a reasonable way to name things *authoritatively*.

    To illustrate, assume I write an article entitled “Authoritative Naming Won’t Work” and name it “robraisch/articles/no_authoritative_names” and later, I discover and fix a typo.

    Is my article now a different version of the original or simply a correction to the existing version? At what point do changes to my article require a new name?

    If my changes do require that I republish my article with a new name, what happens to any external references that might exist to the resource by its original name?

    What happens if changes I make invalidate references to it by external agents that rely on its original form?

    If I choose to publish my article in text, HTML, PDF, mp3, and SuperFutureDocumentFormat(tm), do I need to make five names for it or only one?

    And most importantly, who decides whether my article has one name irrespective of any changes I may make to it or formats I choose to publish it in?

    In the end, we reached the conclusion that the publisher of a resource must control its name but that doing so couldn’t be considered “authoritative” in any sense other than that which the publisher chose.

    • has says:

      “If my changes do require that I republish my article with a new name, what happens to any external references that might exist to the resource by its original name?”
      One option might be to attach a GUID to the document and let everyone else worry about what names/labels/metadata/whatever they want to associate with that. Or just treat the original name as canonical and alias any subsequent names to that. Once the process of storing and retrieving files is better abstracted over, the software can make such nuts and bolts invisible to users.

      “What happens if changes I make invalidate references to it by external agents that rely on its original form?”
      Isn’t this just the sort of problem hyperlinking was invented for? In such a long-lived system the only constant is change, so use it in ways that accommodate change gracefully instead of fighting it. And as a fallback, there’s always search, of course.

      Also, FWIW, rather than devise a new naming scheme it might just be simplest to retain the existing URL scheme and just tweak the way URLs are treated so that any trusted server which holds a copy of the desired resource can handle them. Technically, the domain and path portions of a URL are supposed to be treated as opaque anyway; it’s just an accident of design that they’re somewhat human-readable, encouraging humans to futz with their internal structure or assign special meaning to it.

      “If I choose to publish my article in text, HTML, PDF, mp3, and SuperFutureDocumentFormat(tm), do I need to make five names for it or only one?”
      This one is dead easy: it’s a complete non-issue once the user is no longer responsible for specifying precisely where the file is stored. The article should appear a single resource which is declared as being available in five different representations. That allows the client to specify the article name and the format they’d most like to get it in, and leaves the server to worry about all the back-end storage and retrieval details.

      See Roy Fielding’s seminal paper on Representational State Transfer, aka REST. It’s just a pity so many web programmers today don’t understand (or misunderstand) it – REST may not solve every problem, but it puts a good dent in quite a few of them.

      • JerryL says:

        Sorry, but this completely hand-waves on the real issues. For example, you say it’s a dead easy to deal with multiple representations of the same document. But what counts as “the same”? Of the list given, the text version will certainly contain only a subset of what might be in the HTML and PDF. At the least, it will be missing formatting; it may well be missing embedded graphics, hyperlinks, what have you. The same, or different? Let’s add to the mix. All those formats are nominally final-form; how about an editable format? The same, or different? How about the same document translated into French?

        REST is a great idea, but ultimately it has problems with exactly the same issue. A given URI is supposed to name “the same thing” over time. But except in rather boring (though important) cases, “the same thing” does *not* mean “the same bytes”, nor even “a semantically equivalent representation of what you got last time”. No, it means “the same resource”, for some abstract notions of “resource” and “the same”. There are many cases where the appropriate definitions of these things are clear – and then REST works well. But there are other cases where the entire difficulty is figuring out what these notions should map to – if they even *have* natural mappings. Absent those, REST gets you nothing very useful.
        — Jerry

        • has says:

          “Sorry, but this completely hand-waves on the real issues. For example, you say it’s a dead easy to deal with multiple representations of the same document. But what counts as “the same”? Of the list given, the text version will certainly contain only a subset of what might be in the HTML and PDF. At the least, it will be missing formatting; it may well be missing embedded graphics, hyperlinks, what have you. ”

          You see this as a problem but it isn’t. It’s the *client’s choice* whether they want to see the full semantic HTML version, the pretty-looking PDF or the bare-bones text version.

          Assuming the document isn’t encrypted, the RESTful approach can provide further benefits too. For example, the server may host a single canonical file and perform the conversions to the lossier formats on the fly. If such conversions are common, the converted formats may be automatically cached for efficiency. This reduces workload on the original author, who only has to save the document in one format then leave the server to worry about the rest.

          “Let’s add to the mix. All those formats are nominally final-form; how about an editable format? The same, or different?”

          Things get a bit spicier once you add editing into the mix. For example, if a client GETs the HTML representation, modifies it and PUTs it back on the server, how should the system deal with the old PDF and text versions? Assuming the system tracks the resource’s full revision history (as a modern content system should), one option is to treat all old representations as the previous revision and declare the uploaded HTML document as the only representation available for the current revision. If versioning isn’t supported, delete the obsolete representations and either let the server regenerate them on the fly (see above) or else leave the author to save and upload the additional formats themselves.

          “How about the same document translated into French?”

          Non-issue again. The server declares which language(s) the document is available in and the client negotiates to obtain whichever representation best suits it.

          “REST is a great idea, but ultimately it has problems with exactly the same issue.”

          REST deals with the file format and language concerns pretty well, as long as you remember it’s all about *client choice*, not about the server imposing its own opinions on the client. Revision tracking needs more thought, but like I say REST should be the starting point, not the complete answer in itself.

  5. Ardyvee says:

    This sounds a lot like freenet, if you ask me.

  6. Volt Lover says:

    The request has to travel from the Apple TV over my Wi-Fi network, into Comcast’s servers, then across the Internet core, and finally to Yahoo.”

    It would be better if the author understood how the Internet works. NO Comcast server is proxying that request

    • Jed says:

      It doesn’t matter if Comcast uses NAT or not, the author is exactly correct. Engage brain next time?

  7. Rob Raisch says:

    Another issue that strikes me as problematic is how Content Centric Networking can be used to support content specific censorship. It’s not unimaginable to consider how Verizon or ComCast might use CCN to restrict their customers access to content from Netflix. One useful aspect of Internet Address-based routing is that “bits is bits” irrespective of their source, they are all equal. In CCN, bits no longer enjoy this opacity because they “belong” to a publisher-identifiable resource.

    • Mark says:

      bits no longer enjoy this opacity because they “belong” to a publisher-identifiable resource.

      Good thought by the way …

  8. He appears to have described BitTorrent with magnet links.

  9. Happy Heyoka says:

    @David Gerard wrote: “He appears to have described BitTorrent with magnet links.”

    My thoughts exactly – the torrent file describes the desired content and a way check that you have a valid copy. You don’t actually care as a user where that content might be. With some support from the infrastructure (eg: anycast) it would kill HTTP bandwidth wise (and maybe speed) for content that is in common and frequent use on a wide scale.

    I suspect that Van has in mind an additional level of indirection; off to read a slightly more technical description…

  10. Now here’s the real question.

    Do you browse the web with bittorrent? No?

    Since the web amounts to a good chunk of the internet, how is the next internet (which won’t be current-web-friendly) be the “Next Internet”?

    Don’t get me wrong, the research some scientists are doing is commendable. The hype some people come up with? Not at all.

    Especially from a guy that doesn’t know the difference between file on a server and URL rewriting (AKA routing).

  11. Lawrence says:

    First of all, the Internet did not use TCP/IP in 1985 – it used UUCP until the laet 1980’s, so what are you talking about ??

  12. Thanks for all of that mould breaking info/intelligence, Wade. It is good to hear that not all are content with things as they are, whenever they can and need to be better in Beta Virtual Programs, …. SMARTR Future AI Works in Immaculate Stealthy Progress.

    “Similarly, in a content-centric network, if you want to watch a video, you don’t have to go all the way back to the source, Lunt says. “I only have to go as far as the nearest router that has cached the content, which might be somebody in the neighborhood or somebody near me on an airplane or maybe my husband’s iPad.””

    For leading original novel content-centric networks though, in order that one can lead in a CHAOSystem*, one will always need to feed and seed a direct, and ideally exclusive connection to source, to ensure there is no conflict and cross interference with competition or opposition, although it is as well to consider that in such networks, is it the nature of the leading original novel content itself, which sublimely delivers all of that effortlessly and invisibly and anonymously.

    Words Shared Create and Control Worlds in and for Worlds in Control of Creation with Shared Words ……. which is a Fabulous Fact and an Outrageous Fiction which does not Suffer Fools to Use and Abuse and Misuse ITs Tools.

    * Clouds Hosting Advanced Operating Systems

  13. unwesen says:

    As other people have commented, this is basically a P2P network with some awareness of network locality. Been done, except of course *on top of* IP, rather than to replace IP.

    [Interesting side note: the article is unclear about whether they want to replace TCP or IP as well. Replacing IP might not be feasible. Replacing TCP with a content addressable networking protocol is different.]

    The main issue with this approach is that as a user, you want to know that the copy of the file you want is authentic and up-to-date. That means you’ll probably need a signature for the file, and be able to verify the signature. That means, at some point, you need to contact the source for an authoritative hash of the file, and possibly their current public key (which I’d expect to be signed by other parties in a web of trust-like way).

    Again, though, this has been done in P2P networks.

    I’m all for this kind of approach, but I can’t bring myself to think if it as particularly new. In fact, this is pretty much exactly (in concept) what we did at Joost to distribute video more efficiently.