[B.A.T.M.A.N.] A case for batman-11s

[B.A.T.M.A.N.] A case for batman-11s

[Javier Cardona]

Hi batman developers,

Clara Gnos suggested that I write to the list to make a case for
batman + 802.11s integration.  As you probably know, 802.11s is the
upcoming wireless mesh standard from IEEE.  The current version of the
draft was approved by the IEEE 802 Executive Committee in July and
will be ratified next month.  open80211s (http://o11s.org) is an open
implementation of 802.11s that's in the kernel mainline since 2.6.26.

802.11s uses HWMP as its default routing (path selection, in
11s-speak) protocol.  All 11s implementations must support this
default, and this is what's implemented in open80211s.  The 11s spec
also defines an extensible framework to support other path selection
protocols and custom metrics.  open80211s supports these by providing
userspace hooks for custom path selection daemons.

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?
The benefits:

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)
2. You can leverage most of open80211s, from test tools to wireshark patches.
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.
4. You can reach out to a larger development community and raise
awareness about batman.
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.
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 :)

Anyway, that was just a thought.  If anyone is interested let me know.

Cheers,

Javier

-- 
Javier Cardona
cozybit Inc.
http://www.cozybit.com

Re: [B.A.T.M.A.N.] A case for batman-11s

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 3094 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [B.A.T.M.A.N.] A case for batman-11s

[Javier Cardona]

Hi Sven,

On Tue, Aug 23, 2011 at 3:32 AM, Sven Eckelmann <sven@narfation.org> wrote:
> 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

Thanks for pointing that out.  I did not know there were that many versions.

> ...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.

Noted.

>> 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?).

By colliding I mean "come into conflict or opposition", not killing
bunnies.  And it happens to be the same verb that Simon Wunderlich
used to explain why batman-adv had to change its ethertype
(https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2009-August/001682.html).
 Of course it's not a big deal, but definitely something you need not
worry about if your implementation is based on a spec that has been
standardized.

>> 2. You can leverage most of open80211s, from test tools to wireshark
>> patches.
>
> batman-adv also has wireshark integration (already upstream) and test tools.

Nice.

>> 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.

I see.  If I understand correctly batman-adv works as a bridge,
encapsulating mesh management info into data frames.  In that case
batman-adv routing must be based on hopcount and/or transmission
failures as radio layer info is lost in the conversion to 802.3.  By
being in the 802.11 stack, 11s has more information about the quality
of the links and can use that information to compute a finer-grained
metric.  The standard defines airtime as the default link metric but
11s can be extended to include other info like RSSI or SNR.

A similar argument can be made about security.  I assume batman-adv
does not implement security but instead relies on whatever the lower
layer provides.  In 11s security is built from the ground up.  Peers
authenticate each other and exchange encryption keys at the same time
they establish a peer link.  Security becomes easier to manage and
more robust than when using, for instance, WPA to secure peer links.

>> 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.

No matter how silent or small the open80211s community is, batman-adv
+ open80211s will always be larger than batman-adv alone.  That's what
I meant by "larger".

>> 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.

Why limit yourself there?  There are definitely use cases for
non-routers to join a mesh network.

> Thats why it has client mac propagation, bridge loop avoidence and roaming announcements (and many more
> things with funny names).

IEEE 802 also has its share of funny names...

client mac propagation, roaming announcements = (802.11s, Sec.
7.3.2.116) Proxy Updates
bridge loop avoidance = (802.1D, Sec. 17) Rapid Spanning Tree Protocol
or my favorite:  (802.11s, Sec 8.2a.1) Simultaneous Authentication of Equals

> And we already have a relative good distro integration for our target group...

Agree to that.  openwrt rocks.

>> 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.

You mean the same Wireless Battle of Mesh that year after year fails
to decide on a winner? :)
(My sixth point as well as the response above should be taken
humorously, that's what the colon thingy at the end of the sentence
meant)

