[DESIGN RFC] Critical Update handling in the kernel

[Aditya Kumar Singh]

[snip]

> 
> I still don't like the parsing though. Like I said above, that's a lot
> of complexity that simply doesn't even exist when hostapd controls all
> the updates.
> 
> 
> I really would have envisioned this much more along the lines of having
> hostapd start the channel switch (WLOG on link 1 out of links 1 and 2)
> with an nl80211 message that has:
> 
>   - post-switch beacon for link 1
>   - during-switch beacon for link 1
>     - CSA counter offsets for CSA, eCSA, etc. elements
>   - post-switch beacon for link 2 (?)
>   - during-switch beacon for link 2
>     - CSA counter offsets for link 1's CSA counter
>       (for all the per-STA profile link 1 elements)
> 
> isn't that pretty much it? All the BPCC is well-contained within that
> and maintained by hostapd.
> 
> I'll agree that this limits to only doing a single channel switch at a
> time across the whole MLD, but maybe that's not the most problematic
> thing?
> 
> 
> OK I guess I'll have to think about this more ...

I've also spent some time thinking through the idea of handling frame 
formation at the hostapd level and simply notifying the kernel. Here are 
the key points I arrived at:

1. Using a single Netlink (NL) command:
----------------------------------------
The average beacon size is around 500 bytes. During Channel Switch 
Announcement (CSA), we need to send two beacons—one for CSA and one 
post-CSA resulting in approximately 1000 bytes per link. If we apply 
this across all 14 additional links (MLD can have max 15 links), the 
total data sent via NL becomes roughly 15,000 bytes. This is quite large 
and may exceed what the NL socket buffer can reasonably handle.


2. Using multiple NL command for each link:
-------------------------------------------
In the case of a 3-link AP MLD, where Link 1 initiates a Channel Switch 
Announcement (CSA), the sequence would look like this:

Link 1 starts CSA via NL command:
     * csa_beacon
         * CSA and ECSA offsets
     * after_beacon

Link 2 beacon update via NL:
     * Beacon data
         * Partner offsets
             * CSA and ECSA offsets
Link 3 beacon update via NL:
     * Beacon data
         * Partner offsets
             * CSA and ECSA offsets


Once CSA is completed on Link 1, both Link 2 and Link 3 will require 
another beacon update via NL to reflect the new state.

The complexity increases when, during Link 1’s ongoing CSA, either Link 
2 or Link 3 initiates a CSA or a Color Change Announcement (CCA). In 
such cases, Link 1 must update its beacon to include elements from Link 
2 or Link 3’s per-STA profile. However, since Link 1 is already 
undergoing CSA, it cannot perform a beacon update at that time, leading 
to a conflict in update handling.

To keep things simple, one might suggest allowing only one Channel 
Switch Announcement (CSA) at a time within an MLD. However, this 
approach isn't feasible. For instance, consider a 5 GHz link that's part 
of an MLD. If another link is performing a CSA and the 5 GHz link 
detects radar, it must immediately initiate its own CSA and vacate the 
radar channel. In such scenarios, enforcing a single CSA per MLD is 
impractical and could lead to regulatory non-compliance or operational 
issues.


Even if we somehow manage to address the earlier issues, a new challenge 
arises with managing moving offsets and tracking which offset 
corresponds to which link relative to the reporting link.

For example, consider an AP MLD with three links. Suppose Link 3 
initiates a CSA. As a result, Link 2 receives a beacon update that 
includes a CSA element in Link 3’s per-STA profile. Let’s assume the 
counter offset for this CSA is at position 200.

Now, if Link 1 also starts a CSA, the next time Link 2’s beacon is 
updated, it will iterate through all partner links from Link 0 to the 
maximum. Since Link 1 comes before Link 3, its CSA element will be added 
first, followed by Link 3’s. This causes Link 3’s CSA element to shift 
down in the beacon, and its counter offset may now move to position 400.

This dynamic shifting of offsets makes it difficult to reliably track 
which offset belongs to which link, especially when multiple CSAs are 
active and beacon contents are updated frequently.

Another challenge with handling multiple NL (non-link-specific) beacon 
updates is the need to wait until all beacon updates are received by the 
kernel. This requires implementing a "wait for completion" mechanism.

However, since waiting indefinitely isn't practical, there must be a 
timeout or fallback threshold. This introduces a few critical questions:
   * What happens if one of the links fails to send its beacon update 
within the timeout?
   * Should the CSA proceed with the updates received so far, or should 
the entire CSA process be aborted?

These decisions are non-trivial. Continuing the CSA without all updates 
might lead to inconsistent behavior across links, while aborting the CSA 
could delay critical operations like radar avoidance. A well-defined 
policy or fallback strategy is essential to handle such partial update 
scenarios gracefully.

-------------

Considering all the challenges discussed, I still believe that handling 
beacon manipulation at the kernel level is the most effective approach 
especially for critical updates. This method offers the best possible 
way to manage the critical update feature purely through software, 
ensuring reliability and consistency across links.

Let me know your thoughts on this?


-- 
Aditya