[PATCH wireless-next v8 2/3] wifi: cfg80211: add initial UHR support

[Johannes Berg]

Hi,

> This approach looks well suited to handling overlapping update scenarios.
> 
> To make sure I understand it correctly, I’d like to walk through a
> concise example where a UHR critical update and a CSA overlap on link 0
> of a 3‑link AP MLD.

Well, so honestly, you should probably treat what I write as equivalent
to a paper napkin sketch during a night of drinking ;-)

I surely didn't think it totally through. I was just trying to
illustrate that I feel like we need to have some kind of new design for
all these overlapping updates (CSA, BSS color change, EHT and UHR
critical updates?) than the piecemeal design we have now.

And, importantly, that perhaps I think that this means we need to have
"post-update UHR operation" more than the individual UHR operation
updates broken out - which after all is where we started from.


> t1: A UHR critical update is triggered. hostapd sends
> NL80211_CMD_START_MLD_BSS_UPDATE with an advanced notification (5
> TBTTs), post‑interval (5 TBTTs), and the beacon template with UHR
> parameters update element for link 0. Timers start in mac80211, and
> hostapd receives cookie X.

Don't know if timers would be really in mac80211 - I guess if the driver
pulls each individual beacon then mac80211 could handle the countdown,
but otherwise this might just be given to firmware.

Also I guess the counter would have offset(s) from the start, i.e. the
beacon template would be in this operation already. Or maybe even beacon
updates for multiple links? Don't know if that really matters much
either way.

> t2: hostapd sends NL80211_CMD_UPDATE_AP with cookie X and offset where
> the counter is updated for link 1 (and then link 2).
> 
> the countdown values would be handled in mac80211 with the offset
> mentioned similar to ieee80211_set_beacon_cntdwn().

Sort of, yeah. I imagined that the CMD_UPDATE_AP would come with a list
of "cookie X: { offset X_1, offset X_2 }, cookie Y: { offset Y_1 }" or
something like that.

> t3: Before the UHR advanced interval completes, a CSA is triggered (due
> to radar or user‑initiated). Another NL80211_CMD_START_MLD_BSS_UPDATE is
> issued with CSA countdown 5, including CSA and after beacon templates.
> The after template carries cookie X and the offset. Since UHR CU is
> already in progress, hostapd could also include an updated parameters
> update element. 

Would have to, I think? I think in your example it's unlikely the _after
CSA_ template still has cookie X / offset(s) X_n, since you only had 10
beacon intervals overall for the UHR critical update and CSA might be
longer, but we could also imagine the UHR critical update was advertised
for a longer time.

> Also, an updated UHR operation element which can be
> modified in after beacon template if CSA finishes after the UHR CU
> advance interval. (why to provide the UHR operation element separately
> is because the advance notification can be before or after the CSA
> finalize).
> hostapd then receives cookie Y for the CSA.

This could get trickier than I imagined - you now have three periods of
time:

 - now
 - after CSA but before UHR update
 - after UHR update

and actually all three might need different UHR operation, since the CSA
can change the bandwidth and therefore e.g. DBE/NPCA. The intermediate
period ("after CSA but before UHR update") can be captured by the CSA
operation (given a template/UHR operation for after) easily.

But I was imagining we capture all this in the operations already, so I
guess to do that we would need a "NL80211_CMD_MODIFY_MLD_BSS_UPDATE"
command that takes the cookie and updates the post-operation values, so
that the changes due to the CSA could be taken into account in the
previously started UHR update.

FWIW, I was also kind of imagining that we'd design this combined update
command in a way that it replaces the CSA and color change commands,
handles the proposed link removal thing from Lorenzo, and then we don't
need to handle overlapping operations of all kinds, just of this new
kind that can do many different things. Not a huge difference though
since CSA/CCA would map to a subset of the new "thing".


> t4: hostapd issues NL80211_CMD_UPDATE_AP for link 1 with cookie X (UHR
> offset) and cookie Y (CSA offset), followed by link 2.

