WBA/IETF Connect-Info Implementation under way

[Joey Padden]

Thanks for the explanation, I understand your position better now.

Are you interested in joining the WBA discussion? Might be helpful given the level of feedback you have. I believe Qualcomm is a member already so you could join the call with little friction and provide your input there, it’d be valuable. 

One further question here, why in your view is a new VSA better than using Connect-Info? Connect-Info seems to me to have limited information and usefulness with just WFA-GEN-NAME typically seen today from many vendors.

BR,
Joey

> On Oct 7, 2025, at 2:58 PM, Jouni Malinen <j at w1.fi> wrote:
> 
> 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