WiFi networks are usually deployed to provide best coverage and performances for clients. In some cases performances of a single client must be reduced to allow a better average experience for all clients.
This example can be applied to public hotspot networks, fairground, conferences etc.
The goal is to provide enough bandwidth for each client without allowing someone to take advantage of the free bandwidth for uses outside the scope.
Per-client bandwidth limit 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.
Sometimes documentation about how the limits are enforced are not clear and there are some doubts where the enforcement should be applied for better results. There are many variables involved but some tests may help to clarify.
Let’s start with some over-simplified description of the two types of retransmission involved before proceeding further.
WiFi retransmission
It’s well known that any unicast frame on a WiFi 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 connection oriented L3 protocol. That means if a packet is not acknowledged it will be retransmitted. Do not confuse this with WiFi retransmission. TCP/IP retransmission works end-to-end while WiFi retransmission works on the L2 scope of the single WiFi cell.
Bandwidth limit enforcement
Generally speaking when per-client bandwidth limit (policing) is applied on a wired network packets sent above the threshold speed are dropped.
But what happens when bandwidth limit is applied on the AP?
Let’s do some tests.
Testing environment
Testing environment includes:
- Aruba AP 225 running latest available firmware
- Wireshark 2.4.3
- Test client - laptop with Intel AC7265 Wifi card and updated drivers
- Router for wired traffic policing
- iPerf3 for traffic generation
- Metageek Chanalyzer 5.9.1.10
To simplify the tests a single 20MHz 2,4GHz cell, standard 802.11n is deployed. The test client is the only one connected to the AP.
Wireshark runs on the wired iPerf server. Wired and wireless traffic are collected by Wireshark. Two graphs are created, one showing WiFi retransmissions in red (Wireshark filter wlan.fc.retry eq 1) and one showing TCP retransmissions in green (filter tcp.analysis.retransmission).
The traffic generate for testing with iPerf is TCP to allow the measurement of retransmissions.
Metageek Chanalyzer with Wi-Spy and Ekahau NIC-300 USB are used to measure the channel use.
Running the tests
The first test is run to get a baseline to understand how the network behaves with a single client connected.
Results are embedded in the screenshots.
The following test show channel use, TCP and WiFi retransmission when per-client bandwidth limit is applied on the Access Point:
The following test show channel use, TCP and WiFi retransmission when per-client bandwidth limit is applied on the router placed between the Access Point and the iPerf server:
Results
The graphs show that TCP retransmission only happens when bandwidth limits are applied on the router. This means the limit applied on the AP works with different mechanism and does not drop TCP packets.
The channel use when different bandwidth limits are applied on Access Point and on the router show that the AP enforcement performs better:
Wrap up
The results shown here can be a good starting point to consider when designing a WiFi network that needs bandwidth limits to be applied to client traffic. It is recommended to repeat the test with the AP and clients actually used in production network to verify results are the same with different devices.
In this specific case it appears the AccessPoint can be trusted when applying per client bandwidth limits resulting in lower channel use and no TCP packet drops.