[prev in list] [next in list] [prev in thread] [next in thread]
List: olpc-devel
Subject: Re: Content-Centric Networking.
From: "C. Scott Ananian" <cscott () cscott ! net>
Date: 2011-02-18 18:18:56
Message-ID: AANLkTinDQNnT8WDzQ4Ereua9=AArBGkMR-VSdE+5ua-F () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Feb 18, 2011 at 12:28 PM, Michael Stone <michael@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/ )
[Attachment #5 (text/html)]
On Fri, Feb 18, 2011 at 12:28 PM, Michael Stone <span dir="ltr"><<a \
href="mailto:michael@laptop.org">michael@laptop.org</a>></span> wrote:<br><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">In my mind, the best reason to continue to use DNS and IP \
routing to locate<br> resources (as in the Network Principles document) is that \
deployments<br> understand them. <br>
</blockquote>
<br></div>
In my mind, a stronger reason for sticking with XMPP, HTTP, DNS, and IP is that<br>
XMPP, HTTP, DNS, and IP are standardized technologies with multiple<br>
interoperating free implementations. <br>
CCNx seems unlikely to reach this level of maturity in the near future (e.g.,<br>
the next three years). <br>
On the other hand, if you're thinking about the problem further out than the<br>
near future, then I have more interest in the \
suggestion.</blockquote><div><br></div><div>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.</div> <div> \
</div><div>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.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> However, the CCNx approach could offer significant<br>
bandwidth benefits, and potentially works better in the "kids go home from<br>
school" case (the Network Principles document requires IPv6 tunnels to solve<br>
this mobility problem).<br>
</blockquote>
<br></div>
CCNx-over-ethernet will likely require ISPs to install new routers, no? <br>
And won't CCNx-over-IP will have the same mobility problem that your Network<br>
Principles were designed to solve?</blockquote><div><br></div><div>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.</div> <div><br></div><div>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.</div> \
<div><br></div><div>(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.)</div> <div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"><div class="im"> <blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Here's how \
it would work: CCNx content bundles with a specially-formed name<br> (like \
http/url/here) would get routed by specially-aware content routers<br> over legacy \
HTTP. The contents, once fetched, would be stored in the CCNx<br> network like all \
other content, making it a big web cache. Running such a<br> CCNx gateway on the \
school server would turn it into the web cache we've<br> always dreamed of (and \
which perhaps has been implemented in the past two<br> years?). <br>
</blockquote>
<br></div>
Why will a CCNx cache be more effective than a plain old HTTP cache?<br>
<br>
(i.e., aren't the constraints on memory usage, disk usage, and network<br>
bandwidth going to be fairly similar?) <br></blockquote><div><br></div><div>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.</div> <div><br></div><div>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.</div> <div><br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> This would let \
all of the laptops "talk pure CCNx" to each other,<br> </blockquote>
<br></div>
This seems too strong. Perhaps you mean that <br>
"This is one small but important node on the critical path to a \
functioning<br> laptop-borne CCNx network that preserves web access."<br>
<br>
?</blockquote><div><br></div><div>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."</div> <div><br></div><div>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.)</div><div> </div> <blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Both rproxy and the HTTP gateway are development projects; \
they're probably<br> even research projects, since it's not immediately clear \
how HTTP's caching<br> semantics (which need to be honored) translate into the \
CCNx namespace. I<br> don't think it's a good idea for OLPC to do research \
projects, but if Van<br> and his team are enthusiastic about collaboration, I'd \
hope that OLPC would<br> be willing to integrate and deploy his ideas. The win for \
OLPC would be<br> network bandwidth, which is a huge deal for the developing world; \
with<br> solutions to some "resource discoverability" issues a \
secondary<br> consideration.<br>
</blockquote>
<br></div>
There's also the issue of the communications security story for CCNx. (To \
their<br> credit, the CCNx folks have clearly indicated that this story is \
unfinished.)</blockquote><div><br></div><div>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.</div> <div><br></div><div>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.</div> <div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"><div><div></div><div class="h5"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> I ran into a related problem while trying to figure out how \
to implement Paxos</blockquote></div></div> on top of CCNx. CCNx's caching and \
the flow-balance properties (and the tight<br> binding between names and cache-keys) \
really seemed to get in the way.<br> <br>
(Also, this is not to say that there isn't a good solution; just that I \
didn't<br> find one after searching for a couple of \
hours.)</blockquote><div><br></div><div>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.</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div><div \
class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> I don't think OLPC has the resources to undertake \
research projects, but I<br> would hope that it would be enthusiastic about \
collaborating if PARC wants to<br> explore real-world use cases.<br>
</blockquote>
<br></div>
I was sufficiently impressed by the CCNx work when I first saw it to play with<br>
it a bit myself but I don't yet see sufficient advantages to argue in favor \
of<br> collaboration if said collaboration comes at the expense of directly \
improving<br> other aspects of the networking experience available today -- even \
improvements<br> as simple as indicators for school-server presence or "internet \
connectivity".<br></blockquote><div><br></div><div>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.</div> <div> \
--scott</div><div><br></div></div>-- <br> ( <a \
href="http://cscott.net/">http://cscott.net/</a> )<br>
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic