Re: TR: [RFC] 802.11s bitrate correction in airtime metric calculation

Re: TR: [RFC] 802.11s bitrate correction in airtime metric calculation

[Bob Copeland]

On Fri, Mar 28, 2014 at 11:15:06AM +0100, Cedric VONCKEN wrote:
> Hi all,
> 
> I am currently using 802.11s for a project using openWrt mesh portals.
> All mesh points use 802.11a (non HT) and minstrel. Airtime metric uses a
> "rate"
> which is ultimately computed using sta->last_tx_rate from minstrel.
> 
> This last_tx_rate is also updated by minstrel attempts at lower and
> higher speeds. Even if these occasional attempts are outnumbered by
> frames at max_tp_rate[0], they cause unexpected airtime metric
> variations resulting in unneeded mesh path changes.
> My idea is to use max_tp_rate[0] (from minstrel) instead. This rate is
> not subject to minstrel attempts and directly reflects the speed used
> for the vast majority of the frames.

Interesting -- I tried this exact thing once before, but got mixed results
in my testing.

Can you share your testing strategy?

It's true that last_tx_rate is sub-optimal here, but I feel like using
max_tp_rate directly is a layering violation.  Many rate controllers
won't have that concept, and some rate controllers will exist entirely
in firmware.  So I think perhaps fixing the concept of "last_tx_rate" or
adding a new "best_tx_rate" field that excludes probes and such might be
the way forward, rather than calling into the rate controllers.

-- 
Bob Copeland %% www.bobcopeland.com

Re: TR: [RFC] 802.11s bitrate correction in airtime metric calculation

[Antonio Quartulli]

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

Hello,

On 28/03/14 14:22, Bob Copeland wrote:
> On Fri, Mar 28, 2014 at 11:15:06AM +0100, Cedric VONCKEN wrote:
>> Hi all,
>>
>> I am currently using 802.11s for a project using openWrt mesh portals.
>> All mesh points use 802.11a (non HT) and minstrel. Airtime metric uses a
>> "rate"
>> which is ultimately computed using sta->last_tx_rate from minstrel.
>>
>> This last_tx_rate is also updated by minstrel attempts at lower and
>> higher speeds. Even if these occasional attempts are outnumbered by
>> frames at max_tp_rate[0], they cause unexpected airtime metric
>> variations resulting in unneeded mesh path changes.
>> My idea is to use max_tp_rate[0] (from minstrel) instead. This rate is
>> not subject to minstrel attempts and directly reflects the speed used
>> for the vast majority of the frames.
> 
> Interesting -- I tried this exact thing once before, but got mixed results
> in my testing.
> 
> Can you share your testing strategy?
> 
> It's true that last_tx_rate is sub-optimal here, but I feel like using
> max_tp_rate directly is a layering violation.  Many rate controllers
> won't have that concept, and some rate controllers will exist entirely
> in firmware.  So I think perhaps fixing the concept of "last_tx_rate" or
> adding a new "best_tx_rate" field that excludes probes and such might be
> the way forward, rather than calling into the rate controllers.
> 

Some time ago I raised a similar problem when trying to extract a
reasonable value from the RC algorithm to be used in a new metric for
batman-adv.

I wanted something that could represent the "available bandwidth", so
the first idea was to use "max_tp_rate" and its probability of success.
Unfortunately these two values are meaningful if we are using minstrel,
but mostly meaningless for other RC algorithms, therefore nobody (in
particular Johannes) liked the idea of "exporting" the two separately.

Then we realised that a sort of "estimated throughput/bandwidth" is
something that any RC algorithm can somewhat provide and that can
therefore be exported by a generic RC API[1].

The "expected throughput" should be computed by minstrel as the product
of the max_tp_rate and its probability of success.

I talked a bit about this with Bob on IRC and it seems that this could
be a viable approach for 11s as well (even if it requires a
rearrangement of the way ALM is computed).


I also provided an initial RFC[2] that was then rearranged to follow the
"exported throughput" idea but was never re-sent to the ml.

If you think that this is something that could be helpful for you as
well, I could send the new RFC soon so that we can all discuss on it.


Cheers,


[1] http://article.gmane.org/gmane.linux.kernel.wireless.general/118501
[2] http://article.gmane.org/gmane.linux.kernel.wireless.general/118403

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: TR: [RFC] 802.11s bitrate correction in airtime metric calculation

[Sergey Ryazanov]

