Blog
As you may already know, wireless performance is often affected by the wired infrastructure. Often when people complain, “The Wi-Fi's broke” many times it isn't a wireless issue at all. Therefore, looking at end-to-end performance offers a better view of end user Wi-Fi experiences. Another complicating factor is that end user experience is sometimes not a sum of individual components. As an example, we’ll look at DHCP timing that occurs in some wireless networks.
As an administrator, you might review your wireless DHCP response time, with a daily average and find the response time is a little greater than 2.5 seconds. Then you try running a manual test and it appears to be 1.5 seconds. You look at your server logs and these also indicate a response time below 1.5 seconds. Hey, what’s going on here?
In the simple exchange below, there is only one DHCP server and it's located on the same subnet as the client. The DHCP "Discover" gets broadcast out by the client and more than one server may respond with an "Offer". The server may delay sending a DHCP Offer for various reasons. So, a total time to get an IP address of 1.5 seconds is good.
With wireless, the infrastructure has more network components between the client and the DHCP server. In the roaming example below, there are access points and possibly Wireless LAN Controllers between the wireless client and the DHCP Server. Besides performing DHCP when turning on the device, the laptop will typically perform DHCP when the it roams from AP to AP.
Provided the access points are using the same SSID, a total time to get an IP address of 1.5 seconds can still be achieved.
The wireless SSID identifies the network and a typical company network will have three SSIDs. The first being a Guest network for visitors, the second is for voice over Wi-Fi communications devices, and the third is for general employee use on the corporate network. In these cases, users are not expected to roam between SSIDs. Instead the roaming typically occurs across access points using the same SSID.
Some administrators use the SSID to force a roam. Hotels may do this as a quick way to have a customer force a roam. If the user is on floor 2 and has an unstable connection to the SSID “FLOOR 1”, it’s easy for the front desk to say, “Click on the Floor 2 SSID”. However, a customer that wants to use Wi-Fi in the Hotel restaurant and room may have more than one SSID enabled and expect roaming to occur between these SSIDs.
Let’s take another look at our DHCP retrieval time. But this time, let’s look at the retrieval timing per AP. We can now see that there are two groups of values. One group is centered around our expected 1.5 seconds. And the second group is centered around a much larger 7 seconds.
The larger DHCP retrieval time comes from when the AP and Wireless LAN Controller do not forward the initial Discover to the server. This occurs when roaming across SSIDs. When the initial DHCP Discover does not get forwarded, the client will wait for a timeout and then retry sending the DHCP Discover. Depending on the client, this timeout can be 8 seconds.
The takeaway here is that end-to-end testing gives a better view of system performance. Unexpected interactions arise instead of viewing components individually. In the example above, testing the DHCP server alone will not give an accurate indication of DHCP retrieval time. You need to dig a little deeper and 7SIGNAL has the system that can help.