Forum

Most useful Devinator thanks very much.

In response to a couple of your points:

All data will get aggregated at some point unless it's peer to peer. The VoIP server and gateway is most likely to be located in the enterprise core which is also likely to host your WLAN controller (if you have one) and the more powerful wired switches.

This may be a little crude but let's take an RTP packet (214 bytes on the wire) and add a CAPWAP header (54 bytes). A packet typically contains say 20ms of voice so 50 pps = 107.2kbps. For 100 simultaneous calls in progress that's 10.72Mbps. Given that an enterprise controller is going to have at least 1Gbps connection I can't see it struggling that much with just over a 1% load, particularly if appropriate QoS is configured. Assuming my maths is correct on that one of course...

I take your point about the CAM table updates though it's the "most" which worries me.

For me, the WiFi is a service and services live in the core with all the authentication, filtering and switching power that lives there too.

Something just doesn't sit right with me about potentially the weakest link in my security fence having as many entry points as I have APs.

A controller is a bottleneck? Well - only if I sized it wrong.
A controller is a single point of failure? Yes, if I didn't buy a backup though even then the failover may not be particularly rapid!

I think we've identified the pros and cons of each approach and it's as much a philosophical argument as a technical one.

Thank you all for your advice and opinions.

Devin,
I stand corrected regarding the roam time increase with doubling the channel. I was using information I received from VoIP a phone manufacturer. Just out of curiousity, I've often wondered how guest networks are handled in CCA. I've always thought that was the hardest thing to remove from the controller.

Excellent post. Loads of good stuff. You can almost hear the flagman saying "Gentlemen start your engines" as Team Controller and Team Get That Controller Out of Here get revved up......

Dave

Well let me end this discussion. The original question was "is there any advantage to using a controller in a voice deployment?" And to answer that: it depends. Do your homework and choose the solution that is right for you. Always, a fun time especially when Devin joins the conversation. It certainly gives me a lot to think about. Have a good weekend all.

I stand corrected. So who could be the other manufacturer of a non-controller based solution (sorry Devin, just curious!!!)?

Sorry Craig, this is not an answer to your question.

Don't Spectralink phones also ignore the random backoff requirements of wireless links, and does this make a shambles of everyone elses latency?

Other manufacturers would be Bluesocket and very shortly Ubiquiti (but i'm not sure if they are proper distributed systems or just cloud based control).

BlueSocket still 'appears' to be controller based, just not a traditional box in the cabinet. Possibly cloub based as you mentioned.

"The Bluesocket vWLAN? distributed architecture enables over a 10x increase in the total traffic. Because the packet forwarding functionality is offloaded from the controller to the access point, the controller is free to now manage thousands of AP's and 10s of thousands of users."

So is this technically controller-less or not?

Is there a definative description of a WLAN controller or does each manfacturer devise their own?

CP

Hi guys,

Sorry for being gone so long. :) Here are my responses to posts since my post:

John Eustace:

As to "Aggregated at some point", that depends on the type of traffic really. What about a laptop sending a print job over Wi-Fi and Ethernet to a local printer? What about a VoIP call (which is peer-to-peer)? The VoIP server might be located in the core, but it's typically only used for call setup/teardown, not the actual VoIP traffic. The VoIP traffic itself flows directly from phone-to-phone. VoIP traffic is negligible in the big scheme of throughput, but it's not negligible when it comes to how it must be coordinated alongside data and video within a BSS (an AP radio's cell). Consider what small packets do to an AP's CPU...they tank its overall capacity just like small packets tank a router's overall capacity. For that reason, Aerohive uses dual-core CPUs in our AP300 series - to keep PPS high in addition to Mbps.

Filtering should never live in the core. Filtering should live on the edge. Do you want packets flowing all the way from access > distribution > core only to be dropped because they should've never been on the network to start with? What if your Internet firewall did that? :D Yeeks. ALL Wi-Fi vendors know this and are now pushing firewall filtering into their APs. ALL means "no exceptions that I'm aware of", though there might be a straggler...but they'll eventually get there.

Controller sizing... Rather than write you a small book here, I've addressed that topic here: http://blog.aerohive.com/blog/index.php/2010/11/30/controller-based-wlan-pitfalls-theyre-expensive-dont-scale/

Controller redundancy: Paying extra for something that should be inherent by design seems foolish, don't you think? It's especially painful when your backup controllers each have to be fully licensed just like the primary controller.

I disagree that this is a philosophical argument. This isn't SCA vs MCA, but rather "a hack that did the job for a while" vs. "the future of Wi-Fi architecture." You can bet all of your money on the fact that controllers as we know them today will go away entirely. They will be replaced by a set of inter-AP and/or inter-AccessSwitch protocols that operate the control plane. It will happen.

Wireless Jon:

I'm not sure I understand the question about guest networks and clear channel assessments (CCA). Can you elaborate/clarify?

Also, are you asking about removing guest management from the controller? If so, then that's easy. Just have APs powerful enough to operate an enterprise-class captive portal (like Aerohive). :)

dave1234:

"Team Get That Controller Out of Here" - that's hysterical! :D I may have to borrow that one.

Wireless Jon:

Thanks. I agree: it depends.

CraigP:

So far, as I predicted (starting in Sep 2009 and still predicting), vendors are moving to a distributed architecture. Motorola, Bluesocket, & Xirrus have made it clear that it's the future of Wi-Fi architecture, and there are others who are flirting with it already, such as Ruckus, Meraki, and Aruba. There are a variety of issues that controller vendors are facing in their transition to controller-less that you can read about here: http://www.wirelessweek.com/Articles/2011/01/Evolution-Controller-Less-WLAN/

Wlanman:

It depends. With SVP, that's the gist of it. With WMM-AC, they abide by standard Wi-Fi rules on backoff, based on WMM parameters set for their AC.

Paul Finlay:

Bluesocket has a software controller that runs on an IBM server. It's still a controller, but it's cheaper to build since no custom hardware is required. It helps keep Bluesocket in business. They are a tiny company (around 40 employees), and they have to cut every corner possible to keep the doors open.

Ubiquiti has SMB-class, software-managed autonomous 2.4GHz-only APs. They aren't an enterprise player.

CraigP:

There are two marketing terms these days to be aware of: Private Cloud and Public Cloud. Public Cloud is like Meraki's solution or Aerohive's HiveManager Online, where the management (Aerohive) or controller (Meraki) is a hosted service by the manufacturer. Private Cloud is on-premise management, where the software lives in your data center. Private Cloud is essentially a marketing term for what we've always had. The only difference is that Private Cloud typically means "web based service" instead of OS-based software. Aerohive has both, and believe it or not, we're the only vendor who does...odd.

Bluesocket has Private Cloud...ish. They have a controller that lives in a VM on an IBM server. "Cloud" for Bluesocket is just marketing terminology, but to throw them a bone, I do like the idea of software controllers better than custom appliances. I just don't like controllers in general. :)

Distributed data forwarding isn't controller-less by a LONG shot. If distributed forwarding is in use by any controller vendor, and control-plane connectivity (to the controller) is lost, there is functionality loss. If that weren't so, then there would be no need for the controller. That's what Aerohive has done: eliminated the controller by building the control plane into a suite of free protocols that automatically discover and operate across the APs. Controllers are on their way out. ;)

Hope this helps!

Devinator