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