Content-Centric Networking.

[C. Scott Ananian]

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.  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).

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.

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?).   This would let all of the laptops "talk pure CCNx" to each other,
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.

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.

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.)

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.  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.
  --scott

-- 
                         ( http://cscott.net/ )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20110218/2373546e/attachment.html>