At Cisco Live US 2016, Cisco announced a partnership with Apple to improve the wireless experience for employees connecting their Apple devices to the corporate Cisco network. Now that we’re in February 2017, what fruit has that partnership borne?
In a briefing to a Tech Field Day delegation by Jerome Henry, a Technical Leader at Cisco, I found out. Jerome couched the major achievements as application prioritization and optimized wifi connectivity.
The Problem Of Priority
Cisco saw application prioritization as one of the main problems to solve for their Apple clients. Application prioritization means that when two or more applications are contending for the client’s wireless interface, there should be a scheme in place to decide which application gets to go first.
What Cisco has done is provide such a framework. The word “framework” is critical to understand, because Cisco has not built a queueing system that application developers can write to, or any other traditional QoS mechanism network engineers might think of. That seems to be Apple’s domain in this case. Rather, Cisco has created an app whitelisting function. To quote Cisco, “we can’t control the endpoint, but we can tell it what we want it to do.”
The whitelisting function allows an application to mark its packets with an appropriate QoS mark…and that’s it. The actual marking of that application is a developer concern. The whitelist just allows the marks to be written, and strips marks for non-whitelisted apps.
The marks help guide packets into queues. In iOS 9, Apple offered a 4 queue system. In iOS 10, Apple’s upped that to a 9 queue system. How the queues are de-queued (what algorithms are used, etc.) was not clear, but real-time applications were stressed as the big beneficiary. Voice packets are typically marked with DSCP value EF (decimal 46). EF packets coming from a whitelisted application will be handled by iOS in a prioritized way that sends the voice packets at the expected 20ms interval, resulting in a smooth conversation…hopefully.
The smoothness of the conversation assumes a few things.
1. The AP is not oversubscribed with client traffic.
2. The RF environment is relatively clean.
3. There’s a clear or at least properly prioritized path once the voice packet hits the AP and continues on.
Thus, real-world mileage might vary with this whitelisting scheme. At the least, it will ensure that mission critical traffic from properly marked apps will leave the client appropriately. In testing, Cisco saw low jitter for voice traffic when using this scheme, but much higher jitter when not.
The scheme is called Fastlane QoS. If you’re a Cisco shop and want to implement Fastlane, there’s a few things to know.
1. Fastlane needs iOS 10 or higher.
2. Fastlane is not enabled on Cisco wireless controllers by default.
3. Fastlane needs wireless controller & LWAP software version 8.3 or higher.
8.3 was released in July 2016, so it’s not so shiny as to be alarming. Jerome Henry mentioned that there’s been a few Fastlane QoS tweaks since the 8.3 release, so it might be worth upgrading to the latest stable version. Read about Fastlane QoS implementation here.
The Problem Of Roaming
The other major issue Cisco has addressed for Apple wireless clients is fast roaming. Fast roaming enhances the ability of a wireless client to disassociate from one AP and then reassociate to another AP quickly — so quickly as to avoid any noticeable interruption to the user. Without fast roaming enhancements, Cisco estimated a roaming action to take roughly 0.5 – 0.7 seconds, assuming 802.1x authentication against a RADIUS server and fresh key exchange.
The target was to make that roaming transition time as low as possible, low enough to handle real-time applications without the user noticing any service interruption. In practice, they’ve gotten the transition down to a sub-50ms roam. How did they do this? A combination of 802.11k, r, and v.
My nascent understanding of the 802.11k specification is that it is about finding out what’s in your neighborhood. When a 802.11k-capable wireless client associates with an AP, it will ask the AP for a list of other APs that are in the area. That way, the client has a pre-populated list of APs it can scan for when current AP signal strength is declining, rather than listening on all channels for whatever happens along the spectrum.
Cisco wireless networks populate the 802.11k list via the controller. The wireless controller gathers from the APs it manages lists of other APs that the AP in question has heard, and builds RF groups. Those RF groups are used to populate 802.11k answers sent back to wireless clients.
The 802.11v specification is similar to 802.11k, but works in a more directed way. When signal strength gets low, the client asks the AP for an immediate recommendation of a better AP it might move to. The wireless controller makes a recommendation to the client based on an algorithm of what it thinks will work best.
Cisco explained that 802.11v isn’t always a wonderful of an experience for the end user, as the standard isn’t implemented consistently across vendors. Thus, the handoff isn’t always smooth, and real-time applications can be interrupted long enough for a user to notice. Despite that, 802.11v is still in play at times.
That brings us to 802.11r. 802.11r is not about AP discovery, bur rather about optimizing the handoff time between APs, once the transition action has been initiated. I think of this as an issue of trust. For a client to be allowed to associate to an AP, the proper authentication must happen. The first time a client associates, this might take a while — key exchange and 802.1x auth, for example.
Once a client has associated to an AP, 802.11r allows that now-trusted client to roam to other APs in the same system without having to perform another full authentication. This is done using a key hierarchy, where a subset of the keys are already known to all APs in the system, allowing an authenticated client to associate to a new AP quickly.
In the briefing, we didn’t get into the specific of the key exchange, key hierarchy, sub-keys, or distribution methods, but you get the idea at at high level as to how the speedy reassociation is performed. I noticed in the demo that FT-PSK will show up as the authentication type for clients that are capable of fast transition.
Cisco also pointed out that their flavor of 802.11r is “adaptive 802.11r.” Adaptive 802.11r is important to prevent that non-802.11r capable clients from panicking when seeing 802.11r information during a 4-way handshake. Adaptive 802.11r means that only clients capable of 802.11r will see that information, preventing the panic situation. It’s unclear to me how this bit of magic was happening, but seemed useful information to relay.
The View From The Hot Aisle
Cisco’s efforts here are laudable. Rather than trying to beat Apple at the hardware game or write a software stack requiring installation and maintenance, Cisco has truly partnered with Apple to make the ubiquitous iPhones and iPads of the world work better in an enterprise context. I applaud this effort. Fastlane QoS and fast roaming are going after the problem of real-time application performance over wifi in a practical way that works within some arduous constraints.
Cisco also mentioned that there is more work in the pipeline with Apple, currently hush-hush. The partnership continues, and thus the features released back in July 2016 are just the beginning. This is also encouraging news.
If you’re a Cisco wireless shop supporting Apple iOS clients, these features appear to be worth your time. From what I could see in the demo, Fastlane QoS and fast roaming are configurable per WLAN, so a controlled rollout appears possible.
With a bit of luck, I’ll find some savvy wireless folks to share more details about 802.11k, v, and r with the community via a podcast. I know I don’t have all the details clear in my own head yet, despite having a sense. Stay tuned.