On a busy permit-office SSID, airtime share looks roughly fair yet application latency spikes under load. Which DCF concepts best explain the diagnosis focus?
Select an answer to reveal the explanation.
Short Explanation
Fair slices of the pie still come with a waiting line—NAV says 'medium busy' and the contention window makes stations roll dice before talking. Under load at the permit office, those waits add latency even when nobody is hogging airtime forever.
Full Explanation
On a busy permit-office SSID where airtime share looks roughly fair yet application latency spikes under load, diagnosis should focus on DCF concepts: NAV deferral and contention-window backoff increase wait time under load even when long-term airtime shares appear fair. Fair average airtime does not mean low instantaneous queueing delay when stations defer and randomly back off. Expert performance analysis separates fairness metrics from latency under contention.
Claiming fair airtime means DCF is idle so latency spikes can only be DNS TTL misconfiguration ignores contention delay. Saying NAV is a wired spanning-tree timer and never affects wireless latency confuses 802.11 virtual carrier sense with STP. Asserting contention windows shrink to zero under load, eliminating all queuing delay, reverses how contention worsens with collisions and retries.
Exam caveat: airtime fairness ≠ low latency; NAV and CW explain load-induced delay on civic capacity SSIDs. Operational check: under permit-office peak load, measure client latency alongside airtime share, observe rising retries/deferrals, and reduce contention (cell size, channel plan, QoS) rather than chasing DNS TTL as the sole cause.