[Battlemesh] LibreMesh

[Kim Hawtin]

tl;dr. if you are professionals at the top of you game, be thoughtful to 
amateurs and those new in the field. for innovation often occurs in that 
space around the questions "why" and "how". also interoperability is 
just as valuable as elegant internal consistency.

On 17/12/16 02:02, Pau wrote:
> So what's up with 802.11s? Or any other "stupid" link-layer protocols
> which are not part of the WiFi stack? Is it not a mesh network?

from my experience with 802.11s on the OLPC, 's' was not designed to 
scale an actual ad-hoc mesh past a few tens of nodes.

one would have to look at the voting mechanisms of the IEEE and look at 
how the standard fell out to understand why.

> In any case, I would make a difference between "mesh network" and "free
> community mesh network". First one only references to technical stuff,
> second one would refer to also philosophic definition such as
> decentralized, bottom-up, etc.

philosophic versus commercial reality is that networking by 
manufacturers is "about shipping tin". in the old fashioned sense that 
we sell hardware to sell more of our hardware.

this also felt true with how 802.11s was designed to have a couple of 
gateway nodes back to a "real network" or internet connection.

>> You cannot be a true mesh if you don't use ad-hoc mode.

why put an artificial barrier in the way of participation?

>> I agree you can do a mesh over client-AP, but this means some nodes
>> are more important than others, thus have more power in the network.

any serious effort to create a community that does not allow small 
meshes to join larger meshes is missing the point of participation.

in the real world, heterogeneous networks are the norm. people are going 
to recycle what ever hardware they have into the effort.

making homogenous networks is a high barrier to cross when you are 
starting to understand the concepts.

understanding protocols like BGP/OSPF/OLSR/BATMAN/etc is hard enough 
when you are coming to terms with how to deal with RF/gain/path-loss/etc 
and the basic configuring of your network equipment.

one of the difficulties i have faced over and over with community 
wireless groups is which technology we are going to use in the mesh.
ironically protocols like BGP and OSPF seem to function a lot better 
when there is a central body managing the setup of high traffic routing 
nodes.

centralizing administration defeats the purpose of a mesh and stymies 
the learning opportunities of participants. there will always be shining 
counter examples of this. however as homogenous network hardware and 
software may perform better, i do not believe it encourages growth and 
involvement in a community wireless group.

encouraging growth requires you to accept experimental ideas and 
participation in as many ways as possible. encouraging competition 
allows various technologies to advance in ways that were never initially 
designed for or expected. this is the role that battlemesh helps 
communities understand the technologies available to them.

ultimately all of the participants in this process have favorite 
technologies. you will always see meshes of meshes as participants have 
grown up with a particular technologies and implemented in ways they 
understand. if helping them integrate into larger meshes is ultimately 
the goal, maybe the will advance the state of the art, or maybe they 
will adapt what they have just to participate.

in my culture there is a motorsport class called "run what you brung".
there are no prizes, "wins" are purely reputation based. this class is 
by no means conformist, with participants often being early in their 
careers and you can often learn some interesting things from these folk 
who are in the early stages of learning how to make them selves competitive.

you may find this is a strange a simile, but as in motor sport, adaption 
drives adoption in competition. being able to mix and match is what 
enables folks to make the most of the available resources and more 
importantly, to learn.

now moving on, the network or the mesh is sometimes a by-product. the 
application folks need to run over the mesh is the goal, not just the 
infrastructure. sure, some of us want to understand and build beautiful 
networks! be mindful that "this is a tool for a job" as part of an end 
goal. picking the right tool for the job is often a lot harder than it 
needs to be. sometimes the tool needs to be low latency and as fast as 
possible. sometimes robust and reliable is key. sometimes simplifying 
store and forward mechanisms are what are required. there is no one size 
fits all. for example, the dense populated areas of Europe are quite 
different to isolated communities of the islands across the Pacific. in 
these isolated spaces, interoperability becomes more important than 
arbitrary ideals such as "fastest" or "lowest latency".

i see the opportunity for "battle" in battlemesh to evolve. as some 
technologies mature, some folks will become bored with the simple 
notions of "best" or "fastest". because it isn't the right tool for the 
job, for them. recognizing that and embracing additional models for how 
communities need to use their applications and how mesh networks could 
work for them.

i am looking forward to getting back into mesh network development and 
seeing what folks come up with. specifically how folks solve connecting 
meshes of meshes =)

regards,

kim