[PATCH 2/6] Rewrite roaming logic

[Matthew Wang]

> the main issue I see
here is in that behavior that seems to completely prevent roaming unless
signal level increases significantly regardless of other factors.

This is only the case for the lowest bucket (< -85dBm), as you've
pointed out, and in this case, I would argue that roaming for
estimated throughput gains doesn't actually provide much (if any)
benefit. -86dBm is hardly usable WiFi, and the roam will only add to
the disruption in connectivity, resulting in a decrease in the actual
throughput. Putting the non-HT vs HT question aside for a moment, if
we take two APs that are both at approximately -86 dBm from the
device, according to the original algorithm, any fluctuation in signal
level where the current signal is any worse than the signal of the
other AP will cause a roam, and as I'm sure you're aware, fluctuation
in signal level happens constantly. What we end up seeing is the
device aggressively roaming back and forth for no real signal or
throughput gains. The poor signal level (combined with constant
roaming) far outweighs any gains in estimated throughput.

Even taking into consideration the 2 Mbps non-HT AP vs the 8.666 Mbps
HT AP situation, I think it makes sense to encode some slight bias
towards the HT AP for the reasons you mentioned (A-MPDU and A-MSDU),
but there's no point in roaming to the HT AP if we're just going to
roam away from it because the signal fluctuated a couple dBm.

The point I'm trying to make is that RSSI measurements are moving
targets and can see quite a bit of variance, and the algorithm should
be able to absorb some of this. If we encoded a preference for HT, we
could see something like: at -86 dBm, roam to HT AP when signal is 2
dBm greater, roam to non-HT AP when signal is 6 dBm greater. In this
case, even if two APs have the same "real" RSSI relative to the
device, it's extremely likely, and, in fact, almost inevitable, that
the HT AP will be > 2 dBm greater at some point, and it's much less
likely that the non-HT AP will be > 6 dBm greater at some point. Using
the mac80211_hwsim module to test roaming has this shortcoming - that
the RSSI measurements are too precise and don't actually simulate
real-world environments accurately in this regard.

My arguments up to now have been pretty much entirely conjecture, but
I'd like to offer some (maybe slightly hand-wavy) data. ChromeOS is
one of the largest (if not the largest) consumers of the roaming
functionality in wpa_supplicant since Android offloads roaming to the
chipset. We've gotten many complaints about roaming from enterprise
customers in the past, but ever since we've adopted these roaming
changes nine or so months ago (along with a few more since I first
submitted this patch) in our tree, we've had customers tell us that
their issues were resolved and roaming complaints as a whole have
become more or less non-existent. Additionally, we've since added
integration tests to simulate movement between APs using programmable
attenuators, and we've seen measurable improvements in stability
(device is able to withstand minor fluctuations in signal level
without roaming) and no decreases in mobility (device is still able to
roam before getting deauth-ed for leaving the original AP).

I hope this makes sense, and I'm more than happy to continue
discussing anything you still think needs to be improved or is
unsatisfactory. I think encoding the HT preference is reasonable and
I'll go ahead and do that when I get a chance, but beyond that, I
still believe this is a step in the right direction. Sorry for the
long response, and if you've made it this far, thanks for reading :)

On Sun, Feb 28, 2021 at 1:22 AM Jouni Malinen <j at w1.fi> wrote:
>
> On Tue, Jun 23, 2020 at 02:41:19PM -0700, Matthew Wang wrote:
> > Thanks for the response. I ran the prefer_ht20_during_roam test and it
> > looks like it expects a roam from a non-HT AP at -30 dBm with 54 Mbps
> > est_tpt to an HT AP at -30 dBm with 65 Mbps est_tpt. I'm not too clear
> > on all the phy layer details of HT, but in my opinion, roaming from an
> > AP at such a strong signal level (-30 dBm) needs a fairly strong
> > justification, and a 20% increase (54 -> 65) in estimated throughput
> > is not that strong. That being said, if there are benefits to moving
> > from non-HT to HT that aren't captured in the {signal, est_tpt} pair,
> > then I'd advocate for using a flag that behaves similarly to the
> > to_{2,5}ghz flags, which adjusts the roaming difficulty up/down 2 dBm
> > depending on the direction of the roam. We can assign some value for
> > {to,from}_ht flags that subtracts from or adds to the roaming
> > difficulty depending on how valuable HT vs non-HT is. Does this make
> > sense?
>
> That behavior is not limited to so high signal strength value. Same
> happens with all other values and the impact is much more severe in some
> cases. For example, with both APs at -86 dBm non-HT AP gets 2 Mbps
> est_tpt and HT AP gets 8.666 Mbps. Still, roaming is prevented ("Skip
> roam - too small difference in signal level (0 < 4)"). In other words,
> even that min_diff -= 2 style adjustment that is given for to_5ghz would
> not help here. In fact, it looks like this patch would make it
> impossible to roam to an AP that shows better throughput estimate
> (regardless of how large a difference) on the same band unless there is
> also at least 4 dB increase in the signal level when cur_level < -85.
> That does not look reasonable.
>
> And yes, HT does come with possibility of using A-MPDU and A-MSDU
> aggregation which can result in significant improvement in throughput
> and airtime efficiency and that is in addition to the estimated
> throughput values from TX rates. So it might indeed make sense to
> add/subtract difficulty for roaming, but still, the main issue I see
> here is in that behavior that seems to completely prevent roaming unless
> signal level increases significantly regardless of other factors.
>
> --
> Jouni Malinen                                            PGP id EFC895FA