QoS enforcement: What happened?

Three of four vendors in this test failed to protect voice traffic in the presence of data, even using QoS mechanisms specifically intended to do so. Why did these QoS mechanisms fail, even with the vendors' best experts configuring them? There are a number of factors that might explain our results.

Three of four vendors in this test failed to protect voice traffic in the presence of data, even using QoS mechanisms specifically intended to do so. Why did these QoS mechanisms fail, even with the vendors' best experts configuring them?

There are a number of factors that might explain our results.

Timing is everything. The importance of keeping delay and jitter low can't be overemphasized when it comes to voice traffic. Some QoS mechanisms work in terms of bandwidth and frame loss; if a given traffic class consumes more than a set amount of bandwidth, packets belonging to that class get dropped. That's not sufficient for voice. Even "strict priority" mechanisms, which always service a given traffic class first regardless of the consequences for other classes, only work properly if they receive high-priority packets in the first place. That's not so easy to do with 802.11 traffic. The IEEE protocols involve large amounts of management traffic and also require that every data frame be acknowledged. At the same time, the SpectraLink phones send out one frame about every 30 millisec and seem to falter anytime four or five packets in a row are dropped. These twin constraints make it critical that wireless LAN (WLAN) systems nail down the timely delivery of as much traffic as possible. In our tests, only the Aruba system did that.

It's not about the bandwidth. At most, we threw less than 3M bit/sec of traffic at each system - and that includes both voice and data. Given that four vendors cracked the 6M bit/sec mark in last year's tests, the initial suspicions of some vendors that we simply overloaded the systems with data doesn't hold up. This test emphasized timely servicing of high-priority traffic, not high data rates.

Access points aren't hot rods. The typical "thin access point" consists of a relatively modest CPU, a limited amount of RAM and firmware. By itself, those components aren't enough to ensure timely traffic delivery. Instead, vendors must rely on precise scheduling mechanisms in their switches (as Aruba does); reduce the number of concurrent calls (which improves performance, as we will discuss in covering tests with two access points); or deploy voice-only WLANs and don't allow data clients (not a practical alternative for most corporations).

Back to Clear Choice Test: Voice over wireless LANs

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2005 IDG Communications, Inc.