Orhan Ergun 8 Comments

Quality of service (QoS) is the overall performance of a telephony or computer network, particularly the performance seen by the users of the network.

Above is the Quality of Service definition from the Wikipedia. Performance metrics can be bandwidth, delay, jitter, pocket loss and so on.

Two Quality Of Service approaches have been defined by the standard organisations. Namely Intserv (Integrated Services) and Diffserv (Differentiated Services).

In this post I will not explain each method or special tools used in each method. Instead, which method makes sense in particular design and which Quality of Service Tools can solve user needs without compromising the network design goals.

Intserv was demanding each and every flow to request a bandwidth from the network and network would reserve the required bandwidth for the user during a conversation. Think this is an on demand circuit switching, each flows of each user would be remembered by the network. This clearly would create a resource problem (CPU, Memory , Bandwidth) on the network thus never widely adopted.

Although with RSVP-TE ( RSVP Traffic Engineering ) particular LSP can ask a bandwidth from the network nodes, and in turn nodes reserve a bandwidth, number of LSP between the Edge nodes of the network is order of magnitude less than individual flows of the users.

The second Quality of Service Approach is Diffserv (Differentiated Services) doesn’t require reservation but instead flows are aggregated and place into the classes. Then each and every node can be controlled by the network operator to treat differently for the aggregated flows.

Obviously it can be scalable compare to the Intserv Quality of Service model.

When you practice Quality of Service, you learn Classification, Marking, Queueing, Policing, Shaping tools.

And you are also told that in order to have best Quality Of Service for the user, you need to deploy it end to end.

But where are those ends ?

The name of the nodes might differ based on business. In Enterprise campus, your access switch is one end and the branch router, datacenter virtual or physical access switches, internet gateways might be the other end.

Or in the Service Provider business, Provider Edge router is one end, other provider edge router,datacenter virtual or physical access, internet gateways, service access devices such as DSLAM, CMTS devices might be other end.

So end to end principle will fail since the end to end domain might be too broad and too much devices to manage.

But definitely some tools make sense in some place in some networks.

For example ” Policing ” in the Service Provider Networks. It can be used for the billing purpose. Provider can drop the excess usage or charge for the premium service.

Policing is deployed together with classification/marking but you don’t need to deploy QoS tools on the other nodes so those classification and marking will be locally make sense. This tool is also used for the Call Admission Control purpose.

Imagine you have 200Mb links and each Telepresence flow requires 45mb traffic. You can place 4 calls onto the link. If 5th call is setup, all other 4 calls suffer as well since packets has to be dropped. ( 45 * 5 – 200 – buffer size)

Another Quality of Service tools is Queueing; and in particular it is used whenever there is an oversubscription. Oversubscription can be between the nodes ( On the links ) or within the nodes.

If the congestion is within the node, queueing in the ingress direction is applied to protect some traffic (maybe real time ) from the Head of Line Blocking in the switching fabric of the node. Or in the egress direction between the nodes to protect selective traffic.

The problem is if there is enough traffic, buffers ( queue ) will get full and eventually all the traffic will be dropped no matter what queueing method  ( LLQ, WFQ, CBWFW ) is used.

So if you try to design end to end Quality of Service by enable queueing to cover all possible oversubscription in the network you fail.

When the congestion happens, some flows will just die couple milliseconds after another. 

The design tradeoff here is to add more bandwidth vs engineering all possible congestion points. I am not talking only the initial QoS design phase but the complexity brought by the QoS in the design as well.Netwok Operator need to manage, understand,troubleshoot QoS during steady state and in the case of failure as well.

Bandwidth is getting cheaper and cheaper everyday but the complexity of Quality of Service will stay there forever.


  1. There is a common mistake, that if we have broadband network with a lot of free bandwidth, we doesn’t need QoS at all, and any application will work fine. It’s wrong. Micro-bursts will affect to real-time traffic even if your interfaces are utilised less than 50%. Bandwidth is growing faster than interface tx buffers and while your network speed is growing, micro-bursts will affect your network in more and more serious way.
    Of course it is impossible to make end-to-end QoS, but it doesn’t mean that you shouldn’t implement QoS at all.

    • Hi Mikhail,

      I wrote an article for the microburst and video traffic on packet pushers before. Problem with that is exactly the same. You will try to do it on every part of your edge network to protect the RT traffic but if there is enough rt traffic they will eventually be dropped as well. Again such tools may make sense in particular place but the trade off is bandwidth vs complexity.

      Also in a small scale networks it may be okay to design QoS but as I stated in the post, tradeoff will appear especially in the large scale deployment.

      For those who have enough service provider design experience might know that, throwing bandwidth especially in the core almost always a common practice.

      My ideas are common for all the services, fixed, mobile broadband, satellite, Wifi and so on.

  2. A large problem for designers/architects is that most people do not understand what QoS is, and how it works. They are usually shocked when I explain QoS, and the problems you outlined above…especially those that have Internet based WAN designs. “Wait what, I can’t do QoS across the Internet?!?” is a question the CIO asks, and then stares at his director/VP of IT or network services.

  3. Hmm…

    Sorry, I don’t buy more bandwidth to compensate for QoS. I plan and design for QoS despite bandwidth, that is, whether I have it or whether I don’t. The same concept applies to DCB where converged networks are concerned at least as far as my own philosophy is concerned.

    QoS should not be an option, it should be the rule.

    Darby Weaver


    • Thanks for the comment Darby,

      actually , definitely not 🙂 . Why do you think in most of the service provider core network do not have any QoS but always over provision, 50, 60 percentage rules in capacity planning.

      Yes some QoS tools make sense in specific place of some networks as I indicated in my articles, But you should it make it general rule.

  4. My 2 cents is that QOS is important to implement on critical WAN links and that the two most important classes are EF and scavenger. Its easier to spot the pigs on the link and then add them to a scavenger class than it is to work out the marking and percentages for the other classes.

    I have found that implementing QOS is very difficult in an enterprise because of the differences in the hardware and software features vary so much from device to device or between different line cards in a device or even on a particular line card depending on its configuration.


Leave a Reply

Your email address will not be published.