Introduction
This post is about the effect of rate limiting on Wi-Fi and is inspired by the presentation Troy Martin (@troymart) gave at WLPC 2018 Prague (Link) and his recent appearance in the Clear To Send (@cleartosend) podcast episode 157 (Link)
Especially his comparison between “configuring rate limiting” vs. “disabling high data rates” was very interesting to me, and I wanted to capture and compare the effect of both of them from a L1 and L2 perspective in my lab.
Problem
When a Wi-Fi client wants to transfer a file, it tries to max out the speed available up to the point where it hits a limit.
In Wi-Fi this limit or “bottleneck” is often one of the following:
- Airtime
- WAN Link
So what should you do if you’re only able to get a 10Mbit/s WAN link, but you have APs that support data rates up to 400Mbit/s? In this example, the bottleneck will almost certainly be the WAN link.
How can you make sure users on the guest Wi-Fi do not use up your entire WAN throughput, and drain your corporate devices?
Option 1 – Disable High Data Rates (BAD!)
From the problem mentioned above, one solution might sound logical at first: why don’t we just disable every data rate on the guest SSID except 6Mbit/s, so there will always be 4Mbit/s left for corporate devices?
There are two fundamental mistakes in this thought:
- Because of the nature of Wi-Fi, the raw connection rate is not equal to the throughput you will get. There are a lot of other frames getting transmitted that take up airtime (management & control frames) in addition to the whole arbitration process that needs to take place (Link). A rule of thumb is that you can get around 50% throughput out of your connection rate (there are a lot “ifs” that you need to consider, so please don’t take this for a fact, more as an approximate reference value). So if you are connected on your 6Mbit/s-Only SSID, you’ll get a throughput of roughly 3Mbit/s.
So then just enable data rates up to 12Mbit/s to get the mentioned 50% throughput of 6Mbit/s, right?
NO!: - By using these low data rates only, you use up all the airtime with a single SSID. The corporate SSID running on the same AP (same channel) would be affected as well. Think of a crossroad (“channel”) with two lanes (“SSIDs”), and you want to regulate the flow of the first lane (“Guest SSID”) in order to guarantee the second lane (“Corporate SSID”) to have a decent flow (“throughput”). To solve this issue, you would not make the following proposal:
“To limit the amount of cars (“data sent over Wi-Fi”) from the first lane (“Guest SSID”), they are only allowed to drive over this crossroad with 6 miles per hour (“send data over the air with 6Mbit/s”). Meanwhile, the second lane (“Corporate SSID”) is still allowed to drive over this crossroad with 400 miles per hour (“send data over the air with 400Mbit/s”).”
Does that limit the speed of the Guest SSID? Certainly! But in addition to limiting the speed of the Guest SSID, you have also saturated the channel for everybody else (“blocked the crossroad for the other lane, because of the slow speeds”).
Option 2 – Configuring Rate Limiting on SSIDs (BETTER!)
The following proposal would be much better:
“Both lanes (“SSIDs”) are allowed to drive over the crossroad (“channel”) with 400 miles per hour (“send data over the air with 400Mbit/s”). However, the first lane (“Guest SSID”) has a speed limit behind the crossroad (“rate limit on the AP”). The intelligent drivers (“TCP packets window size”) from the first lane (“Guest SSID”) can see that they can’t just drive over the crossroad in a high interval, and therefore adjust their interval and wait on their site of the crossroad to not block it. During these waiting periods, the crossroad is available for the second lane (“Corporate SSID”).
As you can see, by rate limiting on the AP instead of disabling high data rates, you do not hog the channel and do not use up all the airtime, which allows other SSIDs or APs to operate on the same channel.
If you want to get more information about airtime, I recommend you to watch Andrew Von Nagys (@revolutionwifi) “High-Density Wi-Fi Design”
Lab Time
The concepts mentioned above are easy to demonstrate when you do a spectrum analysis and frame capture during iperf tests.
I have configured the following two scenarios:
- Test 1: TCP upload on 802.11g AP with 5Mbit/s rate limiting configured
- Test 2: TCP upload on 802.11g AP with highest allowed data rate configured to 12Mbit/s
When you compare the output of the spectrum analyzer, you can see that the airtime is a lot less used with the rate limiting in place:
By looking at the frame captures, you can see that the airtime utilization is less than half when you use rate limiting:
When you put this into numbers, you can see with rate limiting, the client was able to upload 40.1MB while only occupying the channel for ~9.8s (QoS Data & ACKs):
Meanwhile, with only low data rates allowed, it took the client ~23.9s to upload 31.3MB:
When you compare 2 Data Frames from the tests you can see that they are both the same size, but do not take the same time to get transmitted over the air due to the difference in the data rate:
Limits Of Rate Limiting: UDP
But there is a limit when it comes to rate limits (pun intended) and preserving airtime:
Rate limiting works well if TCP is used as a layer 4 protocol. TCP is connection-oriented and tries to find the sweet spot of throughput with the window sizes. UDP however is not connection-oriented, which means that it does not care if the receiver gets the packets or not. The “weakest link” between sender and receiver will drop the packets if there is too much traffic as shown in the following example:
A client with a Wi-Fi connection rate of 54Mbit/s uploads a 25Mbit/s UDP stream, so it sends its frames out in the air using up all the airtime. The AP gets it, but can’t forward the frames due to the 5Mbit/s rate limiting. In the process, the AP drops 20Mbit/s (80%) and only the 5Mbit/s (20%) are forwarded.
If the same example is reversed (25Mbit/s UDP download), the AP will drop the frames too, but this time before it gets sent out and consumes all the airtime.
Considerations
Please keep in mind that this post is about the idea of rate limiting in regard to bottlenecks.
I have talked with some people that recently rolled out brand new APs with only data rates up to 24Mbit/s enabled. There was a good reason to do so: it was a warehouse installation where only scanners were connected to the Wi-Fi and they had issues with dynamic rate switching. So remember that this warehouse installation was about stability and not about having throughput bottlenecks.
Please also remember that rate limiting should only be used as a last way out, because it may lead to poor end user experience. Details about considerations and how to tweak it appropriately are discussed in the Clear To Send Episode 157 (Link)
Cheers, Renzo
