<br>Would it be useful to discuss requirements from scratch?<br><br><div class="gmail_quote">On Wed, Jun 20, 2012 at 2:13 PM, John Gilmore <span dir="ltr"><<a href="mailto:gnu@toad.com" target="_blank">gnu@toad.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">> My wife and I are walking in mall with at least one other person every<br>
> 40 feet or so. We decide to separate and go shopping. I walk this way,<br>
> she walks that way. Before long we're out of direct WiFi communication<br>
> range to each other. Now, if enough people there in the mall had<br>
> WiFi-enabled devices running some mesh software, I'd like to be able to<br>
</div>> stay in contact with my wife as she moves about in her random way, and<br>
<div class="im">> as they all move about in their random ways.<br>
<br>
</div>The One Laptop per Child project also wanted to satisfy this goal.<br>
They wanted kids all over a village to be able to reach each other and<br>
to reach the Internet via a gateway at their school. They had the<br>
advantage of designing and building both the hardware and software.<br>
But they failed, partly due to system integration issues.<br>
<br>
They were using a buggy implementation of 802.11 meshing that preceded<br>
802.11s. But they also used higher level user interface software,<br>
which used multicast packets to find and communicate with other nearby<br>
laptops. The mesh software worked poorly with multicast. Not only<br>
did it send multicasts at the slowest speed (1 megabit), which took up<br>
a lot of airtime, but the various nodes would repeat the multicasts to<br>
make sure that every node had heard them. This limited the size of<br>
the network that they could scale to. They did not discover this<br>
unfortunate interaction until very late in the<br>
hardware/software/firmware integration process (when the<br>
multicast-based application sharing software started working).<br>
<br>
Another major problem was that a mesh network is very hard to<br>
reproduce. If it does something unexpected or suboptimal, the<br>
developers can't just teleport themselves to the part of the world<br>
where that particular physical configuration of radio nodes, physical<br>
antennas, software versions, and firmware versions exists. In many<br>
cases they can't even reach into the nodes of that network over the<br>
Internet while the problem is happening, to debug it. Many, many OLPC<br>
mesh problems occurred in the field which could not be replicated in<br>
the lab, which made them 10x or 100x harder to fix. This meant that<br>
buggy mesh network firmware and software didn't improve at the usual<br>
rate (of the rest of their software).<br>
<br>
The result was that despite a lot of work addressing bugs and<br>
performance in the mesh firmware, they never got their automatic mesh<br>
network working with more than a handful of XO laptops. If you put 30<br>
laptops in a classroom, they would burn up 100% of the radio bandwidth<br>
(and chew up their batteries) merely with overhead packets ("Hi, i'm<br>
here." "Hi you, I'm me; have you heard about Joe and Alice over<br>
there?" "In case you want to send a message to Joe, send it via me to<br>
Alice; I can hear Alice just fine."). There was no bandwidth left for<br>
the users to actually communicate; connections would time out, nodes<br>
would appear and disappear from the mesh, etc. So OLPC stopped using<br>
the mesh and recommended that each classroom install one or more<br>
802.11 access points. Which has worked ok. They also switched to<br>
support ad-hoc 802.11 without meshing, for automatically networking "a<br>
few students sitting around under a tree", which also works ok.<br>
<br>
There ARE some mesh networks that I hear are working on a larger<br>
scale, such as B.A.T.M.A.N. I suspect that the large scale meshes are<br>
in largely static networks that are tuned by humans to work well (just<br>
as the broader Internet's routing system is tuned by humans to work;<br>
it's not automatic). I do not know if other meshes support multicast<br>
(or other portable ways for high level software to find what nodes are<br>
on the network), nor whether they work in a network of mobile nodes<br>
with limited battery life. All I can report on is the one project I<br>
was involved in (OLPC), in which their mesh implementation failed to<br>
accomplish its goals, and was dropped from the next generation<br>
hardware and software.<br>
<br>
This is part of why I recommend using wired connections wherever<br>
possible. For FreedomBox to succeed, it needs to succeed at scale. A<br>
FreedomBox network that can't route packets for more than 500 nodes<br>
worldwide wouldn't be worth building. (Clue: this is why the Internet<br>
exists today: it scaled up and kept working, while the proprietary<br>
networks that preceded it didn't scale up to worldwide scale.) In a<br>
substantial network, your mesh and dynamic routing protocol could<br>
require a few megabits of traffic at all times on each node, just<br>
keeping track of everything. Over a 100-megabit Ethernet that's just<br>
2 or 3% of the bandwidth. But over 802.11, that burns up most of the<br>
available bandwidth. Every connection you move off wireless onto a<br>
wire makes more radio bandwidth available for the folks who truly<br>
can't run a wire.<br>
<br>
I have some ideas about how FreedomBox nodes could provide censorship<br>
resistant networking via running an overlay IPv6 network using<br>
geographically based addressing to simplify the routing problem. I'll<br>
dig those up and repost them in the next few days. It isn't an<br>
automatic mesh, though; it has explicit connections made by humans<br>
among friendly nodes. The part that's automatic is how the packets<br>
flow after the humans make those connections.<br>
<span class="HOEnZb"><font color="#888888"><br>
John<br>
</font></span><br>
PS: If you think a mesh protocol shouldn't use even a megabit/second<br>
of continuous overhead, please design and build one that doesn't,<br>
and that scales up and keeps working. It's harder than it looks.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Freedombox-discuss mailing list<br>
<a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><i>Ramen.</i><br>