Re: [PATCH 2/6] Rewrite roaming logic

Jouni Malinen <[email protected]> Fri, 19 Jun 2020 18:29:28 +0300
Newsgroups gmane.linux.drivers.hostap
Message-ID <[email protected]>
On Mon, Jun 01, 2020 at 05:10:14PM -0700, Matthew Wang wrote:
> The roaming logic is currently too aggressive and full of holes. In
> particular, the (arbitrary) values we currently assign to the roaming
> difficulty are too small; an AP can reasonably move up or down 5dB in
> RSSI in an enterprise environment even when the device is static. The
> logic needs to be more resilient to these small fluctuations.
> 
> The following notes describe each of the changes made and the rationale
> behind it.
> 1. Remove all short-circuiting and allow the roaming logic below to run
>    its course. This way we avoid overlooking important factors.
> 2. Add a to_2ghz flag that indicates if we are moving from a 5ghz AP to
>    a 2ghz AP. This should increase the difficulty to roam in that
>    direction and mirror the to_5ghz flag.
> 3. Adjust the min_diff upward across the board. Originally, we would
>    roam with a RSSI imporvement of 1dB in the weakest bucket and 5dB in
>    the strongest bucket. RSSI is fairly fickle and APs can easily
>    fluctuate by more than that in a normal enterprise environment.
>    Additionally, there should be more buckets. We currently stop
>    differentiating after the RSSI is at least -70dB. This is still
>    pretty weak, and the difficulty should continue to increase above
>    that. Move the threshold up to 4dB in the weakest bucket and 10dB in
>    the strongest bucket, and add two more buckets (up to -60dB).
> 4. We adjust the roam difficulty up and down based on the estimated
>    throughput of the selected AP relative to the estimated throughput of
>    the current AP. Small gains or losses in estimated throughput should
>    not be rewarded or penalized as heavily as they are now since
>    estimated throughput is a hand-wavy measurement to begin with. Relax
>    these adjustments.

This seems to prevent roaming from non-HT to HT AP if those APs have the
same signal strength. This does not sound desirable. Being able to use
HT will likely get better throughput and reduced airtime need. For
example, the prefix_ht20_during_roam test case fails because of these.

-- 
Jouni Malinen                                            PGP id EFC895FA