Being in SP field I sometimes hear folks say "we do not need QoS, just let's make sure we have enough bandwidth". This has always been bothering me, because currently we have a network without any QoS in the core and there are no problems with services (Internet, IPTV, VPN).

The core links (bundled 10Gs) are utilized in 50%-70% at peak time.

Correct me if I'm wrong, but I think that we are just lucky enough to carry traffic that is not that bursty to fill up the links.

My understanding is that because of bursty nature of IP traffic QoS should be implemented on core links regardless of their utilization, or in the worst case, when the utilization reaches 50%.


Thanks for your comments. Actually my primary concern are microbursts. I understand the result of a microburst as a packet drop which occur when there is no noticeable congestion on an interface. I also understand that microbursts happen in every packet network.

I was curious if there is any "magic" link utilization percentage below which microbursts are harmless? (and we should be safe without QoS). I think I saw 50% as a best practice in some QoS book, but I don't remember the details.

  • This could quickly escalate into a religious debate. In theory, since the purpose of QoS is to manage a limited resource (bandwidth), if you have more bandwidth than you need, you don't need QoS. OTOH, we can talk about micro-bursts, etc. Maybe this is a better topic for chat.
    – Ron Trunk
    Apr 10, 2015 at 11:58
  • 2
    Is QoS really so hard (expensive?) to implement that it's not worth doing if the hardware supports it, regardless of the available bandwidth? Why should there even be the question of QoS versus bandwidth when they are not mutually exclusive. Have both! Apr 10, 2015 at 13:43
  • 1
    It may not matter how much bandwidth you have if 100 users are all watching March Madness across the network. QoS is a good thing, no matter how much bandwidth you have.
    – Ron Maupin
    Apr 10, 2015 at 15:00
  • 1
    Look at it from another angle. QoS guarantuees that certain network resources will be available. This alone is a sufficient reason for QoS.
    – bjanssen
    Apr 11, 2015 at 14:43
  • @bjanssen QoS does not guarantee link availability; however it does make it much more likely that you get the most important packets through. Some people assume that you can seriously oversubscribe links after they deploy QoS; however all it really does is manage reasonable congestion levels. A full buffer drops packets, no matter what kind of QoS manages it Jun 20, 2015 at 21:06

3 Answers 3


There are at least two questions in your one question :)

"Throwing more bandwidth" at the problem doesn't solve anything, it just hides the problem. In IP network you should always prepare baseline QoS architecture to guarantee delivery of critical traffic and manage other traffic parameters (like jitter or delay) for different classes of traffic. You can take a look into NANOG presentation archives for extensive amount of material generated in that kind of discussions, with usual outcome being "yeah, maybe we should do QoS".

Traditionally, QoS is perceived as the "hard thing to do right" as the PHB model for IP network is indeed quite complex to plan and implement right. Historically, it was usually also connected with specific hardware requirements, architectures and configuration complexity which didn't help. But when you look at traditional SPs and their networks - they generally implement at least 3-4 classes of traffic and QoS policies to manage traffic flow within their networks. Throught last couple of years traditional certification testing tends to move from testing 4 classes and queues to 8-16 for transport network.

OTOH, not having any QoS in the network usually also means those saying "QoS is not needed, I don't have it and everything works OK" have no actual means of monitoring how the network behaves and what is the actual environment applications have for their own use. TCP has great adaptability to network conditions and sometimes problems are not visible with "naked" eye, but become painfully obvious when we dig into details and bit flows.

