Wi-Fi Bufferbloat in a Gateway: Preserve Control Latency During Bulk Uploads

A gateway can upload at an acceptable average rate while control requests miss their deadline. The useful investigation is whether live traffic waits in a persistent queue, where that queue sits, and whether the proposed queue management can actually reach it. A throughput result alone does not answer those questions.

This guide targets a Linux gateway with Wi-Fi egress, using Linux 6.12 and the FQ-CoDel/CoDel descriptions in RFCs 8290 and 8289. It concerns active-link queue residence during concurrent traffic. Offline storage, failover, sleeping-station DTIM delays and application retry policy are separate investigations. Hardware, firmware, AP and upstream queues must be identified on the actual product.

Place every likely queue on the path

Draw application production, socket buffering, the Linux egress queueing discipline, driver/mac80211 queues, firmware or hardware queues, the AP and the next constrained link. A packet leaving one queue can immediately wait in another. If the bottleneck is downstream of the queue you can observe, a small local backlog does not prove the path is free of queueing.

For each observable boundary, record enqueue/dequeue or submission/completion timestamps with their meanings. A driver completion may report a different event from peer application receipt. Use a monotonic clock for local elapsed intervals and document synchronization uncertainty before subtracting timestamps from different machines.

Know what FQ-CoDel promises

FQ-CoDel combines flow queueing with CoDel active queue management. Its ordinary classifier hashes flows into queues, so separation is approximate and collisions are possible. Sparse traffic can benefit from the scheduler’s treatment of newly active queues. This is not a reservation for every control message or a hard real-time service guarantee. RFC 8290, sections 3–4

If bulk records and control messages share one transport flow, the default classifier does not know their application meanings. Merely enabling FQ-CoDel cannot turn those bytes into independent priority classes. Separate application buffering and protocol ordering may be the relevant design issue. Do not switch transports or mark all traffic high priority without an end-to-end requirement and compatible network policy.

CoDel measures packet sojourn time in the queue and distinguishes a persistent standing queue from acceptable bursts. Its target is a control parameter, not a per-packet deadline. Linux 6.12 initializes the ordinary CoDel parameters to a 5 ms target and a 100 ms interval; the FQ-CoDel implementation uses that initialization, with configurable overrides. Those defaults do not promise 5 ms Wi-Fi latency or 100 ms maximum delay. RFC 8289, sections 3–4; Linux 6.12 codel_params_init()

FQ-CoDel itself is not a configured-rate traffic shaper. If a faster upstream interface feeds an inaccessible slower queue, placing an AQM elsewhere may not keep that hidden queue short. A supported shaping design can sometimes move the bottleneck to a controllable point, but a variable Wi-Fi service rate complicates a fixed-rate choice. Treat placement and rate selection as target qualification, not a universal percentage-of-link-rate recipe. Linux 6.12 FQ-CoDel implementation

Run concurrent traffic with a complete denominator

1. Define the control outcome. Use a sequence-tagged request/response or the actual control transaction. State when the deadline starts, what completion means, and the observation cutoff. Record all attempted operations, including missing responses.
2. Establish the quiet active-link baseline. Keep the station awake through its supported configuration for this experiment. Record application latency, loss, CPU scheduling and available queue statistics without bulk upload.
3. Add a reproducible upload. Hold payload generation and receiver behavior steady. Run representative load first, then a declared saturation case. Preserve both useful upload rate and control results.
4. Align queue and loss evidence. Observe the relevant qdisc’s backlog, drops and ECN-related statistics where supported, plus driver/firmware evidence. A rising drop counter can be an intentional congestion response; interpret it alongside latency and delivered work.
5. Reduce offered bulk load without changing the radio. If control delay falls, the result supports a load-dependent queueing or scheduling contribution. It does not identify the exact queue until boundary evidence agrees.
6. Test an approved queue-management change. Only on an authorized fixture with recovery access, compare the supported configuration and restore the baseline. Record where the changed qdisc sits and whether traffic actually traverses it.

Keep uplink and downlink cases distinct. A device-side upload queue policy cannot directly manage an AP’s independent downlink queue. Likewise, a management connection used to change queue settings may depend on the very path under test; maintain an independent recovery route rather than experimenting blindly on the only remote session.

Interpret latency and loss together

Result	Interpretation to investigate
Control delay and local backlog rise together	Local queue residence is a plausible contributor; confirm time alignment
Control delay rises while local backlog stays small	Inspect downstream queues, radio scheduling and endpoint work
Latency improves but required uploads starve	The change fails the combined service requirement
Delivered-response percentile improves while losses rise	Check deadline misses over all attempts; survivorship can hide failure

A hypothetical test attempts ten control operations with a 50 ms deadline. Nine replies arrive with latencies of 1 through 8 ms and 90 ms; one is missing at the cutoff. The delivered-response nearest-rank p99 is 90 ms, and two of ten operations miss the deadline. The missing reply must not disappear from the service denominator. These numbers are synthetic arithmetic, not gateway measurements.

Report sample count, duration, percentile convention, maximum observed latency, loss and deadline misses together. A finite sample cannot establish an absolute worst-case bound. Include the upload’s useful throughput and CPU load so an apparent latency improvement caused by stopping useful work is visible.

Evidence and release decision

A Python 3.12.14 fixture executed the synthetic deadline calculation, including all-missing outcomes and an exact-deadline boundary. No qdisc was installed or changed, no radio traffic was generated, and no FQ-CoDel performance result is claimed.

Accept a configuration only when it meets the joint control and bulk-transfer requirements across the declared workload range, with the queue placement and remaining hidden boundaries documented. If the evidence cannot locate the delay, retain that uncertainty. Calling every loaded-link pause “bufferbloat” is less useful than identifying the first queue or scheduler that demonstrably holds the operation.