The last presentation during the Tech Field Day Extra @ Cisco Live Europe event was a Cisco-Apple Partnership presentation, and we expected an hour of corporate marketese.

Can’t tell you how pleasantly surprised we were when Jerome Henry started his very technical presentation explaining the wireless goodies you get when using iOS with IOS.

Ethan Banks published a great summary of the presentation, what I found most interesting was how they decided to handle QoS:

• Applications must decide what QoS they need;
• They use iOS API to request the QoS class;
• iOS marks the traffic generated by the application with proper DSCP values;
• Network devices act on the DSCP values to provide the desired QoS.

I was so delighted to hear someone finally realized how to handle QoS properly: the responsibility lies with the applications on the host; the network should just provide what it was asked to do, not try to reverse-engineer application intent based on TCP/UDP port numbers or haruspicy.

If an app wants to get QoS on iOS 10, the developer must use the right calls. Finally someone got it ;)) #win #TFDX

— Ivan Pepelnjak (@ioshints) February 22, 2017

But It Doesn’t Work in Real Life…

The obvious counter-argument to this idea is “but then every application will request the best QoS class”. No problem. Have you ever heard the mantra of treating the network as a utility? Let’s do it:

• Every endpoint has a traffic contract with the network specifying how much traffic the endpoint can send or receive (per traffic class).
• It’s the endpoint responsibility not to get over the traffic contract.
• The ingress or egress edge device measures and polices the traffic. Excess traffic is dropped or remarked.
• Network core does simple per-class queuing and dropping.

Won’t work in real life? Tell that to the hundreds of SPs around the world that use this simple approach to run their networks.

Admittedly, the “only” difference between SP and enterprise world is that there’s a customer-provider contract in the SP world, and all the screaming won’t help you if you want to exceed your contractual traffic rates and your traffic gets dropped.

The only trick to use the same approach in enterprise networks (where there’s no customer-provider relationship) is to get someone very high up the food chain motivated to support the contract enforcements (= no exceptions). CFO comes to mind – explain to her how using a simple approach like the one above will reduce the network complexity and consequently CapEx and OpEx.

Back to Wireless

Based on the above reasoning I wondered why Cisco and Apple think they need to tightly control this functionality (called Fastlane QoS). Andrew von Nagy provided the answer in a response to Ethan’s blog post: wireless is shared media, and on a shared media you have to enforce QoS on ingress point, otherwise a noisy neighbor can easily devour all the resources.

The only way to get QoS on wireless working flawlessly is thus to control the endpoints – and that’s what Apple iOS is pretty good at.

More information

Want to know more about QoS? Ethan Banks agreed to do a 2-3 hour QoS Fundamentals webinar in autumn 2017. Stay tuned…