Hi ciscoforum

Software queuing that you configured in this case is LLQ. This won't be used if the link isn't congestion.

Note : Be careful about the bandwidth that you configured if it is less than exact bandwidth that you need then the exceeding packets will be dropped all the time because in this queue inherits tail drop of FIFO mechanism.

As paolo said : You can confirm with "show policy-map interface".

Hope this helps

L.Thot

I had the same idea as you guys before I saw the following from Cisco. It apparently even without congestion the priority queue is still necessary and used to fix the queuing and buffer latency. In other word, the data still will cause delay if in a non congested port and as we thought if priority not used.

Queuing/Buffering Delay

After the compressed voice payload is built, a header is added and the frame is queued for transmission

on the network connection. Voice needs to have absolute priority in the router/gateway. Therefore, a

voice frame must only wait for either a data frame that already plays out, or for other voice frames ahead

of it. Essentially the voice frame waits for the serialization delay of any preceding frames in the output

queue. Queuing delay (?n) is a variable delay and is dependent on the trunk speed and the state of the

queue. There are random elements associated with the queuing delay.

For example, assume that you are on a 64 Kbps line, and that you are queued behind one data frame (48

bytes) and one voice frame (42 bytes). Because there is a random nature as to how much of the 48 byte

frame has played out, you can safely assume, on average, that half the data frame has been played out.

Based on the data from the serialization table, your data frame component is 6 ms * 0.5 = 3 ms. When

you add the time for another voice frame ahead in the queue (5.25 ms), it gives a total time of 8.25 ms

queuing delay.

Hello,

Actually the example you quoted, is about a congested interface, because when the voice packet arrives, another packet is being sent out. Being the interface in the example a mere 64 kpbs, this happens quite often.

But, on high speed like fast ethernet that can transmit 144,000 packets per second, there is no much probability that congestion (more than few packets in queue, or packet drops) will ever happen.

So there is a big difference waiting for packets to be transmitted over a slow or a fast link.

I agree with you that slow link for sure has more chance to be congested. But even fast link you stil have to wait the data packets to be sent out if no priority used. Say you have 10M link, there is FTP packet train each with 1500 byte are sending. Then voice has to be waited until it is finished. If the tfp size is 1M byte, then you could wait about 1s before send the voice. And it's not congested yet since 1Mbyte technically only uses 9Mbits link.

Hmm no, is not like that, let's take you example.

FTP being TCP does not really sends packet trains but is limited to the TCP window size. After a little bit of time (and few packet drops perhaps) it will adapt nicely and will start sending at a steady rate, let's sat 9 mpbs per second. There is still 1 mbps left, now without QoS it will be strictly FIFO. One voice call being some 110 kpbs will still work, and believe me, no packet will ever wait 1 sec, because the default of 40 packets output queue size on a 10 mbps interface, means less than 50 msec for packet size 1500 !

Rememeber that one single TCP flow is never enough to completely fill a link.

Now, it that circuit was shared by many many users, or with aggressive UDP senders, yes you could have issues.

You can try that in your lab if you want.

My point is priority queuing is still should be used even in a non congested link if priority is configured. Take the same example above(or maybe say UDP for argument per say), voice will wait more time at least 50ms in your calculation. But if priority is being used then voice doesn't have to wait so long. It could just wait for one packet.

Hi,

We may agree to disagree.

I have no interest in making you not to configure QoS on LAN interfaces, it's just that is useless.

I don't say this to make weight my opinion, but I've formed it in 15 years of networking, and I was with cisco already when voice and qos was introduced, and I was lucky enough to have it proved many times on both real networks, and sophisticated laboratories.