The Wi-Fi 6 elephant in the room

Everyone is talking about Wi-Fi 6 (802.11ax). From product launches, to technical briefings, to product technical launch briefings, it’s all the Wi-Fi space is abuzz with. Everyone loves talking about “the shiny new”, after all – it’s the technological advances that bring evolutionary and revolutionary changes to our technical lives but there is always that one person (Lee, I’m looking at you) that asks the question: at what cost? I’m not talking capital outlay, I’m not necessarily talking about operational outlay, I’m talking political cost. Our users have long memories and when we mess up (either as an industry, an implementation, or for whatever reason) the political damage that a flubbed product, widget, service, feature, or deployment gone awry can cause is pain that we don’t readily recover from. Everyone wants Wi-Fi 6, no one wants to get it wrong. Frankly speaking, one of the reasons this is so particularly painful is because the last technology ‘upgrade’ we went through (802.11ac wave 1 to wave 2) was painful for a lot of users. Even though this represented a ‘minor’ technical upgrade, in Cisco land, the pain was palpable for more users than not. In order to understand why this was the case then, and not the case now, we have to go back in time. Way back in time. Like, to 1995…

The venerable Windows 95!

If you have grey in your hair, you’ll remember Windows 95. It was awesome. It was great. it had a strong heritage robust peripheral support, and performed well. For its day, (OS/2 users aside) you could do no better. That is unless you were ultra-geeky and decided to spring for one of those SMP (Symmetric MultiProcessing) capable multi-CPU motherboards. In my instance, I was rocking a dual slot-1 motherboard. When the Pentium II CPUs came out, I was first on the list and once I had two of those bad boys installed in my gaming rig, I booted it up to test out some Quake… and was disappointed. You see, Windows 95 (and Windows 3.1 and DOS, etc) were single threaded Operating Systems. This meant that the OS that ran my gaming machine couldn’t see more than one CPU so no matter what I threw at it, I was never better than one CPUs worth of performance. It wasn’t until the brave of us switched to Windows NT 4.0 (don’t talk to me about NT 3.51) and later Windows 2000 – that we were able to ‘unlock’ that hardware’s potential because the Operating System itself, was now SMP capable and could not only see, but take advantage of both CPUs!

Windows NT4.0 with SMP support showing 2 CPUs!

Fast forward to the Cisco 3702 Access Point. This is an 802.11ac wave 1 AP and sports a host CPU of a Freescale P1020 running at 800MHz as confirmed by the clock speed shown on the AP boot messages:

PowerPC CPU at 800Mhz, revision number 0x2151

While not a terribly shocking revelation, there are plenty of data sheets around that detail that the P1020 is indeed a dual-core CPU (thank you, Moores law), but what most people don’t realize is that the venerable IOS operating on the AP3700 (and all other APs back to the AP350!) is a single threaded Operating System. This then means that Cisco was building some awesome dual core capable APs for quite some time now, but was still ultimately limited by an OS that could only execute a single thread at a time. They were ultimately bottlenecked, much like Windows 95 running on my dual Pentium II machine. Now, the Cisco development team aren’t idiots. They knew about this problem and have been working on it for many years – but it reached a critical point prior to the 802.11ac wave 2 APs being launched. This was the inflection point where it because no longer possible to ignore the wasted hardware resources in the AP platform due to a deficiency in the OS. Enter AP-COS. This is Cisco’s rebuilt from the ground up Operating System for all AP platforms moving forward – starting with the 802.11ac wave 2 platforms (the 1800, 2800, 3800, and 4800s). Speaking frankly, it took Cisco some time to get this right. If you were on the leading edge of the 802.11ac wave 2 platform adoption 4 years ago (yes, the 1852 was launched in June of 2015!) you felt the pain of a newly developed Operating System. Let’s park this particular side of the conversation for a moment though…

Cisco 2802 boot messages showing two CPUs

Now, Cisco is well known for their special sauce. Ever since the Cognio acquisition (that us old timers can’t talk enough about), they have ‘rolled their own’ radios. While not precisely true, they have licensed their Intellectual Property to Marvell, the chief supplier of the radios for Cisco for several years now. As my good friend Dave delves into in his blog post, the 802.11ax platforms from Cisco mark a departure from Cisco working with Marvell to build their own radios in their flagship APs. As of the 9120 802.11ax (thanks Pat for the correction here!) (Wi-Fi 6) Access Point, Cisco has moved their special sauce into a discreet add on card and are now using commodity radios from Broadcom and Qualcomm Atheros (QCA) for their client serving radios. The upshot of this is that Cisco is not the only manufacturer using these radios. You could see how, when Marvell was the only radio supplier, firmware, hardware, drivers, etc – all coming from a single proprietary supplier could be a bottleneck from a development perspective. What if there was a radio-reset bug? What if there was a new feature? What if there was a client issue? In short, Cisco would be the only one impacted. This created several unique scenarios where the radio may have needed some attention (for a variety of reasons) but there was only on vendor tackling the problem. Cisco’s move to commodity radios presented a notable step towards stability in the market and they lost none of their proprietary hardware functions, now that things like CleanAir were moved off to a discreet hardware component. In short, the best in stability without sacrificing the things that make Cisco, Cisco.

Cisco 802.11ax AP boot messages with 4 CPUs

Fast forwarding to Windows 10 – I mean, Wi-Fi 6 (802.11ax) platforms from Cisco. We now have a mature Operating System on our APs. We now have radio hardware (and all of the follow-on components such as firmware and drivers, etc) that represent the industry standard in compatibility and stability. These two things mean that the major reasons that we had all of the consternation from the 802.11ac wave 2 platforms have completely disappeared. Now, Cisco is an organization comprised of people, and people are fallible, but my personal experience with the Wi-Fi 6 (802.11ax) platforms from Cisco have been nothing short of rock-solid. We always have the benefit of hindsight, but in this instance, I believe that our past is well and truly behind us. Who knows what the fully ratified 802.11ax specification will bring us (okay, those on the IEEE board do!), but there are several tangible indicators that we’re very much over our growing pains of the past – the most important of which are hands on experience which have been smooth sailing, even under some pretty significant load. If you ask me, Wi-Fi 6 (802.11ax) from Cisco represents a huge leap forward on several fronts – performance, features, compatibility, and most importantly of all, stability.