I could not help noticing a certain level of skepticism in your
response.  I'm not trying to sell anything nor asking anyone to dump
batman in favor of anything else.  I admire and respect what the
batman project has achieved so far.  Even people in open80211s'
mailing list criticize that batman performs much better than
open80211s ( http://open80211s.com/pipermail/devel/2011-August/000859.html).
But my impression is that, maybe because they were ahead of their
time, the batman community had to invent/reinvent things in their own
unique way.  And now that a standard is in place, everyone interested
in mesh could benefit if there was a seventh (and final) version bump
to bring it in line with IEEE 802.11s.

Greetings and congratulations for your good work.

Cheers,

Javier


-- 
Javier Cardona
cozybit Inc.
http://www.cozybit.com

Re: [B.A.T.M.A.N.] A case for batman-11s

[Andrew Lunn]

> unique way.  And now that a standard is in place, everyone interested
> in mesh could benefit if there was a seventh (and final) version bump
> to bring it in line with IEEE 802.11s.

Hi Javier

I don't know that much about 802.11s, so i would be very happy to be
wrong....

I actually think IEEE 802.11s needs to first evolve and become part of
IEEE802.1. The problem is, mesh != wireless, so having it part of
802.11 limits its application way too much.

I've been to a few of the wireless battlemesh events and gained some
experience with real mesh network. One thing which is very clear to me
is, they are multi-technology. They mix 802.11, 802.3, cable modems,
VPN, and in theory, there is no reason why avian carriers could not be
used.

If you look at the mesh routing protocols represented in battlemesh,
static routes, babel, olsr, BMX, and batman{-adv} all are multi
technology and have no problem building one mesh over a heterogeneous
network.

What a mesh technology ideally wants is a collection of links which it
can send ethernet or IP frames over. So this puts it somewhere in
802.1, or a sublayer of IP.

You also said 802.11s contains device authentication, encryption,
etc. This also seems to me to be the wrong layering. These should be
generic services which any 802.11 "mode" above can use. Can these
services be used in adhoc mode or managed mode? If yes, great, anybody
setting up a static routes, babel, olsr, BMX, and batman{-adv} mesh
can just use there services.

My personal opinion is that taking the multi-technology batman-adv
protocol and shoehorning it into the single technology 802.11s is the
wrong way to go. What might however be interesting is taking a closer
look at 802.11s and see what can be generalized and moved up into
babel, olsr, BMX, and batman{-adv}, or merged into plain old managed
mode and adhoc mode 802.11 and offered as services to layers above.

       Andrew

Re: [B.A.T.M.A.N.] A case for batman-11s

[Javier Cardona]

Hi Andrew,

On Wed, Aug 24, 2011 at 12:18 AM, Andrew Lunn <andrew@lunn.ch> wrote:
>> unique way.  And now that a standard is in place, everyone interested
>> in mesh could benefit if there was a seventh (and final) version bump
>> to bring it in line with IEEE 802.11s.
>
> Hi Javier
>
> I don't know that much about 802.11s, so i would be very happy to be
> wrong....

I'm on equal footing regarding batman: thanks for taking the time to
help me understand the differences between the two.

> I actually think IEEE 802.11s needs to first evolve and become part of
> IEEE802.1. The problem is, mesh != wireless, so having it part of
> 802.11 limits its application way too much.

802.11s is designed to fit within the IEEE 802 family of protocols (it
was approved by the IEEE 802 Executive Committee in July).  You are
correct in that 11s does restrict the mesh to be a wireless mesh.  But
it is designed to connect to external networks via 802.1D bridges.
802.1D bridges have been around for ages and are good at
interconnecting diverse MAC types without routing loops.  I read here
(http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance) that
batman implements its own loop-avoidance protocol which, from my
limited perspective, seems redundant.

> I've been to a few of the wireless battlemesh events and gained some
> experience with real mesh network. One thing which is very clear to me
> is, they are multi-technology. They mix 802.11, 802.3, cable modems,
> VPN, and in theory, there is no reason why avian carriers could not be
> used.
>
> If you look at the mesh routing protocols represented in battlemesh,
> static routes, babel, olsr, BMX, and batman{-adv} all are multi
> technology and have no problem building one mesh over a heterogeneous
> network.

I can appreciate the benefits of supporting a diversity of link
technologies.  I'd have to understand better how a single metric
definition can be used to quantify the quality of all link types, from
802.11 to homing pigeon.  But I guess it's being done successfully.

> (...)
>
> You also said 802.11s contains device authentication, encryption,
> etc. This also seems to me to be the wrong layering. These should be
> generic services which any 802.11 "mode" above can use.
> Can these services be used in adhoc mode or managed mode?

In 802.11 infrastructure mode you have only one authenticator (the AP)
and many supplicants.  You cannot use the same security model in a
mesh, when there are no such role divisions.  Does batman-adv provide
a security layer above the link layer security (and below IP)?  If so,
where can I read more about that?

> If yes, great, anybody setting up a static routes, babel, olsr, BMX, and batman{-adv} mesh
> can just use there services.

Based on my current understanding it looks like you could establish a
batman-adv network over 1-hop 11s links.  Interesting.

> My personal opinion is that taking the multi-technology batman-adv
> protocol and shoehorning it into the single technology 802.11s is the
> wrong way to go. What might however be interesting is taking a closer
> look at 802.11s and see what can be generalized and moved up into
> babel, olsr, BMX, and batman{-adv}, or merged into plain old managed
> mode and adhoc mode 802.11 and offered as services to layers above.

When I wrote my first e-mail to your list I was under the impression
was that batman-adv's routing algorithm was more advanced than HWMP,
mainly because it had incorporated improvements gathered from many
deployments (... and mesh battles :).  But it seems like batman's main
strength is its ability to establish routes over heterogeneous links,
not necessarily minimizing the spectrum utilization.

Thanks a lot for sharing your thoughts on this.

Cheers,

Javier

Re: [B.A.T.M.A.N.] A case for batman-11s

[Simon Wunderlich]

[-- Attachment #1: Type: text/plain, Size: 5997 bytes --]

Hi Javier,

On Wed, Aug 24, 2011 at 11:30:01AM -0700, Javier Cardona wrote:
> > I actually think IEEE 802.11s needs to first evolve and become part of
> > IEEE802.1. The problem is, mesh != wireless, so having it part of
> > 802.11 limits its application way too much.
> 
> 802.11s is designed to fit within the IEEE 802 family of protocols (it
> was approved by the IEEE 802 Executive Committee in July).  You are
> correct in that 11s does restrict the mesh to be a wireless mesh.  But
> it is designed to connect to external networks via 802.1D bridges.
> 802.1D bridges have been around for ages and are good at
> interconnecting diverse MAC types without routing loops.  I read here
> (http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance) that
> batman implements its own loop-avoidance protocol which, from my
> limited perspective, seems redundant.
> 

The bridge loop avoidance is a little bit different from (R)STP. It also
avoids loops, but at the same time tries to offer the wireless clients
coming from the mesh the best way into the wired backhaul (i.e. select
the best router for this task). At this point, (R)STP could be also used,
but it usually just randomly kill of links, not neccesarily based on 
transmit quality. :)

> > I've been to a few of the wireless battlemesh events and gained some
> > experience with real mesh network. One thing which is very clear to me
> > is, they are multi-technology. They mix 802.11, 802.3, cable modems,
> > VPN, and in theory, there is no reason why avian carriers could not be
> > used.
> >
> > If you look at the mesh routing protocols represented in battlemesh,
> > static routes, babel, olsr, BMX, and batman{-adv} all are multi
> > technology and have no problem building one mesh over a heterogeneous
> > network.
> 
> I can appreciate the benefits of supporting a diversity of link
> technologies.  I'd have to understand better how a single metric
> definition can be used to quantify the quality of all link types, from
> 802.11 to homing pigeon.  But I guess it's being done successfully.
> 
batman-adv usually sees non-wireless links as "perfect" links, as there
is no packet loss. There is no "special" support (it may be interesting
to further qualify bandwidth or latency), but it just blends in
transparently. That's the beauty. ;)

> > (...)
> >
> > You also said 802.11s contains device authentication, encryption,
> > etc. This also seems to me to be the wrong layering. These should be
> > generic services which any 802.11 "mode" above can use.
> > Can these services be used in adhoc mode or managed mode?
> 
> In 802.11 infrastructure mode you have only one authenticator (the AP)
> and many supplicants.  You cannot use the same security model in a
> mesh, when there are no such role divisions.  Does batman-adv provide
> a security layer above the link layer security (and below IP)?  If so,
> where can I read more about that?
> 

Have a look WPA-NONE. It is not well documented, but it basically works
with a single shared key and CCMP/AES encryption. No peer-to-peer 
session keys or stuff like that though, afaik.

> > My personal opinion is that taking the multi-technology batman-adv
> > protocol and shoehorning it into the single technology 802.11s is the
> > wrong way to go. What might however be interesting is taking a closer
> > look at 802.11s and see what can be generalized and moved up into
> > babel, olsr, BMX, and batman{-adv}, or merged into plain old managed
> > mode and adhoc mode 802.11 and offered as services to layers above.
> 
> When I wrote my first e-mail to your list I was under the impression
> was that batman-adv's routing algorithm was more advanced than HWMP,
> mainly because it had incorporated improvements gathered from many
> deployments (... and mesh battles :).  But it seems like batman's main
> strength is its ability to establish routes over heterogeneous links,
> not necessarily minimizing the spectrum utilization.

Mhm, heterogenous network support is definitly one strength of batman.
However, with its general design we have a broad bandwidth where
we can optimize and experiment, for example:

 * multiple interfaces support in general (does 802.11s allow to span 
   meshes over multiple radios?), and with this:
   * interface alternating (receive on wlan0, send on wlan1) [1]
   * bonding (send on wlan0 and wlan1 in a round robin fashion) [1]
   * full duplex (not implemented, but might be someday ;)
 * network coding (we have some recent research on this) [2]
 * optimized multicast transfer [3]
 * further support for some protocols, like ARP [4]
   (through distributed hash tables, a current GSoC project)
 * the "core" routing too, of course :)
 ...

