Could I use PQ along with CAR to ensure that say 40% of the link could be used for telnet, 20% for web based apps, then the rest for all other traffic? This way telnet could not take up the entire link making the interface drop all other packets? Or would it be easier to just use CQ?

An better way is to use CBWFQ, using the MQS option.

However, as food for thought, let me tell you this story. I seem to remember one trade magazine that asked a bunch of senior ISP network managers what their favorite QoS method was, and then challenged the readers to figure out what they picked. They had 7 choices, including queueing, RSVP, precedence marking, etc, and the possible answers were labeled from (a) to (g). However, the correct answer was actually none of the listed, but actually secret answer (h), which was "None of the above, I would just order more bandwidth". Makes sense too. Bandwidth is dirt cheap and getting cheaper by the day, while QoS can be tremendously costly in terms of router resources. Not to mention even more costly network expertise. For these reasons, I see QoS as having only limited applicability - the easiest and cheapest way to solve a congestion problem is usually to get more bandwidth.

LLQ under MQC is best option.

Bandwidth is not always the best solution for two reasons:

1. It may just move the bottle neck to another part of the network if unbalanced.

2. If the network is only temporarily backed up due to congestion, then queueing is the way to go. Ordering tons of bandwidth for a link that doesn't need it is just wasting cash. If the link is constantly backed up, the more bandwidth is the only answer.

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.

You are correct. But sometimes small companies cant afford tons of BW, so queueing is necessary, especially w VoIP. But I guess you are corect in the hidden cost of QoS.

Exactly. That is precisely what I've found with a lot of QoS implementations. Non-technical managers don't understand the hidden costs involved. So when they see a design proposal that shows the upfront costs of increased bandwidth, they blanch and choose the QoS option, not realizing that the QoS option often times will be even more costly, in terms of hardware, or especially in terms of people. It's one of those cases where what you think is free is in reality very expensive.