[PATCH] wpa_supplicant: Prefer 5 GHz networks over 2.4 GHz networks.

[Sam Leffler]

On Thu, Aug 18, 2011 at 10:51 AM, Galen <galenz at zinkconsulting.com> wrote:
>
> On Aug 18, 2011, at 9:30 AM, Gary Morain wrote:
>
> [resending from the right account...]
> On Tue, Aug 16, 2011 at 3:50 PM, Dan Williams <dcbw at redhat.com> wrote:
>>
>> On Tue, 2011-08-16 at 10:43 -0700, Sam Leffler wrote:
>> > On Mon, Aug 15, 2011 at 3:41 PM, Dan Williams <dcbw at redhat.com> wrote:
>> > > On Fri, 2011-08-05 at 16:23 -0700, Gary Morain wrote:
>> > >> In scan.c, merge a channel's noise value into the scan results. ?When
>> > >> comparing
>> > >> scan results, compute the signal-to-noise ratio and use it when
>> > >> available.
>> > >> Prefer a 5 GHz network if its SNR is really big (> 30) or if its SNR
>> > >> is
>> > >> relatively close to the other network's.
>> > >
>> > > Honestly I'd rather have something like a "bands" option on a
>> > > per-netblock basis, so you could do this:
>> > >
>> > > bands=5
>> > > bands=5,2
>> > > bands=2,5
>> > > bands=2
>> > >
>> > > ie, the connection manager can set whichever band it prefers, or leave
>> > > it out entirely to let the supplicant do whatever it's already doing.
>> > > The problem with micro-optimizations like this are that they often
>> > > break, and they aren't necessarily clear. ?I'd advocate for simpler,
>> > > clearer rules here, with behavior set by the connection manager,
>> > > rather
>> > > than continually more complicated matching rules in the supplicant
>> > > itself...
>> >
>> > I'm trying to understand how this would be used. ?The point of Gary's
>> > change is to prefer the 5GHz band only when two AP's have equivalent
>> > signal quality. (5GHz is considered better because it has
>> > non-overlapping channels, less likely to have interference, etc.)
>> > This is meant to improve the algorithm by which a BSS is selected.
>>
>> Yeah, I guess that's different than I'm proposing. ?But making this
>> decision is still a policy decision that I'm not sure should be done in
>> the supplicant.
>
> The supplicant already makes a decision on which channel to use. ?I'm not
> proposing a new policy but instead a refinement of the existing policy to
> prefer 5 GHz channels.
> There are in fact two refinements in the CL.
> 1) Instead of using signal level as the criteria for channel quality, use
> signal-to-noise ratio if available. ?SNR is a better metric. ?Also, cap SNR
> at 30 because channels with an SNR greater than 30 will perform equally well
> from a signal quality point of view. ?Using SNR for selecting channel is
> better for all bands.
> 2) If two channels have the same or close-enough SNR, then prefer the 5 GHz
> channel. ?Because of the capping of SNR at 30, it is much more likely that
> this preference will occur.
> What seems to be controversial is preferring 5 GHz channels. ?This behavior
> can be configurable. ?For sake of simplicity, I propose making the 5 GHz
> preference a compile-time option, defaulted to off.
>
> I think we can agree that the overall goal here is to improve the
> probability that a typical user will experience excellent WiFi performance.
> In this light, I think it's hard to avoid the fact that some kind of 5 GHz
> preference is going to benefit performance for the typical user. I realize
> that any preference for the 5 GHz band will create some edge cases where a
> user might experience decreased performance ("cost"), but I see this as an
> issue of balancing the cost/benefit ratio.
> I would suggest that we step back and take some time to devise an actually
> intelligent algorithm for 5 GHz preference. Done properly, this should
> significantly minimize the number of cases where typical users will
> experience decreased performance, while maximizing the potential benefit.
> There are some very important considerations in devising this algorithm:
> * SNR is a very poor metric.?There's no way to reasonably model a
> relationship between SNR and data rate, with varying channel widths and
> bands. SNR has to be used, at best, as a very limited heuristic in the
> decision making process.

The basic issue here is that the existing signal level metric is
broken by design.  With NF different on every channel blindly
comparing values causes you to choose the wrong device.  Using "SNR"
improves this (there are too many different names for the value
RSSI-NF).  The preference for 5GHz is separate and perhaps should've
been split into a separate change.

> * Channel widths are a huge consideration. 40 MHz channel widths in the 5
> GHz band are common, while relatively rare in the 2.4 GHz band.

Not really relevant; this should be addressed when comparing the AP's
capabilities.

> * Using actual rate selection data might be a good consideration. This is a
> far better measure that accounts for both channel width and SNR.
> It seems like a good approach to this issue would be to "try" the 5 GHz
> network first if the SNR is anywhere near sane, measure the data rate, and
> then jump to the 2.4 GHz network if the data rate is proving too low. Given
> the typical 40 MHz at 5 GHz / 20 MHz at 2.4 GHz scenario, it is possible to
> use any of the 16-QAM data rates on the 5 GHz band and get throughputs
> greater than all but the highest data rates on the 40 MHz channel. It is
> even possible for the 40 MHz channel to have an inferior SNR and achieve
> superior throughput simply because of the channel width - remember that the
> noisy channel coding theorem dictates the relationship between bitrate and
> SNR, and the relationship is exponential, not linear, thus higher bitrates
> require a significantly better SNR than lower bitrates.

We're talking about selecting the "best BSS to join" given (limited)
scan results.  Unfortunately supplicant doesn't currently maintain
historical data to make more informed decisions.  But again, not
related to the issue at hand.

> In my experiences deploying WiFi networks, I've never seen a WiFi client
> where the 5 GHz band preference has been too strong. For example, Apple has
> implemented a preference for the 5 GHz networks and even with those
> settings, and even increased the strength of this preference in later
> releases of their OS, yet I still find lots of real-world situations with
> WiFi deployments where I split the networks into 5 GHz and 2.4 GHz SSIDs so
> I can force clients onto the 5 GHz because the built-in preference for 5 GHz
> is not strong enough.
> I also believe that facilitating a robust 5 GHz preference is good practice
> for the larger community. By supporting 5 GHz properly (and by default) we
> can help support the wider deployment of dual-band WiFi networks, which will
> be a big win for everybody.
>
> Can we get agreement on this?
>>
>> > Also, specifying a preference on a per-netblock basis seems odd; when
>> > would you want to control band preferences only for a specific SSID?
>>
>> I've had this request come up periodically. ?If your institution uses
>> the same SSID between the 5GHz and 2.4GHz wifi networks, but you'd like
>> to always be on the 5GHz segment because it's less loaded. ?But other
>> places you may not want to be on the 5GHz network. ?It really is a
>> per-SSID (ie per network) preference.
>>
>> > You can lock down a netblock using bssid= and assign priority though
>> > it might be painful to list all the AP's in an ESS. ?If we really want
>> > to add this complexity it seems like it belongs per-interface or
>> > global (or at compile-time).
>>
>> I disagree. ?It's not global to the entire decision, it's specific to
>> the netblock. ?You may not always want to prefer 5GHz networks
>> everywhere you are. ?The problem with the freq= parameter is that to
>> achieve this behavior you'd have to list *all* the frequencies in the
>> 5GHz and 2.4GHz range, while using bssid= is a no-go because the
>> situation where you want this behavior is one where there are a ton of
>> APs around.
>>
>> Dan
>>
>