Rick, These are mine: The mesh network should be able to route packets from any geographic location to another, merely by knowing where it (itself) is, where the packet came from and where it's going. There are certain aspects of forward-transmissions for packets each FBX would have to maintain for a period time in case one or more of the FBXs fell off the mesh and are no longer available, which would require re-routing through a less-than-optimal route, although given the circumstances of the FBX "holes" that now exist in the living, dynamic mesh, perhaps may NOW actually be THE optimal route. I think getting away from IP addresses (except as mechanical means to coordinate with FBX devices that indicate they're "over there in the direction I want to send stuff"), and going entirely with geographic addresses will solve everything. There is still the issue of geographic identity for a roaming target, but I think a lifetime relative to the nature of the roaming speed for nearby FBXs would solve that as well. We'll see. I could be wrong. Probably am. My hard-headedness and stubbornness will mandate that I prove it to myself though, which I may well do this weekend. Ever see a 42-yr old man eat crow on a mailing list? Stay tuned... I might just do that come Sunday evening! :-) LOL! Best regards, Rick C. Hodgin On 06/20/2012 02:21 PM, Rick wrote:

Would it be useful to discuss requirements from scratch?

On Wed, Jun 20, 2012 at 2:13 PM, John Gilmore mailto:gnu@toad.com> wrote:

> My wife and I are walking in mall with at least one other person every > 40 feet or so. We decide to separate and go shopping. I walk this way, > she walks that way. Before long we're out of direct WiFi communication > range to each other. Now, if enough people there in the mall had > WiFi-enabled devices running some mesh software, I'd like to be able to > stay in contact with my wife as she moves about in her random way, and > as they all move about in their random ways.

The One Laptop per Child project also wanted to satisfy this goal. They wanted kids all over a village to be able to reach each other and to reach the Internet via a gateway at their school. They had the advantage of designing and building both the hardware and software. But they failed, partly due to system integration issues.

They were using a buggy implementation of 802.11 meshing that preceded 802.11s. But they also used higher level user interface software, which used multicast packets to find and communicate with other nearby laptops. The mesh software worked poorly with multicast. Not only did it send multicasts at the slowest speed (1 megabit), which took up a lot of airtime, but the various nodes would repeat the multicasts to make sure that every node had heard them. This limited the size of the network that they could scale to. They did not discover this unfortunate interaction until very late in the hardware/software/firmware integration process (when the multicast-based application sharing software started working).

Another major problem was that a mesh network is very hard to reproduce. If it does something unexpected or suboptimal, the developers can't just teleport themselves to the part of the world where that particular physical configuration of radio nodes, physical antennas, software versions, and firmware versions exists. In many cases they can't even reach into the nodes of that network over the Internet while the problem is happening, to debug it. Many, many OLPC mesh problems occurred in the field which could not be replicated in the lab, which made them 10x or 100x harder to fix. This meant that buggy mesh network firmware and software didn't improve at the usual rate (of the rest of their software).

The result was that despite a lot of work addressing bugs and performance in the mesh firmware, they never got their automatic mesh network working with more than a handful of XO laptops. If you put 30 laptops in a classroom, they would burn up 100% of the radio bandwidth (and chew up their batteries) merely with overhead packets ("Hi, i'm here." "Hi you, I'm me; have you heard about Joe and Alice over there?" "In case you want to send a message to Joe, send it via me to Alice; I can hear Alice just fine."). There was no bandwidth left for the users to actually communicate; connections would time out, nodes would appear and disappear from the mesh, etc. So OLPC stopped using the mesh and recommended that each classroom install one or more 802.11 access points. Which has worked ok. They also switched to support ad-hoc 802.11 without meshing, for automatically networking "a few students sitting around under a tree", which also works ok.

There ARE some mesh networks that I hear are working on a larger scale, such as B.A.T.M.A.N. I suspect that the large scale meshes are in largely static networks that are tuned by humans to work well (just as the broader Internet's routing system is tuned by humans to work; it's not automatic). I do not know if other meshes support multicast (or other portable ways for high level software to find what nodes are on the network), nor whether they work in a network of mobile nodes with limited battery life. All I can report on is the one project I was involved in (OLPC), in which their mesh implementation failed to accomplish its goals, and was dropped from the next generation hardware and software.

This is part of why I recommend using wired connections wherever possible. For FreedomBox to succeed, it needs to succeed at scale. A FreedomBox network that can't route packets for more than 500 nodes worldwide wouldn't be worth building. (Clue: this is why the Internet exists today: it scaled up and kept working, while the proprietary networks that preceded it didn't scale up to worldwide scale.) In a substantial network, your mesh and dynamic routing protocol could require a few megabits of traffic at all times on each node, just keeping track of everything. Over a 100-megabit Ethernet that's just 2 or 3% of the bandwidth. But over 802.11, that burns up most of the available bandwidth. Every connection you move off wireless onto a wire makes more radio bandwidth available for the folks who truly can't run a wire.

I have some ideas about how FreedomBox nodes could provide censorship resistant networking via running an overlay IPv6 network using geographically based addressing to simplify the routing problem. I'll dig those up and repost them in the next few days. It isn't an automatic mesh, though; it has explicit connections made by humans among friendly nodes. The part that's automatic is how the packets flow after the humans make those connections.

John

PS: If you think a mesh protocol shouldn't use even a megabit/second of continuous overhead, please design and build one that doesn't, and that scales up and keeps working. It's harder than it looks.

_______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org mailto:Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss

-- /Ramen./

_______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE