* [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP
@ 2025-06-24 20:57 Ramanathan Choodamani
2025-06-24 22:31 ` Ben Greear
2025-06-27 7:24 ` Johannes Berg
0 siblings, 2 replies; 7+ messages in thread
From: Ramanathan Choodamani @ 2025-06-24 20:57 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, ath12k, quic_rchoodam
===================================
Robust AV streaming protocols - QoS
===================================
The Robust AV stream protocols are mobile centric protocols - meaning they
are initiated by a non-AP STA to the AP. These protocols are implemented
at the Access Point (AP) to classify packets sent to the non-AP STA which requests
classification using action frames. The non-AP STA initiates Robust AV streaming
action frames requesting for specific classification for the IP packets
destined to the non-AP STA from the AP. These parameters can be negotiated by both
AP and non-AP STA.
Upon successful handshake, The AP classifies incoming individually addressed MSDUs
(Mac Service Data Unit) based upon parameters provided by the non-AP STA or
notifies the non-AP STA to transmit MSDUs with preferred parameters based upon
what was exchanged.
Robust AV streaming improves AV (Audio and Video) streaming performance when
using IEEE Std 802.11 for consumer and enterprise applications.
Let's look at the Robust AV streaming protocols which are implemented as a
part of this design.
1. Robust AV streaming protocols - A bird's eye view
=====================================================
1.1. Stream Classification Service or SCS
------------------------------------------
In SCS - the non-AP STA specifies what level of classification it
expects from the AP beforehand, by specifying these things explicitly
in the Robust AV action frame:
1. Traffic tuple parameters - The description of traffic that has to be
classified by the AP
2. QoS characteristics - How the classification has to be done
3. UP value to set
SCS can be also used for Uplink traffic classification.
The AP fetches the UL data from non-AP STA by transmitting the
trigger frames containing RU allocation for non-AP STA with
Preferred AC field equivalent to the UP value specified during handshake.
Once accepted, the AP uses 2. and 3. to classify the traffic
matching the exact parameters as 1.
1.2. Mirrored Stream Classification Service or M-SCS
-----------------------------------------------------
In the mirrored SCS as well, the non-AP STA does not specify
the actual traffic to be classified as a part of the action
frame.
Instead, the AP is expected to monitor the uplink flow sent
by the non-AP STA and use the same UP of the uplink flow, for the DL
traffic if the DL flow is the "mirrored version" of the previously
received UL flow.
For more details on the protocol aspects, refer to Section 3. first
which talks about the protocol in detail.
For design, refer directly to the next Section 2.
2. Design Proposal
===================
2.1. Overview
-------------
┌─────────────────────────────────â”
MLME │ │ N/W provisioning
QoS Provisioning│ hostapd ┌─────────â”┼────────────────â”
QoS accounting │ │libnftnl ││ │
└────┬─────────────────└──▲──────┘┘ │
user space │ │ │
│ │ │
──────────────┼────────────────────┼──────────────── │
┌─────┼────────────────────┼─────────┠│
kernel space │ ┌───▼────────────────────┴──────┠│ │
│ │ nl80211/cfg80211 │ │ │
│ │ │ │ ┌──────────▼────────â”
│ └───┬────────────────────▲──────┘ │ │ │
│ │ │ │ │ │
│ ┌───▼────────────────────┼──────┠│ │ netfilter │
│ │ mac80211 │ │ │ │
│ │ │ │ │ │
│ └───┬────────────────────▲──────┘ │ │ │
│ │ │ │ └───────────────────┘
│ ┌───▼────────────────────┼──────┠│
│ │ │ │
│ │ │ │
Resource alloc │ │ WLAN drv │ │ Flow monitoring for new Rx flows
HW programming │ │ │ │ Sending flow info to hostapd
│ │ │ │
│ │ │ │
│ │ │ │
│ └───┬────────────────────▲──────┘ │
│ │ │ │
└─────┼────────────────────┼─────────┘
┌─────▼────────────────────┼─────────â”
│ │
│ Hardware │
│ │
└────────────────────────────────────┘
2.2. Control Path (MSCS/SCS)
----------------------------
The control path for the QoS management could be handled in the user space
- hostapd.
The kernel layers - cfg80211 and mac80211 could pass the required information
to the WLAN driver to program the underlying Firmware/Hardware
to achieve the expected prioritization.
(A) Hostapd
------------
2.2.1 - Capabilities advertisement
----------------------------------
The MSCS/SCS Capabilities Advertisement in beacon, probe
response and assoc response frames will be done at hostapd.
2.1.2 - Protocol Parsing
------------------------
The support to receive, parse, process MSCS and SCS request
action frames from non-AP STA will be done at hostapd.
The NL cmd NL80211_CMD_QOS_MGMT is used to send the parsed
SCS/MSCS descriptor data (Dialog token, QM type, Mac addr,
QM ID, QM Request type, TCLAS element, QoS Parameters,
TCLAS mask) to the kernel from hostapd.
Driver will advertise its capability to hostapd whether it
requires TCLAS rule provisioning in NFT to be carried out by
hostapd or it can take care of handling/provisioning the
networking rules.
The support to send MSCS, SCS response to non-AP STA will also be
done at hostapd.
IEEE Std 802.11-2024 Section 9.6.18 defines how the
Robust AV streaming action frames look like.
IEEE Std 802.11-2024 Section 9.4.2.120 specifies
the details of an SCS descriptor
IEEE Std 802.11-2024 Section 9.4.2.242 specifies the
details of an MSCS descriptor.
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).
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.
2.1.5 - Flow cleanup and Rule teardown
--------------------------------------
During scenarios, where non-AP STA sends a Request to delete/teardown
a session, the hostapd will be responsible for notifying
netfilter and the driver to remove the rules and associated
context.
The support to send unsolicited response to non-AP STA for rule
deletion or session teardown will also be present in hostapd,
after which hostapd will clean-up it's context and also notify
to WLAN driver and netfilter.
2.1.6. QoS Accounting
----------------------
Hostapd will maintain information per non-AP STA for the different
active QoS request.
2.1.7. User space cli commands (Proposed commands)
--------------------------------------------------
2.1.7.1. Config option to set MSCS/SCS during bring-up
------------------------------------------------------
MSCS and SCS features will be enabled during AP bring up.
The options "mscs" and "scs" will be added to the hostapd
config file.
mscs=<0/1>
scs=<0/1>;
where 0 - disable, 1 - enable.
Since these options are enabled only during bring up, they
will continue to remain enabled during the lifetime of the
BSS.
Once these features are enabled during bring up,
AP starts advertising MSCS and SCS capabilities in it's beacon,
probe response and assoc response frames.
The non-AP STA seeing these frames, realizes AP supports these
protocols and then sends the action frames.
If the AP does not support these protocols, then the AP
shall discard these action frames/descriptor elements sent by
non-AP STA.
2.1.7.2. User cli commands to send unsolicitied MSCS/SCS response
-----------------------------------------------------------------
The commands to set unsolicited response from hostapd will be
as follows:
To send unsolicited MSCS response:
hostapd_cli -i <interface> send_unsolicited_mscs_resp
<peer_macaddr> <status_code>
To send unsolicited SCS response:
hostapd_cli -i <interface> send_unsolicited_scs_resp
<peer_macaddr> --scsid <scsid> <status_code>
The unsolicited Robust AV responses
(SCS and MSCS responses) are sent by AP to a non-AP STA to
either teardown an MSCS session or terminate a SCS based
rule for reasons like TCLAS_PROCESSING_TERMINATED when the
AP is no longer able to classify the traffic with the
specified QoS parameters.
The AP should send Action frames with SCS/MSCS response
to non-AP STA with the status code specified in the user
command cli.
(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.
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 │
│ │
└────────────────────────────────────┘
* The Datapath decision making logic for the QoS features
would be handled in the WLAN driver.
* 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.
* 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.
* Based on the QoS parameters maintained at the driver, and the
skb->mark as received in the flows and the QoS parameter requirements
should be met as specified in the request.
* Maintain telemetry for active SCS/MSCS requests per non-AP STA for
debug purposes.
Considering a lot of Hardware(HW) and Firmware(FW) assists would be required
for the following, it would be appropriate to implement the
Datapath in the specific WLAN drivers.
The WLAN driver responsibilities are as follows:
1. Learning all Rx flows in the uplink for MSCS clients
2. Prioritizing downlink flow with stringent latency KPI for AR/VR and
gaming use cases
3. In cases where vendor HW have offloads for such use cases,
where the HW can prioritize by just programming the TCLAS elements
and mapping the relevant QoS characteristics
3. Additional details - Protocol overview
=========================================
3.1. What exists today in mac80211? - DSCP-UP mapping and QoS Map set
---------------------------------------------------------------------
An Access Point supporting QoS Management keeps a default DSCP-UP mapping
table (RFC 8325) to map a DSCP (IP packet header field) to a specific User
Priority value in the QoS-Control field of the IEEE-802.11 header.
When DSCP-UP mapping is enabled, The Access point uses this table and
assigns UP of the IP packets sent it to its associated non-AP STAs
based on the DSCP marking.
The AP even has a provision to configure a specific DSCP-UP mapping using
QoS Map set (instead of using the default table). When this QoS Map is
configured, the AP sends a QoS Map Configure frame containing this
QoS Map element to it's associated non-AP STAs that indicate support for
QoS Map. The AP then shall use this table instead of the default one
for mapping UPs of the IP packets.
The implementation to use DSCP-UP mapping table exists in mac80211
datapath today.
3.2. Robust AV streaming Features: A closer view
---------------------------------------------------
Reference: IEEE Std 802.11-2024
Section 11.25
3.2.1. SCS - Protocol details
------------------------------
Refer to IEEE Std 802.11-2024 Section 11.25.2 SCS Procedures
(Stream Classification Service) for more details.
A non-AP STA can request SCS by sending an SCS Request frame with a
Descriptor element marked as “Add†or “Changeâ€.
The non-AP STA specifies the below elements in the SCS descriptor
in the SCS request action frame.
Downlink (DL) SCS:
- Either the UP (User Priority) (or TID) alone or additionally a
set of QoS characteristics(eg: Service Interval, Delay bound,
Throughput) with TID.
- TCLAS (Traffic Classifier) element (eg: Type 4 - Source IP,
Destination IP, Protocol, Source Port, Destination Port).
These parameters define how MSDUs are classified and prioritized.
The AP prioritizes the flow (as identified by TCLAS elements)
in the Downlink Tx Direction.
Uplink (UL) SCS:
- Set of QoS characteristics for uplink prioritization.
- No Intra access category and no TCLAS element is present in
the request frame.
The QoS parameters are programmed in AP to fetch the UL data from
non-AP STA by transmitting the trigger frames.
The AP can choose to accept or decline the request sent by the
non-AP STA.
Once accepted, for DL, the AP will classify the downlink packets
matching that TCLAS element traffic parameters and set the
TID value for the DL traffic flow to prioritize.
For UL, AP will start sending trigger frames to station based on the
QoS parameter values.
3.2.1.1. Protocol handshake diagram
-------------------------------------
┌─────────────────┠┌─────────────────â”
│ │ │ │
│ AP │ │ STA │
│ │ │ │
│ │ │ │
└──────┬──────────┘ └────────┬────────┘
│ ┌───────────┌──────────┌──────────┌──────────────────────────────────┌───────────────┠│
│ │Robust AV │ │ Intra- │ TCLAS element │ │ │
│ │ │ SCSID = 1│ Acces │type = 4, mask = 01011111 │ QoS │ │
│ │ SCS.req │ │ category │params = {v=4,sip=192.168.1.100, │ │ │
│ │ │ │ │ dip=192.168.1.107, │characteristics│ │
│ │ │ │ UP = 6 │ sp=5400, dp=10400, │ (Optional) │ │
│ │ │ │(Optional)│ proto=tcp} (optional) │ │ │
│ └───────────└──────────└──────────└──────────────────────────────────└───────────────┘ │
│◄─────────────────────────────────────────────────────────────────────────────────────────────────┼
│ SCS Request │
│ │
│ │
│ │
│ │
│ │
│ │
│ ┌───────────┌──────────────┠│
│ │ │ │ │
│ │ Robust AV │ SCSID = 1 │ │
│ │ │ │ │
│ │ SCS.resp │ Status = OK │ │
│ │ │ │ │
│ │ │ │ │
│ └───────────└──────────────┘ │
│ │
┼──────────────────────────────────────────────────────────────────────────────────────────────────►
│ SCS Response │
│ │
│ │
│ │
│ │
3.2.1.2. DL traffic classification using SCS handshake params
-------------------------------------------------------------
┌────────────────────┠┌────────────────────â”
│ │ │ │
│ AP │ │ STA │
│ │ │ │
│ │ │ │
└─────────┬──────────┘ └──────────┬─────────┘
│ DOWNLINK CLASSIFIED TRAFFIC │
┼───────────────────────────────────────────────────────────────────────────►
│ ┌─────────────────────────────────────────────────────┠│
│ │mac hdr mac_addr = sta macaddr │ │
│ │ up = 6 │ │
│ ┌─────────────────────────────────────────────────────┠│
│ │ipv4 hdr │ │
│ │ v = 4 dscp = X │ │
│ │ sip = 192.168.1.100 │ │
│ │ dip = 192.168.1.107 │ │
│ │ proto = tcp │ │
│ ┌─────────────────────────────────────────────────────┠│
│ │tcp hdr │ │
│ │ sp = 5400 │ │
│ │ dp = 10400 │ │
│ ┌─────────────────────────────────────────────────────┠│
│ │ │ │
│ │ │ │
│ │payload │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
│ │
3.2.2. Mirrored SCS - Protocol details
-------------------------------------
Refer to IEEE Std 802.11-2024 Section 11.25.3 MSCS procedures
(Mirrored Stream Classification Service) for more details
Initially, the non-AP STA specifies the UP(User Priority)(or TID)
and the TCLAS(Traffic Classifier) mask for prioritization via
action frames.
The TCLAS mask element consists of Classifier mask which specifies
what params to compare with the UL traffic received while
classifying the DL traffic.
The AP checks the Rx Uplink flow from the non-AP STA matching the
classifier mask and classifies the mirrored flow (by reversing
the 5 tuple of the flow as seen in
uplink) in the downlink direction with the TID of received Rx flow.
3.2.2.1. Protocol Handshake diagram
-----------------------------------
┌─────────────────┠┌──────────────â”
│ │ │ │
│ AP │ │ STA │
│ │ │ │
│ │ │ │
└──────┬──────────┘ TCLAS Mask element └────────┬─────┘
│ ┌──────────┌──────────────────────────┌──────────────────────────┠│
│ │Robust AV │ User priority bitmap = │ │ │
│ │ │ 1111 0000 │ type = 4 │ │
│ │MSCS.req │ │ │ │
│ │ │ User priority limit = 7 │ mask = 0101 1111 │ │
│ │ │ │ │ │
│ │ │ Stream timeout = 60000 TU│ │ │
│ └──────────└──────────────────────────└──────────────────────────┘ │
│◄──────────────────────────────────────────────────────────────────────────────────────┼
│ MSCS Request │
│ │
│ │
│ │
│ │
│ │
│ │
│ ┌───────────┌──────────────┠│
│ │ │ │ │
│ │ Robust AV │ Dialog token │ │
│ │ │ │ │
│ │MSCS.resp │ Status = OK │ │
│ │ │ │ │
│ │ │ │ │
│ └───────────└──────────────┘ │
│ │
┼───────────────────────────────────────────────────────────────────────────────────────►
│ MSCS Response │
│ │
│ │
│ │
│ │
│ │
└ ┘
3.2.2.2. DL traffic classification using MSCS
---------------------------------------------
┌────────────────────┠┌────────────────────â”
│ │ │ │
│ AP │ │ STA │
│ │ │ │
│ │ │ │
└─────────┬──────────┘ └──────────┬─────────┘
│ UPLINK TRAFFIC │
│◄──────────────────────────────────────────────────────────────────────────┼
│ ┌─────────────────────────────────────────────────────┠│
│ │mac hdr mac_addr = ap macaddr │ │
│ │ up = 6 │ │
│ ┌─────────────────────────────────────────────────────┠│
│ │ipv4 hdr │ │
│ │ v = 4 dscp = 30 │ │
│ │ sip = 192.168.1.107 │ │
│ │ dip = 192.168.1.100 │ │
│ │ proto = tcp │ │
│ ┌─────────────────────────────────────────────────────┠│
│ │tcp hdr │ │
│ │ sp = 10400 │ │
│ │ dp = 5400 │ │
│ ┌─────────────────────────────────────────────────────┠│
│ │ │ │
│ │ │ │
│ │payload │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ │
│ DOWNLINK CLASSIFIED TRAFFIC │
─────────► ├───────────────────────────────────────────────────────────────────────────►
│ ┌─────────────────────────────────────────────────────┠│
AP sets the │ │mac hdr mac_addr = sta macaddr │ │
same TID │ │ up = 6 │ │
for the mirrored │ ┌─────────────────────────────────────────────────────┠│
DL flow │ │ipv4 hdr │ │
The tuple params │ │ v = 4 dscp = X │ │
of DL traffic │ │ sip = 192.168.1.100 │ │
are the exact │ │ dip = 192.168.1.107 │ │
mirrored values │ │ proto = tcp │ │
of the UL traffic│ ┌─────────────────────────────────────────────────────┠│
which was recvd │ │tcp hdr │ │
│ │ sp = 5400 │ │
│ │ dp = 10400 │ │
│ ┌─────────────────────────────────────────────────────┠│
│ │ │ │
│ │ │ │
│ │payload │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ │
│ │
┘ │
Public comments on this proposal are welcomed.
/ram
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP
2025-06-24 20:57 [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP Ramanathan Choodamani
@ 2025-06-24 22:31 ` Ben Greear
2025-07-01 19:38 ` Ramanathan Choodamani
2025-07-02 9:57 ` Nicolas Cavallari
2025-06-27 7:24 ` Johannes Berg
1 sibling, 2 replies; 7+ messages in thread
From: Ben Greear @ 2025-06-24 22:31 UTC (permalink / raw)
To: Ramanathan Choodamani, linux-wireless; +Cc: netdev, ath12k
On 6/24/25 13:57, Ramanathan Choodamani wrote:
> ===================================
> Robust AV streaming protocols - QoS
> ===================================
>
> The Robust AV stream protocols are mobile centric protocols - meaning they
> are initiated by a non-AP STA to the AP. These protocols are implemented
> at the Access Point (AP) to classify packets sent to the non-AP STA which requests
> classification using action frames. The non-AP STA initiates Robust AV streaming
> action frames requesting for specific classification for the IP packets
> destined to the non-AP STA from the AP. These parameters can be negotiated by both
> AP and non-AP STA.
>
> Upon successful handshake, The AP classifies incoming individually addressed MSDUs
> (Mac Service Data Unit) based upon parameters provided by the non-AP STA or
> notifies the non-AP STA to transmit MSDUs with preferred parameters based upon
> what was exchanged.
>
> Robust AV streaming improves AV (Audio and Video) streaming performance when
> using IEEE Std 802.11 for consumer and enterprise applications.
>
> Let's look at the Robust AV streaming protocols which are implemented as a
> part of this design.
Thank you for posting this and for the beautiful ascii diagrams!
Since this will be poking netfilter rules into the kernel,
is there a good way to clean up all rules created by a previous
hostapd process in case hostapd crashes or is killed hard and
cannot do its own cleanup? Maybe the rules could have some
special marking that is configurable per hostapd (or per AP or BSS or something)
so that a (re)started hostapd could clean up any leftovers from a
previous instance?
And, is there a mechanism to clean up flows that a buggy non-AP STA
has requested but then forgot to terminate (like phone starts a video call,
requests some QoS, then forgets to tell AP that it is done with the call
and packets no longer need to be classified?)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP
2025-06-24 20:57 [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP Ramanathan Choodamani
2025-06-24 22:31 ` Ben Greear
@ 2025-06-27 7:24 ` Johannes Berg
2025-07-01 19:30 ` Ramanathan Choodamani
1 sibling, 1 reply; 7+ messages in thread
From: Johannes Berg @ 2025-06-27 7:24 UTC (permalink / raw)
To: Ramanathan Choodamani, linux-wireless; +Cc: netdev, ath12k
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?
>
> 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?
> (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?
> 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?
> * 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?
> * 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?
> * 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP
2025-06-27 7:24 ` Johannes Berg
@ 2025-07-01 19:30 ` Ramanathan Choodamani
0 siblings, 0 replies; 7+ messages in thread
From: Ramanathan Choodamani @ 2025-07-01 19:30 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: netdev, ath12k
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP
2025-06-24 22:31 ` Ben Greear
@ 2025-07-01 19:38 ` Ramanathan Choodamani
2025-07-01 20:17 ` Ben Greear
2025-07-02 9:57 ` Nicolas Cavallari
1 sibling, 1 reply; 7+ messages in thread
From: Ramanathan Choodamani @ 2025-07-01 19:38 UTC (permalink / raw)
To: Ben Greear, linux-wireless; +Cc: netdev, ath12k
On 6/24/2025 3:31 PM, Ben Greear wrote:
> On 6/24/25 13:57, Ramanathan Choodamani wrote:
>> ===================================
>> Robust AV streaming protocols - QoS
>> ===================================
>>
>> The Robust AV stream protocols are mobile centric protocols - meaning they
>> are initiated by a non-AP STA to the AP. These protocols are implemented
>> at the Access Point (AP) to classify packets sent to the non-AP STA which requests
>> classification using action frames. The non-AP STA initiates Robust AV streaming
>> action frames requesting for specific classification for the IP packets
>> destined to the non-AP STA from the AP. These parameters can be negotiated by both
>> AP and non-AP STA.
>>
>> Upon successful handshake, The AP classifies incoming individually addressed MSDUs
>> (Mac Service Data Unit) based upon parameters provided by the non-AP STA or
>> notifies the non-AP STA to transmit MSDUs with preferred parameters based upon
>> what was exchanged.
>>
>> Robust AV streaming improves AV (Audio and Video) streaming performance when
>> using IEEE Std 802.11 for consumer and enterprise applications.
>>
>> Let's look at the Robust AV streaming protocols which are implemented as a
>> part of this design.
>
> Thank you for posting this and for the beautiful ascii diagrams!
>
> Since this will be poking netfilter rules into the kernel,
> is there a good way to clean up all rules created by a previous
> hostapd process in case hostapd crashes or is killed hard and
> cannot do its own cleanup? Maybe the rules could have some
> special marking that is configurable per hostapd (or per AP or BSS or something)
> so that a (re)started hostapd could clean up any leftovers from a
> previous instance?
>
hostapd does its own cleanup (cleanup of stations and interfaces)
when it receives SIGTERM.
An nft chain is created for each AP netdev/interface.
The nft rule handle (stored in internal hostapd data structure) and
nft chain metadata can be used to cleanup/flush the nft rules as part of the
interface cleanup.
> And, is there a mechanism to clean up flows that a buggy non-AP STA
> has requested but then forgot to terminate (like phone starts a video call,
> requests some QoS, then forgets to tell AP that it is done with the call
> and packets no longer need to be classified?)
>
> Thanks,
> Ben
>
The scs objects of the stations will be cleaned up during the station
disconnect (by the AP which is maintaining them).
As part of this deletion, the nft rules are also deleted, using the
stored nft rule handle.
/ram
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP
2025-07-01 19:38 ` Ramanathan Choodamani
@ 2025-07-01 20:17 ` Ben Greear
0 siblings, 0 replies; 7+ messages in thread
From: Ben Greear @ 2025-07-01 20:17 UTC (permalink / raw)
To: Ramanathan Choodamani, linux-wireless; +Cc: netdev, ath12k
On 7/1/25 12:38, Ramanathan Choodamani wrote:
>
>
> On 6/24/2025 3:31 PM, Ben Greear wrote:
>> On 6/24/25 13:57, Ramanathan Choodamani wrote:
>>> ===================================
>>> Robust AV streaming protocols - QoS
>>> ===================================
>>>
>>> The Robust AV stream protocols are mobile centric protocols - meaning they
>>> are initiated by a non-AP STA to the AP. These protocols are implemented
>>> at the Access Point (AP) to classify packets sent to the non-AP STA which requests
>>> classification using action frames. The non-AP STA initiates Robust AV streaming
>>> action frames requesting for specific classification for the IP packets
>>> destined to the non-AP STA from the AP. These parameters can be negotiated by both
>>> AP and non-AP STA.
>>>
>>> Upon successful handshake, The AP classifies incoming individually addressed MSDUs
>>> (Mac Service Data Unit) based upon parameters provided by the non-AP STA or
>>> notifies the non-AP STA to transmit MSDUs with preferred parameters based upon
>>> what was exchanged.
>>>
>>> Robust AV streaming improves AV (Audio and Video) streaming performance when
>>> using IEEE Std 802.11 for consumer and enterprise applications.
>>>
>>> Let's look at the Robust AV streaming protocols which are implemented as a
>>> part of this design.
>>
>> Thank you for posting this and for the beautiful ascii diagrams!
>>
>> Since this will be poking netfilter rules into the kernel,
>> is there a good way to clean up all rules created by a previous
>> hostapd process in case hostapd crashes or is killed hard and
>> cannot do its own cleanup? Maybe the rules could have some
>> special marking that is configurable per hostapd (or per AP or BSS or something)
>> so that a (re)started hostapd could clean up any leftovers from a
>> previous instance?
>>
> hostapd does its own cleanup (cleanup of stations and interfaces)
> when it receives SIGTERM.
hostapd could crash without being able to clean up, though.
So I think you need a way to query the kernel's state and
clean it up in this case.
> An nft chain is created for each AP netdev/interface.
>
> The nft rule handle (stored in internal hostapd data structure) and
> nft chain metadata can be used to cleanup/flush the nft rules as part of the
> interface cleanup.
>
>> And, is there a mechanism to clean up flows that a buggy non-AP STA
>> has requested but then forgot to terminate (like phone starts a video call,
>> requests some QoS, then forgets to tell AP that it is done with the call
>> and packets no longer need to be classified?)
>>
>> Thanks,
>> Ben
>>
> The scs objects of the stations will be cleaned up during the station
> disconnect (by the AP which is maintaining them).
> As part of this deletion, the nft rules are also deleted, using the
> stored nft rule handle.
A station may be long lived, and it may be bad at cleaning up
its sessions, so the AP may end up with a large amount of classification rules
that are not actually needed, possibly slowing down performance
and/or limiting other stations from being able to add their own
flows.
Can you add time duration and/or detect idle flows and clean them
up automatically on the AP?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP
2025-06-24 22:31 ` Ben Greear
2025-07-01 19:38 ` Ramanathan Choodamani
@ 2025-07-02 9:57 ` Nicolas Cavallari
1 sibling, 0 replies; 7+ messages in thread
From: Nicolas Cavallari @ 2025-07-02 9:57 UTC (permalink / raw)
To: Ben Greear, Ramanathan Choodamani, linux-wireless; +Cc: netdev, ath12k
On 25/06/2025 00:31, Ben Greear wrote:
> On 6/24/25 13:57, Ramanathan Choodamani wrote:
>> ===================================
>> Robust AV streaming protocols - QoS
>> ===================================
>>
>> The Robust AV stream protocols are mobile centric protocols - meaning
>> they
>> are initiated by a non-AP STA to the AP. These protocols are implemented
>> at the Access Point (AP) to classify packets sent to the non-AP STA
>> which requests
>> classification using action frames. The non-AP STA initiates Robust AV
>> streaming
>> action frames requesting for specific classification for the IP packets
>> destined to the non-AP STA from the AP. These parameters can be
>> negotiated by both
>> AP and non-AP STA.
>>
>> Upon successful handshake, The AP classifies incoming individually
>> addressed MSDUs
>> (Mac Service Data Unit) based upon parameters provided by the non-AP
>> STA or
>> notifies the non-AP STA to transmit MSDUs with preferred parameters
>> based upon
>> what was exchanged.
>>
>> Robust AV streaming improves AV (Audio and Video) streaming
>> performance when
>> using IEEE Std 802.11 for consumer and enterprise applications.
>>
>> Let's look at the Robust AV streaming protocols which are implemented
>> as a
>> part of this design.
>
> Thank you for posting this and for the beautiful ascii diagrams!
>
> Since this will be poking netfilter rules into the kernel,
> is there a good way to clean up all rules created by a previous
> hostapd process in case hostapd crashes or is killed hard and
> cannot do its own cleanup? Maybe the rules could have some
> special marking that is configurable per hostapd (or per AP or BSS or
> something)
nftables has an optional "table owner" mechanism that destroys a table
if the netlink socket that created it is closed. Just like nl80211
connection owner for vifs.
keyword: NFT_TABLE_F_OWNER
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-07-02 9:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-24 20:57 [DESIGN RFC] wifi: Robust AV streaming Design Proposal for AP Ramanathan Choodamani
2025-06-24 22:31 ` Ben Greear
2025-07-01 19:38 ` Ramanathan Choodamani
2025-07-01 20:17 ` Ben Greear
2025-07-02 9:57 ` Nicolas Cavallari
2025-06-27 7:24 ` Johannes Berg
2025-07-01 19:30 ` Ramanathan Choodamani
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).