QoS bandwidth reference

[mmorris11]

Wendell Odom says:

"Finally, IOS uses queuing only when congestion occurs. IOS considers congestion to be occurring

when the hardware queue is full; that generally happens when the offered load of traffic is far less

than the clock rate of the link. So, a router could have a service-policy out command on an interface,

with LLQ configured, but the LLQ logic would only be used when the hardware queue is full."

Nothing new here but in pages before he said:

"! The class map matches on UDP/RTP header and RTP port numbers.

class-map match-all voip-rtp

match ip rtp 16384 16383

! Next, the policy map uses the bandwidth command to reserve 64 kbps for the class

! voip-rtp. Class-default gets some of the leftover bandwidth by default.

policy-map queue-voip

class voip-rtp

bandwidth 64

class class-default

fair-queue

! The interface?s bandwidth 128 command is used as the basis for the limit on the

! amount of bandwidth that can be allocated in the policy map queue-voip.

! The load-interval command sets how often counters are updated. Also, note

! that the policy-map is enabled for output; input is not allowed on routers for

! policy maps that perform queuing.

interface Serial0/0

encapsulation frame-relay

load-interval 30

bandwidth 128

service-policy output queue-voip"

Note the "bandwidth command is used as a basis for the limit..." This indicates that the queueing would be active at 128k well below the interface tx-ring capability. Am I missing something? The way I see it these two things as they read on the page, cannot be true at the same time. If the queueing mechanisms are engaged only after tx-ring is congested, how can this "bandwidth reference" thing work?

[bogdan.sass]

I'm not sure what your question is...

1) When configuring QoS, you cannot reserve more than the interface bandwidth. Which is determined by the router based on the configured bandwidth command on that interface. Try to allocate more than that, and the policy map will be rejected when you try to apply it to an interface.

2) You can configure QoS at any time you wish. But as long as there is no congestion (the traffic stays below the interface limit), QoS will have no effect. As long as there is no congestion, there will always be free space in the hardware queue, so you don't use (and don't need) the fancy software queuing mechanisms. :) Those mechanisms will be used only when the interface is congested.

I don't see where the contradiction is. The bandwidth command is the "software" part, and decides what you can configure on that interface. The actual congestion is the "hardware" part, deciding when (or if) your configured QoS will go into effect.

[mmorris11]

I see what you are saying. That [feature] just doesn't seem particularly useful. Thanks for the input.