Recapping for the list: Jim Gettys sent me a pair of papers to read yesterday, both linked from <a href="http://www.ccnx.org/content/content-centric-networking-resources">http://www.ccnx.org/content/content-centric-networking-resources</a><div>
<br></div><div>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.<br><div>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.</div>
<div><br></div><div>This is very interesting work, and offers an alternative to <a href="http://wiki.laptop.org/go/Network_principles">http://wiki.laptop.org/go/Network_principles</a><br clear="all"><br></div><div>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).</div>
<div><br></div><div>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.</div><div><br>
</div><div>So, with that in mind, the greatest missing piece I see is an HTTP gateway.</div><div><br></div><div>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.</div>
<div><br></div><div>For bonus points, the CCNx routers would use something like rproxy (<a href="http://rproxy.samba.org/doc/protocol/protocol.html">http://rproxy.samba.org/doc/protocol/protocol.html</a>) 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>(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.)</div>
<div><br></div><div>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.</div>
<div>  --scott</div><div><br>-- <br>                         ( <a href="http://cscott.net/">http://cscott.net/</a> )<br>
</div></div>