QOS - Basic Question

Unanswered Question
May 29th, 2008

Hi guys,

Wondering if someone could give a hint

From OReilly Cisco IOS Cookbook:

The main reason for using QoS in an IP network is to protect sensitive traffic in congested links.

In many cases, the best solution to the problem of congested links is simply to upgrade these links...

...how to handle the queuing when the links are congested

So my question is, does QOS only take place only when links are congested?

I mean if you have voice, video traffic and links are not congested you won't have problems?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (3 ratings)
shiva_ial Thu, 05/29/2008 - 21:13


Assume that we have 2 MBps link and normal utilisation on link is around 1 mbps

suddenly a guy tries todo FTP.

protocol like FTP will try to utilise the link completely so entire 2 mb link will be flooded.then all other traffic gets congested which may affect other application traffic passing by.

This FTP traffic,guy has pumped in can be avoided for which qos comes in.

It will priorite the traffic passing on the link based on access-lists we define as policy

there is an question why we should not upgrade the link.

yes even if you upgrade the link heavy bandwidth consuming protocol like FTP will try to consume entire 4 MB completely,same case as 2mb and we land in slow response issue.

so qos would be better if there are some temporary congestions , and upgrading the link would be better if we always experience

a congestion means always we have genuine traffic of 1.8 Mbps of 2 Mbps.

hope it was clear

rate if it helps.


Joseph W. Doherty Fri, 05/30/2008 - 04:09

QoS encompasses many techniques for dealing with congestion. If there's never (ever) any congestion, there's no need to consider QoS. However, it's very rare to find networks that can't congest somewhere, yet statistically, such congestion might be acceptable for the traffic being congested. If not, the two solutions are either to increase bandwidth until the statistical results are acceptable or to deal with the congestion intelligently, i.e. QoS.

On LANs, where bandwidth is usually plentiful and relatively inexpensive, QoS might not be used at all or only in the most rudimentary fashion (e.g. only prioritize real-time traffic). On WANs, where bandwidth is often not as plentiful and relatively expensive, QoS techniques can be very beneficial.

n.nandrekar Fri, 05/30/2008 - 04:37

Well,I see from the responses that it is clear that Qos will kick in only in case of congestion. I agree to this as far as queueing is concerned.

But if you consider features like policing/ shaping etc, there is no need for the link to be congested for these features to kick in. Again you could argue looking at the bigger picture... but for practical purposes, you have a fastethernet link to your SP. But you have bought only 2Mbps of bandwidth. Then you might want to shape the traffic and prioritize it so that imp. traffic is not dropped by the SP.

So yeah... "queueing" features only kick in when there is congestion. but not Qos if you consider policing/shaping etc. to be a part of it. :)



shiva_ial Fri, 05/30/2008 - 05:05


answering your last question

qos kicks in only if hardware queue gets filled.

there are two types of queue

hardware queue -kind of queue normally hardware interface has.

software queue-which is qos

qos kicks only if this hardware queue gets filled..

rate if it helps.



This Discussion