Re: QoS - Multiple LLQs

Yes, only one queue, which works on a first come/first serve basis.
Multiples classes can have priority just to give you granularity for
policing options.

If you have HD video conferences, and each one takes 10Mbps for example, you
want to have a maximum of two, so it's 20 Mbps. And you want to have up to
50 concurrent phone calls at G711, which come down to something like
4,5Mbps. Total is about 24.5 Mbps then

But imagine you'll have only one class, configured with "priority 24500"
What if somehow a third videoconference is started?
All your other videoconferences and calls will die.

But when you have:
class video
priority 20000
class voip
priority 4500

then the third videoconference will only kill the other videoconferences,
not the voice calls.

So multiple classes only provide you with policing granularity. PQ is still
only on single FIFO queue that is served as soon as it has packets.

P.S.: technically, all packets that come into PQ are automatically assigned
a Sequence Number (or Finish Time) of 0, therefore they are always scheduled
for immediate departure in the CBWFQ (which then become LLQ)
Older implementations assign a very high sequence number to the packet in
priority queue that went over the policing limit.

Technically, a small modification would enable an implementation of
SUPER-HIGH and NOT-SO-SUPER-HIGH priority queues, because Sequence numbers
are Alfa and Omega of CBWFQ/LLQ scheduling.

On Thu, May 21, 2009 at 1:00 AM, Dale Shaw <dale.shaw_at_gmail.com> wrote:

> Hi all,
>
> Can anyone describe in detail, or point me at a resource that
> describes how the IOS queuing scheduler deals with multiple priority
> queues/LLQs?
>
> I have a scenario where I'd like to provide LLQ for voice (RTP), as
> well as specific *delay sensitive* voice signalling protocols.
> Ideally, using MQC/LLQ, I'd like to keep them separate. Based on my
> current understanding of the scheduler, there won't be a way to ensure
> LLQ1 is emptied before de-queuing LLQ2 (like there is in PQ). That's
> OK, as long as the combined bandwidth of both LLQs is guaranteed under
> congestion, and both LLQs are serviced before any other queues. I'm
> happy to be proven wrong about the relative LLQ priority though.
>
> I'm sure I've read about multiple LLQs before but I can't recall where.
>
> cheers,
> Dale
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Pavel Bykov
----------------
Don't forget to help stopping the braindumps, use of which reduces value of
your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net