[PATCH 2/6] Rewrite roaming logic

[Matthew Wang]

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?

On Tue, Jun 23, 2020 at 2:30 PM Matthew Wang <matthewmwang at chromium.org> 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?
>
> On Fri, Jun 19, 2020 at 8:31 AM Jouni Malinen <j at w1.fi> wrote:
> >
> > 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