Review: Aerohive Dynamic Airtime Scheduling

By Lisa Phifer

July 06, 2009

Aerohive's QoS booster stops slow Wi-Fi clients from hogging more than their fair share of the air.

Aerohive HiveOS 3.2 Dynamic Airtime Scheduling 

Pros:  Fully automated, protocol independent, optimizes downlink without penalizing anyone
Cons: Little visible improvement on uplink, cannot be enabled through HiveUI

In Part 1 of our review, we used Aerohive's Web-based HiveUI and 300 Series HiveAPs to create a cooperative wireless "hive." Here in Part 2, we use Aerohive's HiveManager to optimize our HiveAP's performance by combining industry standard quality-of-service (QoS) controls with Dynamic Airtime Scheduling, a patent-pending feature introduced in HiveOS 3.2.

Despite its high-throughput moniker, many 802.11n WLANs fail to achieve maximum potential. Reasons vary, but one common culprit is the drag induced by slower Wi-Fi clients. When we conducted open air IxChariot tests, Aerohive's Dynamic Airtime Scheduling consistently squeezed more juice from faster Wi-Fi downlinks without penalizing slower clients—including distant 802.11n clients.

Unruly competition

All 802.11 clients—whether a, b, g, or n—use carrier sense multiple access with collision avoidance (CSMA/CA) to share a channel's "air time." Specifically, Wi-Fi clients implement MAC layer coordination functions (DCF, HCF) to give everyone the same number of transmit opportunities. Because channels are shared media, only one device should transmit at a time. To avoid collisions, any client with data to send must first listen to see if the channel is busy. If the channel is free, the client can transmit a frame (e.g., single or aggregate MPDU). If the channel is busy, the client must wait a random back-off period before trying again.

Ideally, if every client had the same amount of data to send, every client would get an equal slice of "air time." In a lightly-used WLAN, clients with more data to send get to utilize more of the channel's free time, while clients with less to send still get an equal shot at transmitting whenever they want.

However, transmission times depend on length and data rates. A frame sent at 1 Mbps takes twice as long to complete as the same frame sent at 2 Mbps. Even in legacy 802.11b WLANs, this disparity exists between clients operating at 11/5.5 Mbps and those operating at 2 Mbps, where clients slowed by distance and interference degrade aggregate WLAN throughput. To optimize 802.11a/g WLANs, many administrators configure APs with higher minimum data rates, trading smaller cell size (AP coverage) for better throughput and lower latency.

HiveAPs.jpg

But in 802.11n WLANs, max data rates are six times higher and differences between clients are far greater. Furthermore, 11n client performance can vary more, influenced by the presence/absence of obstacles that cause multi-path and exploitation of high-throughput options (e.g., number of antennas, frame aggregation). Unexpectedly slow clients can gobble up long chunks of air time, leaving fewer transmit opportunities for 802.11n clients that could otherwise jump in, send data quickly at 300 Mbps, and be done.

Restoring order

Many standard and proprietary mechanisms can influence the way that Wi-Fi clients share the air. With Dynamic Airtime Scheduling, Aerohive has combined conventional QoS control techniques with its own protocol-independent optimized scheduling algorithm.

For example, all 802.11a/g/n APs (including Aerohive's) support slow 802.11b data rates for compatibility, but can be set to disallow feeble 802.11b clients and costly 11b protection mechanisms. Many dual-radio 802.11n APs (like our Series 300 HiveAPs) can support 802.11g clients in the 2.4 GHz band while communicating with only new clients in the 5 GHz band (or at least on a different channel). These common approaches segregate legacy clients to reduce their drag on 802.11n, but they don't eliminate distant or under-performing 802.11n clients—including early Draft 1 and consumer-grade Draft 2 clients.

Today's enterprise 802.11n APs (including the HiveAP 320/340s we tested) support industry standard 802.11e Wi-Fi Multi-Media (WMM) prioritization. WMM defines four wireless access categories—voice, video, best effort, background –with different transmit queues, inter-frame spacing, random back-off periods, and 802.1d priorities. Frames associated with higher WMM priorities can be sent more frequently and/or for longer durations. For example, WMM lets voice handsets send short SIP/RTP frames at consistent intervals in converged WLANs otherwise dominated by bandwidth-hungry data clients.

However, WMM alone cannot distribute airtime equally across clients that send frames at the same priority, but different speeds. Several vendors have taken proprietary whacks at allocating airtime to reduce slow client drag. Meru was the first to add "airtime fairness" to its controller-directed virtual cell architecture, subsequently refined into virtual ports. Last summer, Aruba released an Adaptive Radio Management upgrade that could prioritize 802.11n clients over 802.11a/g clients. This February, Aerohive entered the fray by introducing Dynamic Airtime Scheduling to improve performance in congested WLANs.

Seeing is believing

As CWNP's Devin Akin observed in his blog post, What is fairness anyway? [PDF], vendors disagree about what constitutes fairness and have tackled related challenges in diverse ways. Our goal was not to compare Dynamic Airtime Scheduling to other-vendor optimization approaches. Rather, we wanted to put Dynamic Airtime Scheduling through its paces with our own mix of Wi-Fi clients to see how much it would really improve our own live hive.

When announcing Dynamic Airtime Scheduling, Aerohive published a paper demonstrating this feature's impact using VeriWave WiMix test results. VeriWave tools are widely used for performance and stress testing by equipment manufacturers. This is a common and effective way to subject APs to generated test traffic representing real-world applications and clients.

Aerohive's test results were compelling. For example, when Dynamic Airtime Scheduling was enabled for a HiveAP with three 802.11a clients (operating at 54, 12, and 6 Mbps), TCP downlink throughput increased four-fold for the fastest client, without delaying slowest client test completion. The more diverse the example client mix, the more striking the demonstrated improvements.

However, those tests were conducted in a closed environment, without live contention between clients. Closed tests avoid external RF interference, are easier to control, and are generally more reliable than open air tests. But open air tests can be uniquely insightful—especially for a feature like this. Aerohive showed us some informal open air test results, obtained with Ixia IxChariot test scripts. So we decided to begin our test drive there, using IxChariot to measure Dynamic Airtime Scheduling's impact on our own live 802.11n clients.

Go to page 2 of 3.

Pages: 1 2 3


Comment and Contribute
(Maximum characters: 1200). You have
characters left.