From: Peter Hessler Subject: Re: update ieee80211_classify() for more responsive SSH To: tech@openbsd.org Date: Sun, 14 Dec 2025 11:11:33 +0100 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!