2014-03-29 18:23 GMT+04:00 Antonio Quartulli <antonio@meshcoding.com>:
> Hello,
>
> On 28/03/14 14:22, Bob Copeland wrote:
>> On Fri, Mar 28, 2014 at 11:15:06AM +0100, Cedric VONCKEN wrote:
>>> Hi all,
>>>
>>> I am currently using 802.11s for a project using openWrt mesh portals.
>>> All mesh points use 802.11a (non HT) and minstrel. Airtime metric uses a
>>> "rate"
>>> which is ultimately computed using sta->last_tx_rate from minstrel.
>>>
>>> This last_tx_rate is also updated by minstrel attempts at lower and
>>> higher speeds. Even if these occasional attempts are outnumbered by
>>> frames at max_tp_rate[0], they cause unexpected airtime metric
>>> variations resulting in unneeded mesh path changes.
>>> My idea is to use max_tp_rate[0] (from minstrel) instead. This rate is
>>> not subject to minstrel attempts and directly reflects the speed used
>>> for the vast majority of the frames.
>>
>> Interesting -- I tried this exact thing once before, but got mixed results
>> in my testing.
>>
>> Can you share your testing strategy?
>>
>> It's true that last_tx_rate is sub-optimal here, but I feel like using
>> max_tp_rate directly is a layering violation.  Many rate controllers
>> won't have that concept, and some rate controllers will exist entirely
>> in firmware.  So I think perhaps fixing the concept of "last_tx_rate" or
>> adding a new "best_tx_rate" field that excludes probes and such might be
>> the way forward, rather than calling into the rate controllers.
>>
>
> Some time ago I raised a similar problem when trying to extract a
> reasonable value from the RC algorithm to be used in a new metric for
> batman-adv.
>
> I wanted something that could represent the "available bandwidth", so
> the first idea was to use "max_tp_rate" and its probability of success.
> Unfortunately these two values are meaningful if we are using minstrel,
> but mostly meaningless for other RC algorithms, therefore nobody (in
> particular Johannes) liked the idea of "exporting" the two separately.
>
> Then we realised that a sort of "estimated throughput/bandwidth" is
> something that any RC algorithm can somewhat provide and that can
> therefore be exported by a generic RC API[1].
>
> The "expected throughput" should be computed by minstrel as the product
> of the max_tp_rate and its probability of success.
>
> I talked a bit about this with Bob on IRC and it seems that this could
> be a viable approach for 11s as well (even if it requires a
> rearrangement of the way ALM is computed).
>
Seems that this could be useful even for end user if we export these
data via NL80211, since last_tx_rate is quite meaningless when using
minstrel rate control.

-- 
BR,
Sergey

Re: TR: [RFC] 802.11s bitrate correction in airtime metric calculation

[Antonio Quartulli]

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

On 29/03/14 19:43, Sergey Ryazanov wrote:
> Seems that this could be useful even for end user if we export these
> data via NL80211, since last_tx_rate is quite meaningless when using
> minstrel rate control.
> 

Yeah, this was the second part of the RFC: export the expected
throughput via get_station() and then export get_station() as well so
that also other kernel modules out of mac80211 can use this estimation
(i.e. batman-adv in my case).

Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: TR: [RFC] 802.11s bitrate correction in airtime metric calculation

[Cedric Debarge]

Hi Bob and Dennis,

Thanks for your answer.

>On 3/28/2014 8:22 AM, Bob Copeland wrote:
>> Interesting -- I tried this exact thing once before, but got mixed
>> results in my testing.
>>
>> Can you share your testing strategy?

Here is my testing summary :

     __  _      |_|_|                           |_|_|      __  _
    [__]|=|--->[____°]                         [____°]<---[__]|=|
    /::/|_|                                               /::/|_|
                       .------------------.
   Mesh portal B       | Office building  |   Mesh portal A
   Fixed location      |    15m x 40m     |   Fixed location
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       |                  |
                       '------------------'
      __  _     |_|_|
     [__]|=|-->[____°]
     /::/|_|

    Mesh portal C
    Fixed location

All points are mesh portals. Signal levels are :
	- around -60dBm between A and B --> metric = 152
	- around -60dBm between B and C --> metric = 152
	- around -80dBm between A and C --> metric >> 2*152

All point are using openwrt with compat-wireless v2013-04-16.

A runs an iperf server and C an iperf client (see iperf parameters below)
iperf -c mesh_point_A_ip -b10M -i10 -t9999

During the test I monitored both mpath and minstrel stats on mesh portal C:
	- mpath (iw wlan0 mpath dump)
	- minstrel stats (rc_stats files for stations B and A)

Without my patch, I get 10 or more mpath changes per minute. When I apply it,
the number of changes drops to 1 or 2 per minute. In this particular case, it
seems to be an improvement but I haven't tested this patch in another scenario.
In order to get a fully stable link, I have to set a rssi threshold in order to
prevent C to establish any plink with A (and do the same on point A).

Cédric DEBARGE
ACKSYS R&D dpt.