kim at hawtin.net.au
Fri Dec 16 22:08:05 CET 2016
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
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 =)
More information about the Battlemesh