Building network automation solutions

9 module online course

Start now!

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.

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…


  1. Ivan,

    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).


    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
  2. Puneet, I have seen a demo of HP and Skype SDN example, not bad. However,- Application-Driven Automated QoS provisioning in SDN and Network Intent - reminds me of a different flavor of a centralized control/signaling based protocol - resource reservation protocol or IntServ. That concept was that applications can provide near(yes ATM VP/VC setup between them) to guarantee the application's latency etc. I understand there is NO silver bullet here. Sometimes it seem that industry flops around on weather we do or don't want the network to be "application agnostic".
    1. Jeff,
      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.
    2. Understood and the post intent translation process would be great to have. However, the question is how do you fairly arbitrate the expression of intent across application classes(IoT et al)to prevent starvation, an unexpected priority over "intents", intent overrun or a misunderstood expression of intent of a wayward application? Think of the original Ethernet CSMA/CD FSM, the CS portion could be considered expressions of "intent" as well as the preamble. Or 802.11e which is just a manipulation of timing to allow that intent to proceed just a nick in time before the others. Do we signal from applications to the central point just for the central point to build/enforce the intent onto the network which could have scaling implications, or continue to let all the applications first come, best effort network access and let the utility plumbing and protocols of the network continue to do what it does well and somewhat fair today? I think the big challenge is always that first part of arbitration and fairness aspect and not the post portion( with automation these days to send the requisite config changes as well as plenty of bandwidth). If bandwidth continues to increase and get cheaper, at the same time improvements to protocols congestion handling TCP or web protocols http2 and html5 such built into the plumbing protocols advances combined with bandwidth(which is decoupled to begin with) may render the need for a central expression of intent based system to specific use cases only. I believe such as semi-central but decoupled system with a form of expressed intent was available in one form with Token-Ring's mac fsm coupled with an SNA or APPN solution on top in the past. Sometimes looking back into older protocols can provide glimpses of future protocols.
  3. > explain to her how using a simple approach like the one above will reduce the network complexity and consequently CapEx and OpEx.

    IMO this sounds much simpler than it really is.
    1. If you're referring to the "explain to the CFO" part, then yes, it was a gross underestimation of the effort.

      If however you're referring to the "simple approach" then IMHO everything else is orders of magnitude more complex.
  4. I give them credit for having taken what seems like a good approach, but I'm afraid that this will be just like many of the other advanced Cisco features that have been introduced in the last few years...prioritized over basic stability and functionality and then discarded when the next flavor of the month rolls into town. As far as Cisco wireless goes I'd settle for basic stability....20% of our access points reboot daily when AC is turned on with no resolution in 6 months of working with them.
Add comment