Compliance for Internal Wi-Fi SLAs

In the first iteration of our SLA feature we used throughput as the best indicator of client health, but also said that this is just the first. With SLA we built engine that enables the monitoring every client on the network and reporting it proactively to the administrator; now that the engine is in place adding other metrics is easy.

Also just as a clarification, we look at throughput vs bandwidth - a subtle change in meaning. When we look at throughput, we make sure to evaluate whether a client is a) below the throughput threshold established with the SLA and that b) wants to more throughput but can't get it. if both a) and b) are true then there is a problem. This is important because some clients may just want 1 Mbps, even though the SLA may set higher - SLA is smart enough to realize that no alarm should be triggered in this state.

Good point and this is something we have not highlighted. We check the average throughput every 5 seconds for every client on the network. Before we raise the alarm though, we like to see consistent congestion for 3 periods in a row. We evaluated shorter and long term time frames and we found that 5 seconds was the best time-frame to eliminate false positives but still be responsive to client issues.

That is the challenge of WiFi - Datarates can fluctuate instantaneously based upon localized and transient signal and noise measurements - while there are ways to mitigate this, there is no way to eliminate it. One of the attractive things about SLA is that it allows an administrator to test the network. Set the limit for 5, 10 or 20 Mbps to each client and see if those throughput levels can be met - if they can't, the system gives an understanding of why not.

SLA provides a management and enforcement layer over an in-deterministic medium that enables the establishment and monitoring of deterministic thresholds. If the network is not able to achieve the determinism required, it is able to respond automatically to achieve the threshold. In the unlikely event that it still cannot be met - the reporting gives the information required to enhance the network design to ensure that it does not happen in the future.

Good question, and you are right that that is very important. I will answer this is the context of WMM, which is only a portion of 802.11e widely adopted by both clients and APs. WMM, while useful is less a QoS system and more a hardware buffer which is a very different thing. WMM provides strict priority to clients and preemption based on the hardware queue. For this to be an intelligent system, there needs to be something behind WMM, that is what AeroHive's scheduler does. We feed the hardware queues packet by packet to ensure that WMM does what we want. Think of WMM as complimentary to SLA. Another important topic is that we try not to do anything non-standard or unintended with the 802.11 protocol. There is an incredible diversity of WiFi clients and with that comes a range in quality. Some clients aren't tolerant to any deviation to the expected AP behavior. To maximize compatibility we follow the standard as closely as possible and add things like SLA at a higher layer.

On the second point, we queue downstream but are also able to affect upstream because our queuing mechanisms look at aggregate airtime (both send and recieve) therefore we decrement airtime when clients use airtime either upstream or downstream. At the TCP level (or session layer or application layer for UDP protocols) the protocols react, which changes the upstream utilization. This works quite well. In addition the PER gives the AP precedence which means that the AP can usually send when it needs to.

SLA is actually the culmination of a bunch preceding of work on airtime, monitoring, QoS etc and depends on those technologies to deliver this level of determinism.