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

[Antonio Quartulli <antonio@meshcoding.com>]

[-- 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 --]