To Control or Not to Control?

Maybe that’s why I find the controller/controller-less conversation so amusing – Enterprise-grade, mission critical Wi-Fi needs control, right? From a historical perspective, controllers were originally introduced to simplify the management of Wi-Fi. As the number of APs deployed increased, the process of going to each AP individually to make configuration changes became an unworkable IT overhead. Controllers therefore provided centralized management, configuration, and visibility to the Wi-Fi. I don’t think any of us would argue that controllers are bad given those criteria.

The argument that I often hear with regards to controllers being a bad idea is that they can become a bottleneck for Wi-Fi traffic. I’ll agree that could be mathematically argued as a possibility, but tunneling traffic through a controller was not the primary reason for the development of the controller. Tunneling traffic through a controller does provide a number of significant benefits including, but not limited to, simplified AP deployment, client authentication management, and negating the need to tag multiple VLANs at the AP Ethernet port (not insignificant step in the deployment of APs).

However, the controller manufacturers figured out a number of years ago that there may be scenarios where tunneling data traffic through the controller may not be the most effective architecture. For example, if the APs and controller are separated by a WAN link, tunneling the traffic through the controller may be less efficient than dropping the data traffic onto the wire at the AP. For Meru this is known as bridged mode, but has also been called Remote AP mode, REAP, etc. So most scalable controller vendors today provide two data plane modes tunneled, and bridge, which can often be combined in a deployment. Therefore if a Wi-Fi vendor only provides bridge mode capability and requires a device to manage those APs (whether you call it a controller or not), a big portion of your potential deployment capabilities are not at your disposal – sounds like a one trick pony to me.

So, to recap, if I require a device to manage APs, I would argue that today, for all intents and purposes, it’s a controller. The majority of enterprise capable solutions offer two data plane modes – tunneled and bridge, which provide maximum deployment flexibility.

Much like Ethernet, each version of the 802.11 Wi-Fi standard increases supported data rates and the availability of 802.11ac has increased that by an order of magnitude. Therefore, given the argument that controllers are data plane bottlenecks appears to be highly compelling or even the perfect scenario for bridge-only data planes (let’s face facts – “controller-less” is bridge mode only in sheep’s clothing). However, having both tunneled and bridged data planes at my disposal provides the ultimate flexibility for 802.11ac. There may be applications or users that I would much prefer to tunnel than bridge. For example I may want to isolate guest users into a DMZ or provide special support and traffic steering for voice applications.

I will continue to argue that making strategic Wi-Fi decisions based primarily on data plane mode is ignoring the still fundamental issue of Wi-Fi; users expect the same experience at work or school than they get at home, regardless of the fact that they are highly mobile and are in environments that may contain thousands of APs supporting thousands of users with an ever increasing device density and throughput demand.

If you agree that a control-plane or controller function is required, the next question is where should that control function reside? Once again, I strongly believe that what the control-plane function provides is much more important than where the function resides. Therefore the model you choose (local, WAN, cloud, private cloud, virtual, AP) should have no bearing on the functionality of your Wi-Fi.