Cisco and Apple Agree: QoS Marking Is an Application Problem
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.
Want to know more about QoS? Ethan Banks agreed to do a 2-3 hour QoS Fundamentals webinar in autumn 2017. Stay tuned…
One has to close the loop, Apps expressing what they desire isn't enough. That said, Apps shouldn't be expressing "how" i.e. DSCP markings etc. They should only be expressing "what" they desire and let the network control decide "how". Our team did initial research on Application-Driven Automated QoS provisioning in SDN. Network Intent as it has since been called.
Hope it doesn't sound like a product plug, but here is an example of how trusted application server (MS Skype for Business) APIs/SDKs can connect with Network control elements (Aruba Controllers) to optimize Network performance and App's Quality of Experience (not just QoS). http://www.arubanetworks.com/solutions/microsoft-mobile-ucc/
Puneet Sharma, Ph.D.
IEEE Fellow, ACM Distinguished Scientist
Distinguished Technologist & Head, Networked Systems Group
Networking, IoT and Mobility Lab, Hewlett Packard Labs
Palo Alto, CA
While there are some similarities to Rspecs, Tspecs etc. from Intserv, ATM etc. there are significant differences also. The key distinction is notion of Intent. While applications need to express intent, it has to be decoupled from network (including control, whether centralized or not) that has the job of translating the intent into actual network configurations and such. Such decoupling is key to optimizing network resource utilization while maximizing the app utility.
IMO this sounds much simpler than it really is.
If however you're referring to the "simple approach" then IMHO everything else is orders of magnitude more complex.