On (2011-09-02 12:02 -0400), Valdis.Kletnieks@vt.edu wrote:
Except you can't actually *guarantee* that QoS works every packet, every time, during congestion even within the same network. Remember - QoS is just a marking to shoot the other guy first. If a link ends up overcommitted with QoS traffic, you're still screwed. And there's a second-order effect as well - if
I guess you're trying to say, if the protected traffic class is out-of-contract you're still out of luck, that is true. If you're trying to say that any link which which is overcomitted is lost cause anyhow, QoS or not, this of course is not true, if link is not overcommitted QoS makes no sense.
your net is running sufficiently close to the capacity edge that QoS actually matters, there's probably other engineering deficiencies that are just waiting to screw you up.
Lot of customers have low speed DSL connections and want to run VoIP over that, even if whole office is surfing lolcats. This works, and it works perfectly when configured correctly, of course if VoIP traffic would exceed capacity, you're still screwed, this is where planning comes in, you will sell only X VoIP lines which will always fit, just lolcats will load slower. If this link gets uncontrollable priority traffic from Internet, all bets are off, hence the options in the first post -- ++ytti