WWDC WiFi – It doesn’t have to be this way!

WiFi Fail, WWDC 2010

Image courtesy of ars technica

“The networks in here are always unpredictable, they are slow today…  you could help me out if you’re on Wifi if you could just stop.”

— Steve Jobs, WWDC 2010 Keynote

In a previous life, as an engineer at Apple, I demoed the new networking technology I’d built in front of a few thousand developers at Apple’s World Wide Developer Conference (WWDC). I was showing off our zero-configuration networking platform, called Bonjour, which involved throwing together a dozen devices on stage and having them instantly talk to each other. Back then, the rule was clear – never, ever rely on the wireless for a high-stakes live event!

Sadly it seems that little has changed. At last week’s WWDC, Steve Jobs’ new iPhone crapped out trying to load the New York Times over WiFi. I’m not sure which happened first – shutting of the WiFi for conference attendees in an attempt to get the demo back on track, or a head rolling somewhere at Apple HQ – but either way, the aftermath wasn’t pretty.

While this was perhaps the most visible conference WiFi fail, it is certainly not the first. Twitter’s Chirp, Facebook’s F8, Google/IO, and scores of other tech conferences, with large audiences of power-users crammed in one big hall, all had their issues. These environments are challenging, for sure, but the issues that bring down these networks are, by and large, preventable. (See, for example, the fine work by our friends at British Telecom at Le Web – 2,400 concurrent users in one hall pushing 300mb/s!) If you’re serving high-density, high-bandwidth environments, here are a couple of tips:

Bandwidth Limits
The pipe to the internet needs to be shared amongst a large group of people, so one of the most crucial aspects is setting an appropriate bandwidth limit per client. This keeps internet access consistent for all users, and prevents one hog from ruining the experience for all. A real-time management console (like ours!) makes it very easy to set a per-client bandwidth limit, and to monitor the number of clients on the network and the overall bandwidth usage, so you can adjust as needed. Of course, you’ll want to exempt VIPs (think Steve Jobs) from these limits. With our platform, this is easy – either whitelist their MAC address, or create a separate SSID (aka virtual network) that isn’t subject to a limit, with access control locked down to VIPs only.

Dual-Radio 802.11n with Band Steering
802.11n provides much faster speeds than its predecesor, 802.11g.  But not all 11n APs are created equal. Most 11n client, including laptops and iPads, can operate at either 2.4Ghz or 5Ghz (a clean, wide-open spectrum), whereas older clients and iPhones only operate at 2.4Ghz. Also crowding 2.4Ghz are bluetooth headsets, microwave ovens, and cordless phones. A dual-radio access point can operate at 2.4Ghz and 5Ghz simultaneously. To reduce interference, we’ll want to clear the 11n devices off of 2.4Ghz. An AP like our MR14 that features Band Steering will proactively steer 11n clients to the 5Ghz radio, reducing contention amongst the legacy devices on the 2.4Ghz radio. Finally, you’ll need an AP with an enterprise-grade chipset to support high user densities, like BT did at Le Web with 100+ users per AP.

Optimize Channel Selections
Think of the wireless spectrum as a multi-lane highway. You’d never cram 100 cars into one lane while leaving the others empty, yet this is exactly what happens if you have APs nearby one another on the same channel. It takes more than just putting APs on different channels  to fix this, though. Some channels actually overlap, while others may be occupied by other devices that are out of your control. With typical wireless systems, this can be addressed with site surveys and optimization by a wireless technician. Alternately, in our cloud-managed solution, each AP monitors the airwaves around it, uploading interference data to the cloud. Our servers then analyze this data, along with performance metrics and usage information, and compute the optimal channel configuration and push this down to the APs. This process repeats continually, so the network stays optimally configured even as RF conditions change.
Real-time visibility and support
Over the course of a major conference, conditions can and will change. Being able to monitor bandwidth consumption, identify overly high-density areas, and receive real-time alerts if anything goes awry is immensely helpful. We’d watch our dashboard over the web to monitor bandwidth usage, and ratchet down the per-client bandwidth limit if needed. We also like our dashboard’s display of APs by usage – if we see some being overtaxed, we’ll just plug in another to share the load. It’ll automatically connect to the cloud controller, download the correct configuration, and join the network. And if an unruly attendee unplugs an AP, we’ll get an automatic alert.

I hope some of these tips help you plan for big events. Have any tips and tricks that you’d like to share? Let us know!

-Posted by Kiren Sekar