On Monday 22 August 2011 16:30:56 Javier Cardona wrote:
Which brings me to the main point of my e-mail: is
anyone out there
interested in porting batman's path selection algorithm into
open80211s?
Which one? There are ~5 revisions of the algorithm (not implementations). The
newest iteration is B.A.T.M.A.N. V and is currently in the research and
prototyping phase. The algorithm described in the RFC draft was B.A.T.M.A.N.
III
...but I am not interested in implementing it for 802.11s. Maybe there is
somebody else. Most people are currently focused on batman-adv. So I will
write this response with batman-adv in mind.
The benefits:
I only see benefits mentioned by you, but were are the disadvantages? I don't
think that a marketing mail is a good start for a serious discussion.
1. By being based on a standard, you'll know you
won't be colliding
with other layer 2 technologies (for instance, no need to define your
own ethertype)
At least batman-adv is quite happy about the fact that it is based on a widely
used standard technology. And defining another identificator instead of an
ethertype doesn't make a big difference to me.
But why are we colliding with any other layer 2 technologies? It sounds like
"uh, you are so bad. you kill cute bunnies", but I don't see the
"colliding"
problem here. Maybe you mean the missing ethertype registration (anyone got
$2500 for us?).
2. You can leverage most of open80211s, from test
tools to wireshark
patches.
batman-adv also has wireshark integration (already upstream) and test tools.
3. By being integrated in the kernel's 802.11
stack, you can take
advantage of the development that's taking place there, from encrypted
management frames to HT support.
Aren't all those things part of the layer _below_ batman-adv? Why should we
care about it when the stuff we use has to deal with it.
4. You can reach out to a larger development community
and raise
awareness about batman.
What larger development community? At least the open80211s community seems to
be a lot more silent.
5. A big problem in mesh adoption on Linux is not the
mesh protocol
itself but the absence of simple to use configuration tools (e.g. no
mesh support in ConnMan, NetworkManager, etc.). By providing a
unified wireless mesh framework we increase the likelihood of having
some support at the distro level.
Hm, maybe we have a different target audience. batman-adv is made for
routers/APs and not for desktop systems. Thats why it has client mac
propagation, bridge loop avoidence and roaming announcements (and many more
things with funny names). And we already have a relative good distro
integration for our target group...
and last, but not least...
6. You'll be able to say authoritatively that batman is X times more
efficient than HWMP (pick any X greater than 1 :)
And this is important because... And can be measured by... And uses the normed
scale...
Maybe you should visit a Wireless Battle of the Mesh and tell them how such a
benchmark is correctly done.
Greetings,
Sven