[Battlemesh] idea: QoS in mesh-networks / private interfaces

[Dave Taht]

On Mon, Apr 11, 2016 at 12:19 PM, Bastian Bittorf
<bittorf at bluebottle.com> wrote:
> dear hobbyists!
>
> For making everything better 8-) my idea was to
> apply QoS-rules per neighbourm, because of:

I am in the middle of a long writeup on why classic 802.11e QoS ideas
are flawed and how to go about fixing some of them, as yet
unfinished.... however I do have some pieces already in the queue that
I hope will help, some links below.

However the way you are using "QoS" here is not how I would
conventionally think of Qos.

>
> dynamically restrict rx/tx to _lower_ values than rate-selection
> guesses, so we dont run that likely into congestion/borders.

Actually, you will make congestion worse this way, generally.

http://blog.cerowrt.org/post/selective_unprotect

> yes: i prefer low latency over fast throughput.

So do I!

However, some packet loss or congestion management is needed to
actually match the rate to the throughput. Having a more perfect rx/tx
is sometimes the opposite to what you really want.

Secondly, things like minstrel optimize for the best connectivity, and
perversely, sometimes the high rate has less interference, shorter
packets using less airtime is better, or being sent twice in the retry
chain, is often better than the lower rate. The paper on how minstrel
worked (in 2008) I have finally got around to putting up, here:

http://blog.cerowrt.org/post/minstrel/

I wish everyone deeply involved in wifi had had a core starting point,
there. Grokking rate control is a big piece of the puzzle.

>
> For making this to work it needs 1 interface per neigh.
> This smells like VLANs, but i could not get it to work:
> When I force to tag the wireless with e.g. tag 66 it applies
> of course for all packets, not only a specific neigh.
>
> Question:
> is somebody of you aware of a method for reaching this goal?

First up, in my mind, is getting per station queuing to work right,
dynamically tying the physical rate to the bandwidth available, and
buffering appropriately for the amount of data you can aggregate.

http://blog.cerowrt.org/post/rtt_fair_on_wifi/

>
> imagine e.g. 3 nodes in a triangle:
> Node A - interface wlanAB, wlanAC
> Node B - interface wlanBA, wlanBC
> Node C - interface wlanCA, wlanCB
>
> the normal e.g. 'wlan0' should stay, so new neighs are still
> capable of joining (and are later transfered to a private interface).
>
> bonus-point if there is a way for having the broadcast packets
> still on the not-private interface.

Dealing with multicast better is a different topic. To some extent
cisco solved that years ago, and they also deal with how 802.11e QoS
works much better than how linux does it now.

http://blog.cerowrt.org/post/how_cisco_does_wifi_qos/

>
> bye, bastian
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh