[bufferbloat] Does Airtime FQ replace the need to shape per client

Yes, that's the idea. Shaping is really a workaround for bad queue management at the real bottleneck. The airtime FQ algorithm sits at the real bottleneck (in the WiFi driver on the AP), managing the queue directly.

@zekica summed up the different components of this system well, above:

This enforces fairness between flows going to the same station, and applies the "short flow optimisation" that is also in FQ-CoDel and CAKE to ensure that sparse traffic gets relative priority.

This is to keep the lower-level queues in the WiFi firmware from bloating. It's the same mechanism that Byte Queue Limits does for Ethernet, but measured in the airtime domain (by forecasting transmission time from the current rate), hence the 'A' instead of 'B' :slight_smile:

This is only needed for hardware that has significant queueing in the firmware; but that's everything except ath9k, so in practice this is pretty important.

This does (deficit) round-robin scheduling of all active stations to ensure they each use only their fair share of the available airtime. This is to ensure a low-rate station does not use up all the airtime (the so-called "performance anomaly"). Airtime usage is accounted after-the-fact (on TX completion) in the airtime domain, using the best available source of airtime information. I.e., if the hardware provides actual airtime usage information that is used, otherwise the usage is estimated from the rate information.

5 Likes