Regarding the battlemesh - we have seen some interesting effects in
the battlemeshes, but personally I see these events as an excellent
way to meet people, discuss experiences and ideas and primarily have 
a lot of fun. ;) It is one of the rare occasions that most of the
batman developers meet. You should come next time if you can. :)

The "real" tests and live experience is gathered inside real mesh networks, e.g. 
community networks or commercial networks with routers which include 
batman-adv as their mesh network software (using *WRT or commercial firmwares). 
Many features which were developed (e.g. Gateway support [5], Bridge Loop
Avoidance [6], Multicast Support [3], ...) came directly from 
"real world requirements".

Thanks for your input!

best regards,
	Simon

[1] http://www.open-mesh.org/wiki/batman-adv/Bonding-alternating
[2] http://www.open-mesh.org/wiki/open-mesh/2011-08-18-network-coding-first-steps
[3] http://downloads.open-mesh.org/batman/misc/wbmv4-multicast.avi
[4] http://www.open-mesh.org/wiki/batman-adv/DAT
[5] http://www.open-mesh.org/wiki/batman-adv/Gateways
[6] http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [B.A.T.M.A.N.] A case for batman-11s

[Andrew Lunn]

On Thu, Aug 25, 2011 at 09:36:14AM +0800, Yeoh Chun-Yeow wrote:
> Hi, all,
> 
> Although batman-adv is a layer 2 routing that works across multiple access
> technologies (not so sure about other technologies, because it mainly use
> for WiFi), but it only make senses if we configure the wireless interface
> operating in adhoc or adhocdemo mode. If we configure the wireless interface
> as Infrastructure mode, all the traffic will go to the AP first, even if we
> can direct communicate between the two STAs.
> 
> Correct me if I am wrong.

