A clerk's TCP transfers on a city finance SSID remain inefficient after association. Captures show ADDBA Request/Response failing, so Block Ack never establishes. What is the performance implication?
Select an answer to reveal the explanation.
Short Explanation
ADDBA is the handshake that opens the Block Ack express lane for aggregates. When it fails, you're stuck mailing one postcard at a time—TCP feels that pain. Fix the BA agreement if you want aggregation back.
Full Explanation
ADDBA Request/Response establishes Block Ack agreements that enable efficient A-MPDU aggregation. When a clerk's TCP transfers on a city finance SSID remain inefficient after association and captures show ADDBA failing so Block Ack never establishes, the performance implication is that ADDBA negotiation failure forces non-aggregated or poorly aggregated exchanges, reducing efficiency and harming TCP goodput. The link may stay up while remaining stuck in less efficient acknowledgment patterns.
Saying failed ADDBA is required before OFDMA triggers and should be encouraged fails by concept: ADDBA failure is a performance defect, not a prerequisite to celebrate for OFDMA. Claiming that without ADDBA, GTK rekey cannot occur and all unicast stops fails by concept: group rekey and pairwise unicast can proceed without Block Ack; the symptom is efficiency loss, not total unicast death. Asserting ADDBA only applies to Bluetooth coexistence fails by concept: ADDBA is an 802.11 Block Ack setup exchange for Wi-Fi data efficiency.
Exam caveat: CWNE performance analysis ties TCP inefficiency after a clean join to missing Block Ack/aggregation setup, not only to RF coverage.
Operational check: Filter ADDBA Request/Response for the finance clerk, note status/failure codes, compare against a healthy client on the same BSS, and remediate client/AP BA policy or driver issues before raising PHY rates alone.