Hold on. I never said that bandwidth is always the best solution.
But I would say that the majority of the time that a manager requests QoS, the problem could probably be solved cheaper and more effectively with more bandwidth. QoS is useful in special cases. But people try to extend it too far without realizing its problems.
Or let me say this. If I was a manager, and I had a congestion problem, I would have 2 choices - QoS or more bandwidth. QoS might seem to be the cheap and easy answer, but that is an illusion because the costs of QoS are hidden.
The disadvantage of QoS is twofold. One, you are placing significant strain on your routers, and the more fancy your QoS, the more strain you are placing on them. You are therefore risking the stability of your network, unless you want to upgrade your routers, but then that's part of QoS's hidden cost.
Two, and much more pervasive is the cost of network expertise. Let's face it - network traffic patterns change all the time, so the source of congestion will always be changing. This therefore means I will constantly have to have a trained network dude around to watch the traffic patterns and adjust things accordingly. So either I will have to hire another guy, or one of my existing guys will have to spend man-hours doing just that. Either way, that's a major part of the hidden costs of QoS. Generally speaking, the cost of labor is much more than the cost of bandwidth.
In fact, I've noticed that many network engineers know this all too well. I've seen many network proposals where the engineer has proposed QoS to 'groom and manage' network streams or whatever. And from what I can tell, the only thing they're 'grooming and managing' is their own job security. They seem fully aware that the network usage will change, and therefore the QoS policy must change, which means they'll always have a job. Now, there's nothing wrong with that, cause everybody's got to look out for themselves in this kind of job market. You should just understand what it is that you're doing.
