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%.
EDIT:
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.
Best Answer
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.