Ideally, you have BATMAN on the AP as well as the STA. So you never do
STA->AP->STA hops between BATMAN nodes, you only do a STA->AP BATMAN
hop followed by a AP->STA BATMAN hop. Performing two BATMAN hops means
BATMAN knows the transmit quality of each of the two wireless hop, not
the combined transmit quality of the STA->AP->STA path. So BATMAN
running on the AP can then decide if it makes sense to take a
different path.

There is code to enforce this, i.e. blocking STA->AP->STA transfers,
in the development tree and it has been push upstream to be included
in the mainline kernel.

	 Andrew

Re: [B.A.T.M.A.N.] A case for batman-11s

[Andrew Lunn]

> 802.11s is designed to fit within the IEEE 802 family of protocols (it
> was approved by the IEEE 802 Executive Committee in July).  You are
> correct in that 11s does restrict the mesh to be a wireless mesh.  But
> it is designed to connect to external networks via 802.1D bridges.
> 802.1D bridges have been around for ages and are good at
> interconnecting diverse MAC types without routing loops.  I read here
> (http://www.open-mesh.org/wiki/batman-adv/Bridge-loop-avoidance) that
> batman implements its own loop-avoidance protocol which, from my
> limited perspective, seems redundant.

STP, RSTP protocols are good when the networks are nearly
perfect. However, wifi is no way near perfect, there is high packet
loss. So when deciding to block ports, to resolve loops, you want to
block the wireless part and keep the wired part working. It can be
hard to make STP and RSTP do this, it often blocks the wired part, so
making your overall network work badly. Read the page, it explains the
concept quite well.

> > You also said 802.11s contains device authentication, encryption,
> > etc. This also seems to me to be the wrong layering. These should be
> > generic services which any 802.11 "mode" above can use.
> > Can these services be used in adhoc mode or managed mode?
> 
> In 802.11 infrastructure mode you have only one authenticator (the AP)
> and many supplicants.  You cannot use the same security model in a
> mesh, when there are no such role divisions. 

BATMAN does not really care if the WiFi is in infrastructure mode of
adhoc. However, generally, it is used in adhoc. Maybe the 802.11s
authentication and encryption schemes don't make too much sense in
infrastructure mode, but it would be nice to be able to use them in
adhoc mode.

> Does batman-adv provide a security layer above the link layer
> security (and below IP)?  If so, where can I read more about that?

Nope. That is a problem for some other layer, e.g. the link layer
below, IPSEC above, TLS end to end etc...

> Based on my current understanding it looks like you could establish a
> batman-adv network over 1-hop 11s links.  Interesting.

I expect it will also work over 42-hop 11s links. It probably won't
have the "optimal" toplogy, by some definition of "optimal". 

> deployments (... and mesh battles :).  But it seems like batman's main
> strength is its ability to establish routes over heterogeneous links,
> not necessarily minimizing the spectrum utilization.

Actually, most of the mesh protocols i listed try to minimizing the
spectrum. They try to use wired as much as possible! Wired links give
a much better goodput compared to wireless, so that it is better to
take a longer low bandwidth looking path over wired than a shorter
higher bandwidth looking path over wireless.

I'm not a PHY person, but i've seen papers from coding/PHY people who
actually say you should be maximizing spectrum utilization, not
minimizing it. If i understand the research correctly, you get better
overall mesh performance by sending for a long time a 6Mbps at lower
power, compared to sending a short burst at 54Mbps at high power. To
receive at 6Mbps you need a much lower SNR than at 54Mbps. So you can
transmit at lower power, so causing less interference to others and
receive in a noisier environment at 6Mbps, than receive a 54MBps frame
which needs more transmit power and less background noise in order to
receive it. So 6Mbps at lower power allows more links to be active at
the same time, maximizing the overall mesh bandwidth/latency. But like
i said, i'm not a PHY person, so i might have this all wrong.

Most mesh protocols actually go partway towards this. They all roughly
approximate to "least number of hops over good links", by some
definition of "good link". Least hops generally means using long hops,
which will naturally have less bits per symbol, i.e more medium
time. All that is missing is power control in the wireless layer.

      Andrew