As for the second part of your question - there is nothing that can help you to fight with microburst apart from having deep enough buffers to accomodate them. Which leads almost immediately to things like buffer bloat and additional delays on the path if you tend to simplify and throw packet buffers with memory fast enough to actually deal with microburst (which is not simple and cheap). QoS unfortunately (at least - the mechanisms available in the usual toolset of networking gear) doesn't help 'control' microburst. Good news however is that You'll find microburst dangerous or damaging usually only in HPC and generally DC environments, not in typical transport networks.

  • Łukasz, thanks for taking time to reply. Unfortunately I have a hard time to understand the second part of your reply :) How come QoS doesn't help 'control' microbursts? Won't it help if I tune buffers, properly mark my sensitive traffic and put it into separate (priority) queue? If microbursts are not a problem in transport networks and we cannot control them, my original question is still valid - why having "fat" pipes is not enough? Or to put this the other way around - what are the problems in modern transport networks that QoS is supposed to solve (assuming having underutilized pipes)?
    – mkurek
    Apr 15, 2015 at 7:57
  • Microburst can't be controlled (in absolute terms) because this is something you receive, not send away. If you have a 100Mbit/s interface, and you get exactly 100Mbit/s over this interface, in ideal world you'll be able to send that exactly 100Mbit/s away. It's not always the case unfortunately. The way most switches are built, microburst are either handled by dropping part of the bursty traffic, or doing everything that's possible to buffer them. Both options have pros and cons, and there are holy wars fought over both approaches. Apr 18, 2015 at 10:51
  • ...and QoS solves capacity guarantee for your critical/priority traffic - no matter (to some extend of course) what changes in topology happen and what's the momentary availability of other links. So you can have your network loaded to 30%, but if some link or links fail, suddenly, you'll have some other links overloaded with traffic. QoS will make sure priority traffic will get through and other traffic (other classes of it) will also still have a chance to go through. Apr 18, 2015 at 10:52

QoS takes action when there is a congestion. So, yes, your team mates might be right when saying that a link used at 50 to 70 percent doesn't need QoS.

First, let's think to a theoretical link of 1 bit per second with a clock rate of 1 second (meaning that there would be 1 wire that transmit either 1 or 0 for 1 second, because destination wouldn't be able to catch the value if the signal is shorter): until the traffic that we need to send is of 1 bit per second, we just put that bit into the wire. No QoS is needed.

But if we receive 2 bits per second from a faster link (a LAN for instance), these 2 bits need to be forwarded to the 1bit/s link, and so we need to either queue or drop 1 of the 2 packets we received, while forwarding the other 1 bit. Here QoS should be used to decide what bit must be forwarded first, and what should we do with the other one (basically, drop or queue).

Second, in a real world situation, we have links that have a fixed bandwidth and that can transmit only at that bandwidth; for instance, an Ethernet 100M full duplex can send and receive data at 100Mbps only. If we're connected to an ISP with a 100M Ethernet link but we pay for 50Mbps, our link must send frames/packets at 100Mbps. To achieve the 50Mbps we need to do something like transmitting at 100Mbps for an half second, and than wait another half second without transmitting anything, obtaining the average of 50Mbps in the time of 1 second. In this example, a burst may allow to transmit at 100Mbps for 1 full second if we didn't transmit anything in the previous 1 second.

With these concepts in mind, we can understand that the link used at 50%, that hasn't any burst above the link capacity, will never be congested and QoS won't be used. On the other side, in a real world, it's rare to spend a lot of money for a WAN link that is never fully utilised (but it might be not in a LAN); also, peaks of traffic happen in a usually unforeseeable manner. Consequently, moments of congestion should be taken in account in a good plan, in order to permit the flow of the critical traffic while sacrificing the non critical one.

QoS is quite complex anyway, if you're interested I wrote this column: https://www.matteo.site/blog/post/quality-of-service/


QoS is complicated. It requires absolutely correct marking across the entire edge of your network and correct trust/queueing internal to your network to guarantee operation. Additionally the software/hardware operating in your network require different syntax and can affect QoS capabilities and operation. This is not to say that QoS is not a valid solution when you cannot afford to increase link capacity. Also with jitter-sensitive SLA-based traffic (SIP trunk/hosted VoIP) it is usually worthwhile to configure a priority queue in addition to a 'standard' queue.

Adding bandwidth solves the long-term problem of insufficient capacity without the complications involved in configuring and monitoring QoS performance, and then still having to add bandwidth when the link is over-saturated in some shorter-than-expected time period.

  • Downvote for "QoS is complicated" when OP stated he's an SP and protecting critical network protocols is reason enough. I'll remove downvote if comment is retracted or qualified. Apr 20, 2015 at 7:18
  • What does the last sentence of that paragraph read?
    – cpt_fink
    Apr 21, 2015 at 3:37
  • Last paragraph reads as "QoS is complicated" and more bandwidth is the answer when it's impossible to ensure sufficient bandwidth is always available. You've stated that QoS is a solution when link capacity can't be increased. I don't view the two as mutually exclusive and both are the correct answer IMHO. Apr 21, 2015 at 4:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.