WBA/IETF Connect-Info Implementation under way

[Jouni Malinen]

On Tue, Oct 07, 2025 at 01:03:33PM -0600, Joey Padden wrote:
> If you’d rather see a VSA, do you have thoughts on which parameters you’d want in Connect-Info and which you’d want moved to a VSA? 
> 
> WBA has a Vendor-ID and has some precedence for defining VSAs. So this path can be explored further. 
> 
> The current set of metrics Wi-Fi roaming operators are asking for is:
> 
> •	Connect Speed
> •	Wi-Fi Standard
> •	Channel
> •	Band
> •	RSSI
> •	RSSI Minimum
> •	Noise Level
> •	Channel Utilization
> •	TxBitRate
> •	RxBitRate
> •	Frame Loss
> •	Frame Retry
> •	Backhaul Downlink Throughput
> • 	Backhaul Uplink Throughput
> •	Backhaul Latency
> •	STA count connected to radio
> 
> Do you have a format you’d rather see that is more parsable? I think Mark and Josh chose ABNF syntax as it’s defined and standard. Would you two be advocates for multiple VSAs, one for each parameter or for a similar ABNF syntax just not in Connect-Info? 

The high level use case makes sense to me, but the way this is described
in draft-grayson-connectinfo-04 does not seem to match that use case or
at least my understanding on what the use case is trying to achieve. It
feels more like this draft is describing historical information on how
some vendors have implemented this than a clean design that could be
conveniently supported in future devices.

I would also point out that some of the descriptions like
TxBitRate/RxBitRate being "the _latest_ TxRate/RxRate used by the AP"
does not seem to match what I think was proposed here, or well, at least
my thinking of what would be the best way of collecting and aggregating
information. It would seem to be much more useful for the AP (e.g.,
hostapd in this particular contribution case) to collect average
TxRate/RxRate values from the period between the RADIUS accounting
updates. This would then allow RADIUS servers to do additional analysis
of the information that is more accurate description of the connection
than any small number of snapshots of last used TX rates at the time a
RADIUS message is sent.

If we were to ignore what vendors might have implemented in this area
and look at a clean design from RADIUS attribute view point for
potential future implementations that do not need to be compatible with
what exists today, it should (IMHO) be multiple VSAs, one for each item
that cannot be determined at the time of association (i.e., the exchange
of (Re)Association Request/Response frames) or that are not specific to
a single STA (e.g., channel information or conditions) while at least a
subset of the items that are specific to each STA and that are known at
the time of association could be encoded in the Connect-Info attribute.

To be more specific, the Wi-Fi generation (i.e., the highest Wi-Fi
generation value that both the AP and STA support; WFA-GEN-NAME in the
draft) and maybe also theoretical PHY MAXSPEED or PHYRATE based on the
negotiated capabilities for the association could be nice additions in a
standards text format in the Connect-Info attribute. Everything else
would be in new VSAs with only one VSA encoding defined for each item
instead of the multiple options (likely based on what different vendors
have happened to implement so far) in the draft (e.g., WIFIGEN having
two different ways of indicating the high level Wi-Fi generation of IEEE
802.11 amendment defining that Wi-Fi generation).

All the non-STA-specific items like channel/operating class (i.e.,
identification of an operating channel), noise level, channel
utilization, backhaul link throughput/latency, and STA count on the
radio should be kept separate and each of those would be in their own
VSA anyway so this confusing combination of them with per-STA
information in a single string attribute would be avoided.


PS.

I used "the upstream project" as a reference to the
git://git.w1.fi/hostap.git repository since there was an inaccurate
comment about modifications to src/wifi_stats/wifi_stats.c which made be
believe this was about some other repository that has changes that I
have not seen before (i.e., not the upstream project's repository).

-- 
Jouni Malinen                                            PGP id EFC895FA