Few would deny that 802.11 is perhaps the most successful IEEE standard of all time, with the possible exception of 802.3. As wireless LANs move toward both ubiquity and a position as the default network connection for most users most of the time, the impact of 802.11 is perhaps even greater. But the spec has one clear flaw that must be addressed, and the sooner the better: the lack of standard client-side functionality.
Can you imagine someone sitting down to design a cellular network and deciding that no client component is required? Well, that's what happened back in 1995 when .11 was still in development. The thinking was that most .11 networks would be of the peer-to-peer/ad hoc variety, and not infrastructure-based using access points (APs). I am not, as Dave Barry would say, making this up. Of course, this assumption has turned out to be dead wrong, and the consequences are quite serious.
First, there is as yet no reasonable way to do load balancing. Roaming, in fact, is entirely nondeterministic in current .11 implementations, because there's no way for the infrastructure to tell the client what to do. This alone has serious performance and reliability implications. But it gets worse. With no client, there's no way to manage roaming devices and no way to verify that a client device is properly configured and free of malware. There's no way to keep a client from associating with a spoofed AP (the so-called "evil twin" problem).
Implementing upper-layer security is more difficult, because end-user organizations need to certify virtual-private-network and 802.1x components individually. Wouldn't it be great to turn a client device into an air monitor or sensor when it's not doing anything else? Well, we could do that too, thereby vastly lowering the costs associated with maintaining a second infrastructure of sensors for security and integrity. It would also be possible to do client remediation and deactivation if desired, protecting both network integrity and enterprise data assets.
But my biggest fear is that the need for a client is going to become obvious shortly, as we begin to load up our wireless LANs with ever-greater amounts of data and ever-greater duty cycles, and then add time-bounded traffic on top of all this.
Voice-over-Wi-Fi, or VoFi, is going to become a core driver of the WLAN industry, and I think it will become a fixture in many enterprises (and, of course, on metro-scale Wi-Fi networks) over the next few years. The lack of determinism that can be addressed via a client is going to severely impact the capacity and thus the performance of countless WLANs as a result. This situation will thus potentially lead to the rise of proprietary client implementations-and then interoperability becomes dicey.
We need to nip the private efforts in the bud and move to a standard client right away. OK, sure, we'll add some hooks for (authenticated and secured) extensibility, so that products can be differentiated and special needs met. But the core clientside functionality needs to be the same everywhere.
Should this be something that 802.11 takes on? Is the Wi-Fi Alliance or another ad hoc group the right home? I personally don't care-but I do think that this effort should have the highest priority and level of attention from both management and the engineers that will make it work. The time is now.
Craig Mathias (craig@farpointgroup.com), principal at Farpoint Group (Ashland, Mass.)