06-08-2007 11:34 AM - edited 03-14-2019 09:58 PM
Somewhere I read that if the wan link is not congested then the priority queueing mechnism is not used. A little confused about this. say I have a 256K wan, and 90k assigned to voice for about 3 G729 calls. say same time there are 100K data. WE see here in total is less than 256. so it's not congested. Does that mean the voice traiffic is not put into priority queueing because no congestion? If that's the case, which queue does it put before exit? THanks
06-08-2007 11:43 AM
Hello,
queues actually exist only when there is congestion. When there is not, packets leave immediately the interfaces and no queueing occurs. If you want to see how your Qos is working, try "show policy-map interface".
06-09-2007 10:54 PM
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
06-11-2007 10:21 AM
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.
06-11-2007 10:39 AM
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.
06-11-2007 01:20 PM
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.
06-11-2007 02:00 PM
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.
06-12-2007 11:13 AM
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.
06-12-2007 12:01 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide