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.
- 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?).
- You can leverage most of open80211s, from test tools to wireshark
patches.
batman-adv also has wireshark integration (already upstream) and test tools.
- 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.
- 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.
- 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