LLQ question

Unanswered Question
Jun 8th, 2007

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Fri, 06/08/2007 - 11:43

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".

thotsaphon Sat, 06/09/2007 - 22:54

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

ciscoforum Mon, 06/11/2007 - 10:21

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.

Paolo Bevilacqua Mon, 06/11/2007 - 10:39

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.

ciscoforum Mon, 06/11/2007 - 13:20

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.

Paolo Bevilacqua Mon, 06/11/2007 - 14:00

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.

ciscoforum Tue, 06/12/2007 - 11:13

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.

Paolo Bevilacqua Tue, 06/12/2007 - 12:01

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.

Actions

This Discussion