Re: [PATCH RFC 3/3] station: improve roam scan strategy

[James Prestwood <prestwoj@gmail.com>]

Hi Alexander,

On 5/7/25 5:53 AM, Alexander Ganslandt wrote:
> Hello James and Denis,
>
> Thank you both for the feedback! I want to focus on the overall idea 
> here and will look at the code details later.
>
> On 4/16/25 18:46, James Prestwood wrote:
> > Won't this start reusing the same frequencies after a few scans? Say
> > your first N scans take more than 3 seconds, you'd then begin using
> > those frequencies again on subsequent scans since their ages are under
> > the threshold?
> >
> > Rather than a hard threshold simply sorting by age seems like the best
> > way to do this:
> >
> >   - Sort the frequencies by least recently used -> Take the first N
> > frequencies -> Scan
> >   - No candidates found? -> Repeat ^^^
>
> Yes, it will start reusing frequencies and might never reach the less 
> common frequencies depending on how long time the scans take. That's 
> definitely not ideal. Looking at the age as you suggest has the 
> problem that it will eventually spend time scanning uncommon 
> frequencies when that time would have been better spent scanning 
> common frequencies that are getting old.

I think we can say the #1 goal is to avoid full spectrum scans. But 
entirely avoiding frequencies even if they are uncommon is definitely a 
show stopper. We do (eventually) need to scan all the frequencies even 
if they come after the 3rd, 4th, 5th scan subset.

>
> Maybe this is an impossible task to solve perfectly as there will 
> always be a trade-off, maybe it's better left as configs for the user? 
> In my livestream use case the APs should be configured such that most 
> good frequencies are in "neighbor" or "known", so I would like to 
> spend most time on these frequencies. However, for a use case where 
> the network setup is unknown, having more exploration of uncommon 
> frequencies might be better.

I see your point, and even for my use-case we generally know a subset of 
frequencies that the APs are on. But this really doesn't align well with 
a generalized use case where you may be on various public network, 
traveling between countries, etc. We should definitely prefer 
neighbor/known frequencies but we need to account for all frequencies at 
some point during the scanning process. Completely ignoring certain 
frequencies will end up biting us when some user comes and says their 
device refuses to roam to some AP in their network because its using an 
"uncommon" frequency.

>
> We could have configs instead where users can define the subsets and 
> age threshold. If they don't set anything, the default is the current 
> behavior. If they set subsets, the roaming algorithm will pick 
> frequencies from those in the prioritized order, just like this patch 
> does. It could still get stuck scanning the same frequencies if the 
> age threshold is too low, but then it would be a user configuration 
> error. We then also get rid of hard-coding frequencies in IWD and all 
> problems that causes, but still give users the possibility to do so if 
> needed. Does this make more sense?
I doubt your going to get such a configuration parameter past Denis :) 
We need to figure out a path for a dynamic/learned configuration based 
on prior frequencies seen/used, neighbor reports, while still 
(eventually) scanning the entire spectrum.
>
>
> On 4/16/25 19:19, Denis Kenzior wrote:
>> Have you considered maintaining a scan_freq_set of all the 
>> frequencies scanned
>> by the neighbor and known-frequency stages instead of maintaining an 
>> hashtable
>> based on age?
>
> I don't completely follow what you mean here. The reason for having 
> the hashtable is to know how long ago a certain frequency was scanned 
> in order to not scan it again too soon. So that info will have to be 
> stored somehow, or did you have some other approach in mind?
>
>> So the idea is to add up to STATION_MAX_SCAN_FREQS to a new set, 
>> starting in
>> order of preference with:
>>         1. neighbor frequency set
>>         2. known network set
>>         3. scan frequency ordering set
>>
>> while filtering the frequencies already scanned.
>>
>> How do you know when to give up the current attempt?
>
> Yes, correct. Do you mean when to give up on the roaming attempt 
> completely? The current approach is to never give up, it will continue 
> scanning frequencies in the subsets until it finds a better BSS, or 
> until the current BSS signal goes above the threshold and roaming 
> stops. I believe this is also what IWD does today, except it uses full 
> scans continuously.
>
> Regards,
> Alexander
>