The Retry Bit vs TCP Retransmission
A user copying a 4 GB file to a NAS over Wi-Fi sees 12 MB/s. The AP and client are 5 GHz, 80 MHz, 2x2, MCS 7, RSSI -67 dBm. A monitor capture at the AP shows the Retry bit set on 38% of data frames from the client. The capture also shows A-MPDU with Block Ack; the Block Ack bitmap has missing MPDUs in most aggregates, and the missing MPDUs are retried. A simultaneous capture on the AP's wired uplink shows TCP duplicate ACKs and fast retransmissions, but no wired CRC errors. The wireless capture shows no FCS errors because the adapter reports only decoded frames. Channel utilization is 55%, and the noise floor is -92 dBm.
1. Distinguish the 802.11 retry behavior from the TCP retransmissions. Which layer is losing data, and why does TCP still react?
Read the worked answer
The 802.11 retry bit refers to link-layer retransmission: an MPDU was not acknowledged and is being sent again. A 38% retry rate means the wireless link is losing or failing to acknowledge many MPDUs, and the Block Ack bitmap shows which ones are missing from aggregates. TCP retransmissions occur at the transport layer when TCP's own loss detection fires, such as duplicate ACKs or a retransmission timeout. The wired capture has no CRC errors, so the loss is not on the Ethernet side. TCP reacts because some wireless loss becomes visible to it: an MPDU may be discarded after the retry limit, or TCP may see reordering and delay from retried MPDUs. Not every 802.11 retry becomes a TCP retransmission; the link layer hides most of them. The combination of high Retry bits and TCP retransmissions therefore points to the wireless link as the underlying cause.
2. How can the Block Ack bitmap and sequence numbers localize the problem, and what does the absence of FCS errors in the capture mean?
Read the worked answer
The Block Ack starting sequence control and bitmap identify exactly which MPDUs in an aggregate were not received. Compare the bitmap with the retried MPDUs: if the same sequence numbers are missing repeatedly, the problem is persistent loss rather than random corruption. If retries eventually succeed, TCP may experience delay and jitter; if the retry limit is exceeded, TCP sees actual loss and retransmits. The absence of FCS errors does not prove a clean link, because the monitor adapter reports only frames that decoded sufficiently to be delivered; corrupted pre-MPDU frames may be counted as PHY errors or not reported at all. The Block Ack bitmap and retry behavior are the reliable evidence here. Sequence numbers also help distinguish retransmission from new traffic.
3. What would you investigate to reduce the retry rate, and what capture location would confirm the fix?
Read the worked answer
Investigate the wireless link quality and airtime, not TCP. Check SNR: -67 dBm signal with -92 dBm noise gives about 25 dB, which is usable but not excellent. Channel utilization is 55%, so contention and airtime may contribute. Examine retries by MCS and spatial stream; MCS 7 at 2x2 may be too aggressive if retries cluster at high MCS. Check A-MPDU length, Block Ack window, and whether the AP and client support the same aggregation parameters. Look for interference and for uplink/downlink asymmetry. Capture simultaneously at the client and AP to see whether losses occur in one direction, and use a spectrum analyzer to rule out non-Wi-Fi energy. After lowering MCS, changing channel, or reducing width, confirm the fix by a lower Retry rate, cleaner Block Ack bitmaps, and fewer TCP retransmissions on the wired capture.