Content-Centric Networking.

[Michael Stone]

On Fri, 18 Feb 2011 at 11:00:52 -0500, "C. Scott Ananian" <cscott at cscott.net> wrote:
> Recapping for the list: Jim Gettys sent me a pair of papers to read
> yesterday, both linked from
> 
>   http://www.ccnx.org/content/content-centric-networking-resources
> 
> 1) V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,
> R. L. Braynard (PARC) Networking Named Content, CoNEXT 2009, Rome, December,
> 2009.
> 
> 2) V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. Stewart, J. D.
> Thornton, R. L. Braynard, VoCCN: Voice Over Content-Centric Networks, ReArch
> '09, Rome, December, 2009.
> 
> This is very interesting work, and offers an alternative to
> 
>   http://wiki.laptop.org/go/Network_principles
> 
> In my mind, the best reason to continue to use DNS and IP routing to locate
> resources (as in the Network Principles document) is that deployments
> understand them. 

In my mind, a stronger reason for sticking with XMPP, HTTP, DNS, and IP is that
XMPP, HTTP, DNS, and IP are standardized technologies with multiple
interoperating free implementations. 

CCNx seems unlikely to reach this level of maturity in the near future (e.g.,
the next three years). 

On the other hand, if you're thinking about the problem further out than the
near future, then I have more interest in the suggestion.

> However, the CCNx approach could offer significant
> bandwidth benefits, and potentially works better in the "kids go home from
> school" case (the Network Principles document requires IPv6 tunnels to solve
> this mobility problem).

CCNx-over-ethernet will likely require ISPs to install new routers, no? 

And won't CCNx-over-IP will have the same mobility problem that your Network
Principles were designed to solve?

> I think the CCNx ideas would be worth exploring, but OLPC would need active
> participation from the PARC CCNx folks.  OLPC role would be
> integrator/deployer, *not* developer or researcher.
> 
> So, with that in mind, the greatest missing piece I see is an HTTP gateway.

Agreed.

> Here's how it would work:  CCNx content bundles with a specially-formed name
> (like http/url/here) would get routed by specially-aware content routers
> over legacy HTTP.  The contents, once fetched, would be stored in the CCNx
> network like all other content, making it a big web cache.  Running such a
> CCNx gateway on the school server would turn it into the web cache we've
> always dreamed of (and which perhaps has been implemented in the past two
> years?). 

Why will a CCNx cache be more effective than a plain old HTTP cache?

(i.e., aren't the constraints on memory usage, disk usage, and network
bandwidth going to be fairly similar?) 

> This would let all of the laptops "talk pure CCNx" to each other,

This seems too strong. Perhaps you mean that 

   "This is one small but important node on the critical path to a functioning
   laptop-borne CCNx network that preserves web access."

?

> without losing web access, and make the web behave better when machines are
> disconnected.
> 
> For bonus points, the CCNx routers would use something like rproxy (
> http://rproxy.samba.org/doc/protocol/protocol.html) when searching for
> content from other CCNx routers, so that "slightly changing" content such as
> is found more typically on the web is still highly cacheable, and we get
> even more bandwidth improvement.

This suggestion is worth forwarding to ccnx-dev at ccnx.org -- I would be
interested to hear their reaction.

> Both rproxy and the HTTP gateway are development projects; they're probably
> even research projects, since it's not immediately clear how HTTP's caching
> semantics (which need to be honored) translate into the CCNx namespace.  I
> don't think it's a good idea for OLPC to do research projects, but if Van
> and his team are enthusiastic about collaboration, I'd hope that OLPC would
> be willing to integrate and deploy his ideas.  The win for OLPC would be
> network bandwidth, which is a huge deal for the developing world; with
> solutions to some "resource discoverability" issues a secondary
> consideration.

There's also the issue of the communications security story for CCNx. (To their
credit, the CCNx folks have clearly indicated that this story is unfinished.)

> Note that the two papers I've read so far don't really address the resource
> discovery and naming issue. They make some suggestive remarks, such as "We
> are also developing higher level name discovery mechanisms that are more
> efficient for exploring large name spaces" (Networking Named Content, page
> 4).  That's another area of concern for me.  As we learned the hard way,
> just finding your friends and classmates in a large school can be a
> surprisingly difficult problem, and CCNx's reliance on multicast with a
> casual reference to "standard multicast suppression techniques" (Networking
> Named Content, page 3) causes me concern.  But I'm sure OLPC would be more
> than willing to provide the test cases if they are interesting in proving
> that their name-discovery stuff actually works in the field.  So,
> secondarily to the HTTP gateway, I would suggest the ol' Journal as a
> research area they might like to explore: a collection of ~100 machines,
> each of which has a (unique?) name and a collection of documents sorted by
> date.  The task is to efficiently enumerate your friends or classmates, and
> then look through their shared documents.  Ideally this would work even if
> some of your friends (and their documents) aren't currently in class,
> assuming other students have cached the relevant information.
> 
> (In addition, I would add an indirection layer: my best ideas for solving
> the document collaboration problem involve the notions of "borrowing" vs
> "copying".  So person A can "borrow" some document, make edits (possibly
> with others) and then "return" the borrowed document to the original owner.
>  So when you request document A from friend X, the response might be "friend
> Y is currently borrowing it".  This might involve another request to friend
> Y, with a different document "name" -- or it might involve friend Y
> publishing a document in friend X's namespace.  I'd be very interested in
> hearing the "CCNx way" to approach this problem.  The goal is to simplify
> the multi-editor versioning problem by ensuring that there is exactly one
> "owner" at any given time who is responsible for serializing edits.)

I ran into a related problem while trying to figure out how to implement Paxos
on top of CCNx. CCNx's caching and the flow-balance properties (and the tight
binding between names and cache-keys) really seemed to get in the way.

(Also, this is not to say that there isn't a good solution; just that I didn't
find one after searching for a couple of hours.)

> So, bottom line: very interesting work.  Offers some benefits even in an
> isolated "my CCNx network is just this classroom" setting, in terms of
> regularizing content discovery, naming, and caching.  But there are some
> significant research projects still lurking.  

Agreed and agreed.

> I don't think OLPC has the resources to undertake research projects, but I
> would hope that it would be enthusiastic about collaborating if PARC wants to
> explore real-world use cases.

I was sufficiently impressed by the CCNx work when I first saw it to play with
it a bit myself but I don't yet see sufficient advantages to argue in favor of
collaboration if said collaboration comes at the expense of directly improving
other aspects of the networking experience available today -- even improvements
as simple as indicators for school-server presence or "internet connectivity".

Regards,

Michael