Blog
802.11 retries occur when there are client collisions or too much interference. Learn how to prevent high retry rates.
Let’s go back to some Wi-Fi basics and talk about 802.11 retries, which can cause problems for networks when their rate is high.
An 802.11 retry is a wireless frame that’s retransmitted because the receiver did not acknowledge it. In Wi-Fi, this only applies to unicast frames. We don’t acknowledge multicast or broadcast frames—just frames with a single destination.
An 802.11 retry is an important component of the enhanced distributed coordination function (EDCF) that governs channel access for Wi-Fi.
How do 802.11 retries work?
Say you have Client 1 trying to send a frame to the access point (AP). That frame is a PLC protocol data unit (PPDU), also known as a complete 802.11 frame.
Client 1 is trying to send this frame to an AP, but it doesn’t get an acknowledgment (ACK) back when it sends it. So, it sends the exact same frame again, gets no acknowledgment again, and does the third try. It finally gets that ACK frame back from the AP, knows the AP received it, and Client 1 can move on to sending its next frame.
Why do we need retries?
The reasons we need retries stem from the fact that the radiofrequency (RF) channel that the APs and clients operate on is a half-duplex medium. This means only one station on the channel can transmit at a time. Another essential aspect of half-duplex is that the transmitting station can't receive when it's sending.
It’s similar to how walkie-talkies work—only one person can depress the button and speak at a time. And when you say something into the radio, you won't know if your message was received on the other end unless someone replies with "copy" or another acknowledgment.
In Wi-Fi, ACKs represent that “copy” message, and you need them consistently. It’s the only way to know whether messages are getting transferred across the wireless medium. If the ACK isn’t received, devices will retry sending many times and eventually give up. The frame is dropped, and they move on to the next one.
Retries may occur when two clients try to transmit data to an access point (AP). Client 1 starts sending, and Client 2 begins at about the same time. That’s called a collision. The two transmitters interfere with each other, and the AP can't make sense of either transmission. One of the issues that lead to collisions is the hidden node problem, which happens when a node can talk to an AP but not with the other nodes talking to that AP.
Note, however, that collisions are just one cause of retries. We’ll cover more a little later below.
Two important steps happen during retries
Let’s walk through another layer of detail to understand more about retries at the protocol level. A couple of things happen when a retry occurs:
- The contention window doubles in size. The first window has 16 possible values and then doubles to 32, 64, and so on. It gets longer and longer because something is going wrong, and the frames aren’t being acknowledged. Wi-Fi is a very “polite” protocol; we try our best to share the channel with other users. So, we double that contention window each time to give whoever else is using the channel the chance to do it — and give us a longer time to detect that other user.
- The data rate (or Modulation and Coding Scheme (MCS) rate) the station uses starts dropping. Because a higher data rate corresponds with the signal-to-noise ratio (SNR), the client might begin to believe channel conditions have degraded, which is why frames aren’t getting acknowledged. So it shifts down to lower and lower data rates that don’t have the same SNR requirements.
All this activity takes up air time. It’s not just that we’re sending the same frame over and over again, which is inefficient. We're also sending it more slowly, which eats up air time.
Main causes of retries
Let’s quickly cover the three main causes of 802.11 retries:
- Poor SNR. We don’t have enough SNR to support the MCS rate we’re transmitting at. We might be too far away from the AP, it’s a noisy environment, or we made a bad selection for the MCS rate we’re trying to use.
- Collisions, as mentioned earlier. These are caused by hidden nodes or clients or APs transmitting simultaneously, causing garbled, corrupted frames.
- Interference. Other wireless protocols or other RF energy from other sources are on the channel while we're trying to transmit. This leads to a source of poor SNR.
We think about retries in terms of rates, and a single retry isn’t a big deal. But you want to know how often they’re occurring and keep the rate as low as possible. High retry rates indicate RF problems, and they must be limited to get the best performance from a Wi-Fi network.
There are also certain network design and application considerations here. For instance, VoIP is one of the most demanding applications, and retry rates should be kept below 10% for good performance. That’s because this application has the strictest packet loss, latency, and jitter requirements, and high-retry environments are bad for all three of those metrics.
Other applications can tolerate far more retries, however. For example, if you’re just sending emails, you can have retry rates through the roof, and the email will go through without noticing a big difference. But for many of the real-time applications we use today, low rates are crucial.
How to lower retries!
Try these best practices:
Use 5 GHz
The first step is using the 5 GHz band rather than 2.4 GHz. 5 GHz has fewer sources of interference and a lot more spectrum available, so it’s far less crowded, there is less contention, and it’s not as noisy. It’s also subject to far less interference from non-Wi-Fi protocols like Bluetooth.
Limit contention
Reduce contention as much as possible. We can do this by keeping the number of clients per AP as low as possible and reducing or eliminating co-channel interference, which is a significant source of retries stemming from collisions.
Search and destroy non-Wi-Fi interferers
Find those sources of non-Wi-Fi interference that are particularly disruptive and remove them. It’s not always possible, but it can be a better course of action than trying to channel plan around these interference sources.
Deploy and configure clients that roam well
A sticky client that doesn’t roam well will end up with poor SNR and be on the edge of an AP’s coverage area. This could lead to high retries. Deploy clients that roam well as much as possible. And if they have configuration options that affect their roaming performance, tune those for your network.
Design for roaming
Specific design methods, specifically AP placement, can make roaming more graceful for clients. An AP should be there when the client needs it while moving around the area, helping reduce the retry rate.
Visibility is key to identifying retries and reducing their rates
So, now you know what 802.11 retries look like, why they happen, and how to prevent them. But you’ll have an easier time spotting retries and other issues — and much greater success with a network plan — if you have a way to assess performance and see the results of any troubleshooting.
7SIGNAL provides wireless experience monitoring solutions that provide continuous testing and detailed visibility. Our Mobile Eye® and Sapphire Eye® platforms monitor performance from the end user's perspective in real-time, enabling quick and even proactive solutions.
Contact 7SIGNAL today to learn more.
7SIGNAL® is the leader in wireless experience monitoring, providing insight into wireless networks and control over Wi-Fi performance so businesses and organizations can thrive. Our cloud-based wireless network monitoring platform continually tests and measures Wi-Fi performance at the edges of the network, enabling fast solutions to digital experience issues and stronger connections for mission-critical users, devices, and applications. Learn more at www.7signal.com.