What @liviu.gheorghe wrote is sometimes true, but sometime not.
Let's consider where QoS can, or cannot, "physical" bandwidth needs.
You have two hosts, that want to exchange a very large file, perhaps across a WAN link in the path.
So, if you say to me, we need to copy this X sized file, between these two hosts, my question would be, what's the acceptable time to do so. (Hopefully) obviously, to copy X bits in Y time will require a specific minimum transmission rate.
We determine we need 100 Mbps. Fine, so as long as hosts have FE interfaces, and at least FE end-to-end, in theory we can meet this requirement. During the data transfer, path will be at 100% utilization, but our needs are met.
Next, it's found we need to make that transfer in half the time. Easy add physical bandwidth, say gig end to end.
We do that, and we actual get a 10x time reduction. Usually, all good, but the hosts, by themselves, want to use the full gig.
Next, we decide to share this gig path with other traffic, say web traffic. Perhaps that traffic, on average only uses 100 Mbps.
Well, what often happens, web users will complain about poor web app performance because of the concurrent gig data transfer.
Can this be fixed by adding physical bandwidth? Sure can, as the data transfer hosts only have gig interfaces, if we upgrade the network path to 25 gig, all should be find. Unfortunately, what's the cost for that?
Or, if the data transfer truly only needs 200 Mbps, we can use QoS to manage our gig path's bandwidth, in different ways, to insure that data transfer doesn't cause erratic web app performance.
What happens when another and another large host to host data transfer happens? How much more bandwidth to you need to obtain to insure there's no oversubscription?
If there's oversubscription, QoS can often meet service requirements without the need for additional bandwidth. QoS can also often provide consistent performance rather than erratic performance.
Also unfortunately, many think QoS is only good for things like VoIP, where, yes, QoS is more or less required on many networks or it work well, but missed is how well other network applications can work with QoS being used.
I often tell, at one company I worked at, we had a remote site with two WANs E3 links, that during business hours were running at 100% flat out, all day long. You named it, we had that traffic on those links, but with QoS, all the traffic actual service need were met.
Or, same company, one of out core WAN routers rebooted itself and drop its QoS config. WAN engineer stated his phone was lit like a Christmas tree, with network complaints, until he restore the QoS config. (Yea, I guess if all our WAN links were 100G, perhaps no one would have complained, and we wouldn't have needed QoS, but start to compare costs - which most business also take a keen interest in.)
