Making Sense of the Cisco-Apple 'Fast Lane'
Taking advantage of existing technology in a coordinated fashion, Cisco and Apple are addressing some long-standing challenges in managing Wi-Fi networks.
I will be the first to admit being not a little skeptical regarding the description of a "fast lane" for iOS enterprise users promised by Cisco and Apple in a partnership announced in late August 2015. For one, the description was essentially so vague as to be meaningless. And for another, I could see no sense in prioritizing traffic based on device manufacturer rather than an application's importance and technical requirements.
My skepticism carried forward to just a few days ago, when Cisco revealed a mechanism for optimizing Wi-Fi and prioritizing applications on Cisco infrastructure when using iOS devices. But a fruitful conversation with Jonathan Rosenberg, Cisco fellow and VP/CTO for Cisco's Collaboration business, and Jeff Reed, SVP of Cisco's Enterprise Infrastructure and Solutions Group, changed my mind. It turns out the two companies are addressing two major areas: Wi-Fi performance (particularly in roaming) and application prioritization.
Reliable Roaming Required
The first major change deals with the performance of iOS devices on Cisco WLANs. This is an important development as users expect consistent high performance on a WLAN throughout a facility or campus. The expectation includes consistent high performance for real-time traffic, particularly in regards to reliable roaming as users move throughout a facility.
Real-time traffic is inherently challenging in Wi-Fi, as the IEEE 802.11 standard describes a contention-based shared medium operation by which all of the devices associated with an access point (AP) take turns using a single half-duplex radio channel. The major step to address that problem came with the development of the IEEE 802.11e quality-of-service (QoS) mechanism for Wi-Fi networks; this is what the Wi-Fi Alliance refers to as Wi-Fi Multimedia (WMM). In essence, 802.11e/WMM gives real-time voice and video traffic preferred access to the shared medium, thereby reducing latency.
Maintaining that performance becomes even more challenging as users roam from one AP to another. Unlike on a cellular network, where the mobile device and infrastructure share the roaming decision, on a Wi-Fi network the client alone decides when it is time to roam. One long-recognized problem is "stickiness," referring to clients that put off making the roaming decision in favor of sticking with the original AP. Sticking with an AP can be a good decision for data apps, but a catastrophe for voice calls. When the device finally decides it's time to move, it then needs to decide to which AP to move and initialize encryption with that new AP.
As Reed described, the Apple-Cisco solution is not meant to create something new, but rather to tap into little used or ineffectively used capabilities that already exist in the Wi-Fi standards. That would include standards like 802.11r for fast roaming, 802.11k for radio resource management, and 802.11v for wireless network management. Together these allow for functions like neighbor reporting, through which the infrastructure provides information about the APs surrounding the one the device is currently on, and opportunistic key caching so the device has preconfigured encryption keys prior to making the roaming decision. This is to ensure a fast and reliable move to the new AP.
These difficulties have been known for some time, as I wrote in an April 2014 No Jitter post, "A Little More Voice (and UC) Over Wireless LANs." And, as Reed pointed out, the tools for solving such problems have been available. It's just that vendors had not put the solutions together in a coordinated and effective fashion. Exacerbating the situation, activating a feature at one end and not the other often resulted in worse rather than better performance.
While the Wi-Fi Alliance has been working to address many of these issues on an industry-wide scale, the Apple-Cisco partnership is the first coordinated vendor effort to address the difficulties. Their efforts should be more complementary than contradictory to the Wi-Fi Alliance initiative.
The even bigger challenge is prioritizing applications or creating that "fast lane." While we have QoS mechanisms at Layer 3 (i.e., Differentiated Services Code Point, or DSCP) and at Layer 2 (i.e., 802.1p and WMM), there is no defined mechanism whereby the application can tell the network what level of priority should be assigned to a particular data flow. That is precisely what Apple and Cisco have worked out, Rosenberg said.
In the Apple-Cisco scheme, IT administrators only need to activate the capability in the infrastructure and identify which applications have enterprise priority. The devices will automatically take those priorities into account in passing data packets to the communications interface, which in this case would be the Wi-Fi chip. An enterprise would need a mobile device management/enterprise mobility management (MDM/EMM) system to identify the prioritized applications.
There are still challenges, particularly when you get to Wi-Fi. The number of priority levels differs by prioritization mechanism, and you will need a standard mechanism for mapping between them. DSCP has a six-bit priority field (i.e., 64 possible states, though typically only nine or so are used), 802.1p has a three-bit field (i.e. eight levels), and WMM defines only four levels or Access Categories: AC_1 (voice), AC_2 (video), AC_3 (priority data), and AC_4 (background data). To make matters worse, the standard mapping between 802.1p and WMM links the 802.1p voice priority (i.e., Priority Code Point 5) to the WMM's AC_2, the access category for video!
While Reed didn't get that far down into the weeds, Apple and Cisco have apparently straightened out the 802.1p-to-WMM mess, and the device's priority selection will ensure that enterprise data will be assigned to WMM's AC_3 while lower-priority data will go to AC_4.
So, while I was initially put off by this fast-lane business, Apple and Cisco were actually on to something important, and may have given us a workable solution to some long-standing issues in Wi-Fi networking. Best of all, as Reed likes to emphasize, this is not being done by some proprietary mechanism, but primarily by coordinating the implementation of existing standards.
Proof in the Performance
As with anything in these technical fields, the proof will be in the pudding -- or, more specifically, in the performance.
With regard to the Wi-Fi issues, Apple and Cisco are certainly on to issues that have been a thorn in our sides for as long as we have been trying to send voice calls over Wi-Fi networks. Linking the application to the priority assignment is a major step, though I can envision some potential problems in mixed iOS-Android environments. In particular, while Apple may be able to deprioritize non-enterprise applications, data from all Android applications could be assigned to the enterprise priority (i.e., AC_3), which is the default priority for all traffic in non-WMM environments.
In the meantime, other standards for addressing these issues in a whole different fashion are in the works. The IMTC Real-Time Media Software Defined Networks (RTM SDN) Activity Group has defined UC-SDN with what it calls a "northbound interface." Using this interface, a UC&C controller like a Cisco Unified Communications Manager (CUCM) or a Microsoft Skype for Business server could communicate with a software-defined network controller and effectively order up a QoS-enabled path end to end through the network with sufficient bandwidth to support a real-time voice or video connection. However, by focusing on a smaller problem with a limited set of variables, Apple and Cisco may be able to come up with a workable solution to a nasty problem in a lot shorter time.
In addition to the fast-lane news, Cisco also announced it has used the Apple CallKit API for a new Spark iOS app that will allow users to make and receive Spark VoIP calls through the native iPhone interface. For my coverage of that news, see "Cisco Missing the Mark on iOS Calling?"