Wi-Fi networks are usually deployed to provide the best coverage and performance for clients. In some cases (such as public hotspot networks, fairgrounds and conferences) we need to limit the bandwidth consumption for specific devices on the network.
The goal is to provide enough bandwidth for each client without allowing someone to take advantage of free bandwidth for uses outside the scope.
Per-client bandwidth limits can be applied and enforced on the wireless network itself or on the wired portion of the network, on a router, firewall, L3 switch or any uplink devices between the wireless controller and Internet. In a controller-less environment, this can be done on the access point itself or anywhere between the access point and the internet.
With all these options available, one would wonder where it is best to enforce bandwidth limitations to achieve the best results. There are many variables involved but some tests can help clarify this to an extent.
Let’s start with a simple description of the two types of retransmissions involved before proceeding further.
Wi-Fi retransmission
It’s well known that any unicast frame on a Wi-Fi network must be acknowledged. This includes UDP and TCP frames, it doesn’t matter upper protocol used; we are on Layer 2 here. When a frame is not acknowledged it is retransmitted multiple times before being considered “lost.” Once the frame is lost, upper layer protocol may take care of it and decide to retransmit again (in case of TCP), or simply give up (UDP). If clients must transmit each frame multiple times to get them acknowledged, the load on the cell will increase while reducing the overall throughput of the single cell. This is bad.
TCP retransmission
TCP is a reliable, connection-oriented protocol. TCP retransmission occurs when a TCP sender does not receive an acknowledgment (ACK) from the receiver within a certain timeout period after transmitting a packet. Do not confuse this with Wi-Fi retransmission. TCP/IP retransmission works end-to-end while Wi-Fi retransmission works on the L2 scope of the single Wi-Fi cell.
TCP retransmission can occur due to various reasons, including network congestion, packet loss, router or link failures, or high latency. Excessive retransmissions can indicate network issues or congestion, which may degrade network performance.
Bandwidth rate limiting
Bandwidth rate limiting can be implemented using various techniques, including Quality of Service (QoS) policies, traffic shaping algorithms, and hardware-based rate limiting mechanisms in routers and switches. These techniques allow administrators to allocate bandwidth fairly, prioritize critical traffic and optimize network performance according to specific requirements and usage patterns.
When per-client bandwidth rate limiting is applied on wired networks, packets sent above the threshold speeds are dropped. But what happens when bandwidth limit is applied on the AP?
Let’s do some tests.
Testing environment
- HPE Aruba Networking AP 505 running HPE Aruba Networking OS 10.6 connected to HPE Aruba Networking Central.
- HPE Aruba Networking AP 505 in monitor mode for OTA packet capture.
- HPE Aruba Networking 2930F switch running AOS-S 16.10
- Apple MacBook Pro 13’ 2020 – wired client connected on SW
- Acer swift 3 laptop – wireless client connected to AP.
- A laptop with Wireshark to collect OTA pcaps from AP505 using HPE Aruba Networking ERM.
- iperf3 version 3.17.1 installed on both laptops to generate traffic.
A single 40MHz, 5GHz cell will be broadcast by AP-2. The test device will be the only device connected to the AP.
iperf3 will be used to generate traffic between the two test laptops.
Wireshark will capture all wired packets on the iperf server. It will also be used to capture all OTA traffic generated between the AP and the iperf client.
We will use the QBSS load element from OTA captures to identify real-time channel use.
From the Wireshark captures we will generate graphs to analyse the following parameters:
- TCP retransmission – (tcp.analysis.retransmission)
- WiFi retransmission – (wlan.fc.retry eq 1)
- Channel Utilization % - (wlan.qbss.cu)
Lets start with analyzing TCP retransmissions.
The first test is to check the baseline TCP retranmissions when running iperf. This will give us an idea of how the network behaves when there is a single device connected and no bandwidth throttling is enabled.
Next we will apply bandwidth throttling on the wireless network itself (on AP) and then on AP’s uplink switch port (on switch) and then compare the TCP retransmissions.
Let’s look at the graph results generated from the packet captures.
Now let’s compare the Wi-Fi retransmissions
Now let’s compare the channel utilization percentage
Baseline channel utilization percentage (channel 44)
You can see that the baseline channel utilization is between 40% - 50%. This is because channel 44 is used by other APs in the neighborhood.
Now, let’s compare the channel utilization percentage when bandwidth enforcement is applied on AP vs on switch.
Results
The graphs show that a lot of TCP retransmissions occur when bandwidth limits are applied on the switch. You can see from the graphs that the frequency and intensity of TCP retransmissions are much higher when bandwidth limits are applied on the switch.
This means that the limit applied on the AP works with a different mechanism which leads to lesser or almost no TCP retransmissions.
The channel use when different bandwidth limits are applied on the access point and on the switch show that the AP enforcement performs better:
Conclusion
The results shown here can be a good starting point to consider when designing a Wi-Fi network that needs bandwidth limits to be applied to client traffic.
It is recommended to repeat the test with the AP and clients used in the production network to verify results are the same with different devices.
In this specific case it appears the access point can be trusted when applying per client bandwidth limits resulting in lower channel use and no TCP packet drops.
Nidhi Johnny is a Technical Marketing Engineer at HPE Aruba Networking, working on cutting edge technology in the networking space.