Not sure really about this. You also need new beacon templates for the
two periods I mentioned above ("after CSA but before UHR update" and
"after UHR update").


I think in my head the beacon templates for post-operations for all
links would've been handle by NL80211_CMD_START_MLD_BSS_UPDATE and, as I
discovered above, NL80211_CMD_MODIFY_MLD_BSS_UPDATE, rather than by
NL80211_CMD_UPDATE_AP.

I was, however, imagining that updates to the *current* template could
still happen via NL80211_CMD_UPDATE_AP, so - let's build a side branch
here first, e.g.:

      - we start UHR update to happen in 10 beacon intervals
        - this comes with a post-update template and post-update UHR operation
      - something else happens, e.g. HT mixed mode needs updating
        in this case, NL80211_CMD_UPDATE_AP could happen with the cookie(s)
        and offset(s) for the _current_ beacon
      
      Although I think perhaps this ends up being racy, and in fact hostapd
      would need to use a hypothetical NL80211_CMD_MODIFY_MLD_BSS_UPDATE again
      to update the link's beacon for HT mixed mode for all of the ongoing BSS
      updates and their post beacon(s)?

Anyway, back to your scenario:

> t5: When the UHR advanced notification interval expires, the CSA after
> beacon template is updated to reflect the new operation element by
> mac80211 or getting it from hostapd.

Yeah so that's also an option, if we think it'd work / not be too racy?
As I wrote, I was thinking CSA becomes another MLD BSS update and then
the post-CSA template is already given there.

> t6: Once the CSA completes, the driver updates the after beacon template
> along with updated counter for UHR parameter update element. (since it
> will be in the post notification interval)
> 
> 
> t7: When the UHR post‑interval completes, the UHR parameter update
> element is removed. Since offsets are known, the driver can remove it
> from the latest beacon template.

I wasn't really imagining the driver would remove it I guess, but rather
a post-update template would be provided already.

Ah! I think you were maybe thinking "this is the offset where to
insert/remove the UHR Parameter Update element", and I was thinking
"this is the offset of the counter" so that we could also put it into
the RNR etc.?

> Please let me know if this sequence aligns with the intended behavior,
> or if I’m missing any edge cases.
> 
> Also, CSA during NPCA parameter update seems very tricky as the channel
> information advertised in NPCA may not be relevant when there is a CSA,
> perhaps stop the NPCA CU (still spec has not mentioned any details on
> the abort scenario though)

Right, it's a bit tricky all over for concurrency scenarios. I hear that
two UHR critical updates concurrently are not going to be allowed
though.

> Even, in case of link removal during UHR CU update, we need to stop the
> UHR CU.

Well if the link is removed then it probably isn't relevant to update it
any more anyway?

> Furthermore, the UHR capabilities carries the advance notification
> interval, post notification  (i guess yet to be added in element as I
> see it in "37-8—Enhanced Critical Updates Mechanism") and update
> indication in TIM interval, these intervals can be sent in the START_AP.
> I assume, these intervals cannot be modified dynamically as these are
> exchanged in assoc response (Will reconfirm again).

Yeah, I agree, I would tend to think these are fixed.

> For beacon offloaded drivers, NL80211_CMD_START_MLD_BSS_UPDATE can be as
> a trigger. May be we can add the updated UHR operation element in case
> of UHR. So, that firmware/driver handle the timers as well as
> constructing the elements since "the encoding of fields in Mode specific
> parameters for any feature say DPS/NPCA/DBE etc.. is same as the
> corresponding field in operation parameters field for that feature" (but
> i see bit variations for NPCA between both)

The bit variants are going to get fixed, it's just not entirely clear
yet which way around.


> I guess, this means the proposal of having a separate netlink attribute
> for the UHR operation with _full_ data like is much useful.

OK. We can always also just parse it out anyway, just that element
(contents) isn't really too difficult to get at.

> Still, we are thinking through on all the other cases of wifi-7/CCA etc..

Of course.

Thanks,
johannes