Content-Centric Networking.

[C. Scott Ananian]

On Fri, Feb 18, 2011 at 12:28 PM, Michael Stone <michael at laptop.org> wrote:

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


IP-based routing has a lot of known problems, especially wrt firewalls, and
so does DNS (I think the strongest kickback on the Network Principles was
the idea of giving each school its own domain name).  So I think there is
some latitude for trying new stuff within the school *as long as it is
interoperable with the outside world*.  Our existing XMPP is not
interoperable, and our DNS is unimplemented.  So it's not hard to do better.

The real opportunity is to partner with a research group and multiply OLPC's
efforts.  Basically, we *must* use something which other people are working
on.  If we can't find "others" interested in working on CCNx, then we must
use DNS, etc -- although we haven't been too successful in finding people
who want to work on *those* in the ways OLPC would like to use them, either.

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?


New CCNx router == school server.  The router is the primary place where
content is cached.  There are over-IP hops to other school servers.  It does
depend critically on how interoperation with "legacy networks" is done.  It
seems that they have a reasonable story for this, falling back to direct
connections when no "CCNx router" is available.  I agree we could use more
details, but the fact that they have working Android implementations (which
must work with the vagarities of carrier networking) seems to be a
proof-by-example that this is not an insurmountable problem.

Remember that the Network Principles document also posits new "routers" --
but in that case, they were IPv6 routers (called 'tunnels' in the spec).
 Basically, disconnected and mobile operation, coupled with IPv4 firewalls
and NAT, means that some network router infrastructure (aka, connecting
school servers to each other, or to the globally-routable internet) is
required in any case.  The question is what those routers look like.

(A few years ago I also looked at the idea of making those 'routers' look
like bittorrent clients, which basically uses DHT techniques to route
content between schools.  Lots of different ideas; the trick is in
interoperability, transparency, and deployment.)

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

Yes, but it would potentially allow content to be aggregated over several
caches more easily (ie, you don't have to store the entire cache on one
machine), and solves some of the DNS issues more cleanly (no one has to look
up DNS and make a connection to an arbitrary IPv4 or IPv6 address, as in
Network Principles).  So far this is more of a replacement than an
improvement.

The improvement would be for stuff kids publish, which now doesn't need to
be discoverable via a fixed IPv4 or IPv6 address.  As long as it has a CCNx
'name' it can be reached/cached/etc in the same way as the rest of the web
content.  So now the school server can fulfill its role in storing kids'
assignments in the same way it is storing web content.  And discovery can
now be done via CCNx as well.  It's reducing a number of different
mechanisms into one.

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."
>
> ?


Yeah, something like that.  I mean, "with this, you can consider replacing
all of the laptop's standard networking/collaboration/discovery with CCNx
mechanisms.  Without a way to get to the web, you can't jettison TCP."

In general I'd probably require an email gateway as well -- but I don't
think the situation on email-on-XO has changed since we worked there.
 (Please correct me if I'm wrong.)


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


I'm much less concerned with this.  It's a general problem for CCNx,
perhaps, but I haven't seen evidence that privacy issues are in fact a large
*present* issue with XOs.  My qualifications for any new technology is only
that it does better *than we do now*, not that it be perfect.

Bonus points, of course, if a technology looks like it can eventually do all
the things we would like it to do.  But I'm not willing to be dogmatic about
that.  I think it's important to realize that progress toward a goal is
going to take place in a greater-than-one number of paradigm jumps as well
as periods of gradual improvement.


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


My impression from reading the papers is that Van Jacobson knows a lot more
about routers and routing than I do.  As such, he's willing to delegate a
certain amount of complexity to the router protocols (including a full
machine language for describing routing rules) which others try to hoist to
the application level.  I don't know that that's necessarily the answer to
your problem, but I think it's an interesting (and probably not
unreasonable) approach.


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

My criterion is simple: are the CCNx folk willing to work on OLPC use cases?
 If they are interested in the problems OLPC's deployments present, and
present us with some implemented solutions they think will help, then I
think OLPC would be wise to attempt to adopt and deploy them, even in a
piecemeal or experimental manner.  It seems to me that there could be
commonality of interest, and growing the number of people working to solve
OLPC's problems is always a good thing.
  --scott

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