On 2025 Dec 04 (Thu) at 12:47:38 +0100 (+0100), Stefan Sperling wrote:
:On Wed, Dec 03, 2025 at 01:02:32PM -0700, Theo de Raadt wrote:
:> I have a worry that as soon as our kernel does conversion from one
:> priority classification, to a different level's priority conversion,
:> we should possibly be responsible for doing some traffic management
:> automatically.
:> 
:> My gut feeling is we should be the same rate limiting back-pressure
:> that downstream devices do.
:> 
:> If we don't have that... hey, can I get a trivial knob to make my chrome
:> set the DSCP_EF flag?  Or can we make that the default?
:> 
:> See, I'm saying there is a slippery slope to EF becoming the default,
:> and I feel like that should be stopped by saying high priority obviously
:> means a limited % of traffic on the port.
:
:Agreed. Thanks for pointing this out.
:
:In the default timings prescribed by the 802.11 standard a device which
:wins a high-prio VO Tx opportunity can use up to 2ms to send N frames.
:This includes meta frames such as RTS, CTS, and block-ack.
:Details: https://inet.omnetpp.org/docs/showcases/wireless/txop/doc/index.html
:
:Access points usually send a beacon every 100ms, and everything else must
:happen in-between beacons. Which means, with 2ms per Tx op, a channel will
:start becoming completely blocked if an application can grab about 50 VO Tx
:opportunities per beacon.
:
:To balance this with typing latency, we need to consider that users are
:typing comfortably at a latency between 20-200ms.
:https://www.researchgate.net/publication/375773571_Effects_of_Text_Input_Latency_on_Performance_and_Task_Load
:
:Based on this, let's aim for roughly 50ms typing latency. Which means we
:want to allow up to 2 VO Tx OPs per 100ms.
:The intention is that each VO Tx OP we allow corresponds to a keypress in
:an application using EF. Beyond this limit we fall back on best-effort.
:This leaves time on the channel for other types of traffic, preventing abuse.
:
:Another problem in the previous diff was that our mapping from EDCA access
:categories to QoS TID was outdated. EDCA has 4 queues, and QoS defines 8.
:The 802.11 standard provides a mapping table ("Table 10-1 UP-to-AC mappings")
:which I have applied in the patch below. This needs a fix for Tx aggregation
:where TIDs 4-7 had been left disabled. The only other direct consumer of this
:is the bwfm(4) driver which already expects to see priority values 0-7.
:
:This patch is working well for me.
:
:SSH key-presses get assigned to TID 6 (VO 3 -> UP 6).
:
:Bulk transfers (tcpbench) remain on TID 1 (BK 1 -> UP 1). TID 1 has a lower
:prio than TID 0 in the UP-to-AC mapping, so using TID 1 for tcpbench is better.
:
:There are ways for access points to customize TID mappings, but I don't have
:any which actually do this. Defaults should be good enough for now.
:

This reads good to me, and I agree with your analysis.

Been running for a few days on iwx0 AX211, behaves fine.

OK


-- 
I went to the race track once and bet on a horse that was so good that
it took seven others to beat him!