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>