question in voice QOS about queue & gurantee bw

[Dr.X]

hi  all ,

im asking about qos in voice

want to know

what is the difference if i let voip traffic  get the 1st 30 % bw of traffic    and   between i give the voip traffic 30% gurantee of traffic ???

why the 1st one is better than the second one ??

shouldnt in the two cases we guranteed 30 % for voice traffic ???

wish to clarify

regards

[blau grana]

Hi,

I am not sure if I understand your question, could you please elaborate a little bit, thanks.

Best Regards

Please rate all helpful posts and close solved questions

[Dr.X]

im talkign about LLQ & cbwfq


im cbwfq there is no prioirty queue
i mean i only can do is  gurantee bw for voice and assume 30 %

but in LLQ i can use queue priority
i can   put voice in priority queue and  police it to 30 % of bw.



the question is ,

what is the difference between them ????

i have littele underdstanding and want to  make good understanding .

what is the difference between them ??

both of them has 30 % bw at least !!

why the LLQ is better than CBWFQ for voice ???


with my best regards

[Rolf Fischer]

Hi,

LLQ adds one (strict) priority queue for real-time traffic to the CBWFQ for the "normal data classes".

This PQ is not not serviced by the scheduler, as soon as real-time data comes in, it will be transmitted immediately regardless of the other queues.

With pure CBWFQ, in contrast, other queues could be serviced first which then could result in latency and jitter for the real-time data.

Have a look at figure 1-17 and 1-18 in this document, they show the diffenence very clear:

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp60974

HTH

Rolf

[Dr.X]

fischer.rolf wrote:
Hi,
LLQ adds one (strict) priority queue for real-time traffic to the CBWFQ for the "normal data classes".
This PQ is not not serviced by the scheduler, as soon as real-time data comes in, it will be transmitted immediately regardless of the other queues.
With pure CBWFQ, in contrast, other queues could be serviced first which then could result in latency and jitter for the real-time data.
Have a look at figure 1-17 and 1-18 in this document, they show the diffenence very clear:
http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND_40/QoSIntro_40.html#wp60974
HTH
Rolf

very nice reply ,

let me ask u a question ,

assume im downloading a file ,

and that file in not in priority queue ( assume i macthed it with classmap and  just appled bw gurantee to its class)

does that mean that there is some interrupt occurs during  downloading that file , due to round robin queue mechanaisim ???

i know that  i will not note it , but ,t it should be occuring  (due to my understand) , and this issue will be sensitive to voice  and will be noted .

that wt i understood

plz correct me if im wrong

regards

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

There's (hardware) interrupts whether traffic is in LLQ or non-LLQ class.  Both should be transparent to your download.

What actually happens on most routers (since you've asked about LLQ), egress traffic attempts to be sent to an interface hardware queue (tx-ring).  If that (FIFO) queue/buffer fills, excess packets are stored elsewhere. If you've using CBWFQ, the packets are stored into the queues defined by your CBWFQ policy.

If there are packets in the CBWFQ queues, when the hardware queue has new room (i.e. some packets have been transmitted), software dequeues packets from the CBWFQ queues based on the CBWFQ policy and based on previous dequeuing history.  LLQ, if any pakets are queued, is dequeued from its queue first.  Non-LLQ queues are proportionally dequeued.  So, for example, if there's two queues with packets, but one has twice the bandwidth allocation, the dequeuing will attempt to dequeue twice as many bits from the its class queue relative to the other class queue.

As Rolf noted, LLQ has priority over all other classes, when the CBWFQ attempts to dequeue from the software classes.  This to minimize any possible latency and/or jitter.  (NB: you can still have latency and jitter even with LLQ.)  BTW, you can have multiple LLQ classes, but there's only one actual LLQ (excluding perhaps ASRs).

One other important difference between LLQ and non-LLQ, the former will police LLQ queued packets.  The latter will allow additional bandwidth to be used beyond the class allocations.  (NB: if packets are not being queued to software queues, LLQ policer doesn't engage, i.e. it's possible for LLQ traffic to exceed its bandwidth allocation in such a situation.)