[DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP
Ramanathan Choodamani
quic_rchoodam at quicinc.com
Tue Jul 1 12:30:36 PDT 2025
On 6/27/2025 12:24 AM, Johannes Berg wrote:
> Hi,
>
> (With my cfg80211/mac80211 maintainer hat on)
>
>> 2.1.3 - QoS Provisioning
>> -------------------------
>>
>> Hostapd extracts the QoS parameters from SCS/MSCS request, and
>> sends the parameters via NL80211 command (NL80211_CMD_QOS_MGMT).
>
> Do you have any idea yet what that would entail? I'm thinking it would
> also need add/remove, perhaps, and some kind of lifetime tracking on the
> station?
>
Yes you're right Johannes! The hostapd will maintain a per-STA based database of
each and every param within a request received.
If a request to ADD is received with SCS/MSCS params, the hostapd maintains them
on a sta_info struct per STA (that sent the request)and then sends them to the
driver via NL80211 framework.
If a new request is sent to modify/delete the params, the hostapd
modifies/deletes them within STA struct and then conveys the same to
the driver.
>>
>> 2.1.4 - Networking Provisioning
>> -------------------------------
>> Hostapd if required and as indicated by the WLAN driver
>> capabilities, would add rules in the netfilter subsystem
>> via libnftables, such that flows matching the TCLAS
>> parameters are marked with certain meta data using skb->mark
>> to assist in prioritization in the MSDU processing in the WLAN
>> driver data path.
>>
>> In MSCS, hostapd will receive the Rx flow tuple from WLAN
>> driver using NL80211 command (NL80211_CMD_QOS_MGMT) and then
>> make a decision to install an nftable rule in the netfilter
>> subsystem based on MSCS parameters exchanged
>> during handshake.
>>
>> The WLAN driver will be responsible for classifying the
>> new flow received and parse the tuple information from the MSDU
>> and use the framework to send event to hostapd. For
>> identifying a new flow, the WLAN driver can make use of
>> any HW offload assist features it supports, as maintaining
>> flow information in software on a per-packet basis will be
>> expensive for flow classification.
>
> How would the classification propagate through the layers?
>
The classification happens for the DL packets as mentioned in the RFC.
Here's a short description on how it happens:
(Refer to the diagram added at the start of Section 2.3 -
Data Path (MSCS/SCS) - done at WLAN driver).
1. The rule match happens at NFT for DL packet arriving from the
network stack.
2. NFT looks at the skb->mark to see if any special provisioning is done.
3. Since the rule was indeed provisioned by hostapd to the NFT, skb->mark
will have classification details (whether the packet has to be
classified or not).
4. The NFT gives this packet to the network stack which then gives it
to the WLAN driver via mac80211 (mac80211 uses drv_tx() to send to
WLAN driver).
The mac80211 layer will just pass this packet to the WLAN driver.
5. Since the classification is done at the WLAN driver, it looks at
the skb->mark and then decides how to classify the packet using the
initially passed on params from hostapd when it received the request
from STA.
>> (B) cfg80211
>> -------------
>>
>> The cfg80211 layer receives the NL(NL80211_CMD_QOS_MGMT), parses
>> the parameters and passes further down into the mac80211 layer.
>>
>> (C) mac80211
>> -------------
>>
>> The mac80211 calls into the WLAN driver with the QoS and
>> networking parameters.
>>
>> (D) WLAN driver
>> -----------------
>>
>> The WLAN driver receives the QoS characteristics and the
>> TCLAS elements and can do the required resource allocation and
>> the Firmware(FW)/Hardware(HW) programming based on the underlying HW
>> capabilities.
>
> Without really going into the actual implementation, structurally, what
> would this contain? And architecturally, is it really just one set of
> parameters? It would seem to be more specific, like for a given station?
>
The WLAN Driver maintains a peer STA database having the QoS params that
hostapd sends.
This structure will be looking something like this:
struct qm_params {
struct tclas_params tclas_tuple[]; //the actual tclas element
sent by STA in request.
struct qos_characteristics qos_info[]; //The QoS characteristics
info sent by STA.
u8 tid;
u8 tclas_mask;
..
..
};
This structure will be stored inside a STA.
Every new request having new tclas_tuple/qos_info will be stored in
this struct.
>> 2.3 - Data Path (MSCS/SCS) - done at WLAN driver
>> --------------------------------------------------
>> 3. Hostapd provisions the rule to NFT
>> ┌─────────────────────────────────┐
>> │ │ N/W provisioning
>> │ hostapd ┌─────────┐┼────────────────────────┐
>> │ │libnftnl ││ │
>> └──────────────────────└──▲──────┘┘ │
>> user space │ │
>> ───────────────────────────────────┼──────────────── │
>> ┌──────────────────────────┼─────────┐ │
>> │ │ │ 4. │
>> kernel space │ ┌────────────────────────┴──────┐ │ NFT updates skb->mark│
>> │ │ nl80211/cfg80211 │ │ while adding the rule│
>> │ │ │ │ ┌──────────────────┼──┐
>> │ └────────────────────────▲──────┘ │ │ │ │
>> │ │ │ │ │ │
>> │ ┌────────────────────────┼──────┐ │ │ Linux N/W stack │ │
>> │ │ mac80211 ◄──┼───┼ │ │
>> │ │ │ │ │ ┌──────────▼─┐│
>> │ └───┬────────────────────▲──────┘ │ │ │netfilter ││
>> 5. The DL packet │ │ │ │ └───────└────────────┘┘
>> comes with │ ┌───▼────────────────────┼──────┐ │
>> skb->mark │ │ │ │
>> which is used │ │ │ │
>> for classification │ │ WLAN drv │ │2.
>> along with │ │ │ │Driver then programs the rule to hostapd
>> stored QoS │ │ │ │using NL80211
>> params at the │ │ │ │
>> driver │ │ │ │1.
>> │ └───┬────────────────────▲──────┘ │For MSCS flows, driver learns a new rx flow
>> │ │ │ │using HW assist
>> └─────┼────────────────────┼─────────┘
>> ┌─────▼────────────────────┼─────────┐
>> │ │
>> │ Hardware │
>> │ │
>> └────────────────────────────────────┘
>
> Terminology wise, "driver then programs the rule to hostapd" seems ...
> confusing. It's more like "notifies hostapd of the new flow" or so?
>
Yes you're right! In addition to this, few more details:
The step 1. and 2. from the diagram are only for MSCS protocol (not for SCS).
The MSCS protocol relies on Rx packets from STA to AP, since it does
not specify any traffic tuple info in the MSCS request, unlike SCS.
(For understanding the difference, refer to protocol handshake diagrams
in Section 3.2.1.1 & 3.2.2.1)
So when an Rx packet is received, Driver learns whether it is a new flow
using HW assist. It then extracts the tuple info (src_ip, dst_ip ...)
from the msdu and then informs hostapd to create a rule in NFT.
>> * The Datapath decision making logic for the QoS features
>> would be handled in the WLAN driver.
>
> What decision making logic is even in the datapath?
>
I think, the explanation is same as what I described above (the step-by-step flow)
For MSCS, more details below.
>> * In MSCS, Driver will be responsible to track all the uplink flows
>> for a non-AP STA with MSCS session, based on
>> TCLAS mask and should prioritize the corresponding downlink flows.
>>
>> * For prioritization in DL for MSCS, the driver should notify hostapd
>> using NL80211 framework (via mac80211, cfg80211) to program the
>> netfilter rules, when a new Rx uplink flow is received.
>
> Here I don't follow - I can see how uplink needs the driver to
> parse/classify the flow and tell hostapd about the mark or so, but on DL
> the whole thing starts at higher layers, no?
>
Please refer to my response below, for your last query:
>> * As mentioned in Section 2.1.4., In MSCS hostapd receives the
>> Rx flow tuple from the driver via NL80211_CMD_QOS_MGMT,
>> then decides whether to install an nftables rule in netfilter
>> based on MSCS handshake parameters.
>
> For an uplink flow, I'm not even sure what netfilter rules need to be
> there be at all? Once a packet is received, it's effectively game over
> for classification / air competition / etc. no?
>
> johannes
The MSCS protocol relies on Rx packets from STA to AP, since it does
not specify any traffic tuple info in the MSCS request, unlike SCS.
So, the driver, even if it extracts the tuple info from the Rx MSDU, it
informs the hostapd with the reverse of this tuple info (because,
the reverse of this UL flow, will be the DL flow - hence the name
Mirrored SCS)
Eg. if src_ip = 192.168.1.10 and dst_ip = 192.168.1.20 in a Rx MSDU
then the response sent from AP to STA i.e the Tx MSDU will be this:
src_ip = (dst_ip of Rx MSDU) = 192.168.1.20 and dst_ip = (src_ip
of Rx MSDU) = 192.168.1.10
Let's take one more example:
Driver receives an Rx UDP traffic packet with these tuple params:
driver extracted rx_msdu_params = {
sip = 192.168.1.10
dip = 192.168.1.20
sport = 50103
dport = 50102
proto = udp
dscp = 30
tid = 4
};
The driver notifies the hostapd to program the reverse of this
flow to NFT (so that when DL packet arrives with the programmed
rule, it will be classified with same tid as Uplink)
driver programmed mirrored_msdu_params = {
sip = 192.168.1.20
dip = 192.168.1.10
sport = 50102
dport = 50103
proto = udp
dscp = 30
tid = 4
};
So driver notifies the mirror(extracted Rx tuple info) to hostapd, which
then programs the rule to NFT for DL classification.
So when NFT rule match happens for DL, it will be sent with
same tid as Rx (in this example, dl_tid = 4)
You can also refer to IEEE Std 802.11-2024 Section 11.25.3.
Hope this clarifies.
/ram
More information about the ath12k
mailing list