I
ve had some thing familiar @ the GSR & CRS-1 implementation for my Mobile
Operator.
2 LLQ classes will act as 1 LLQ at the end based on the Scheduling & HW
Arch,
My advise is to have 1 LLQ with High BW , it can reach 45 % ( that based on
the type of provider....ISP or Mobile Operator)
OR have 1 LLQ for VOIP and another class with minimum BW garentee for Video
you must be well aware of teh type of HW & OS your implemeting teh QOS on,
as sometimes the got difrrent reactions :)
-----------------------------------
Thanks & B.regards
Ahmed Elhoussiny,CCIE# 21988 (R&S)
Network Consultant & Cisco Academy Instructor
On Thu, May 21, 2009 at 12:44 PM, Pavel Bykov <slidersv_at_gmail.com> wrote:
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
-- ----------------------------------- Thanks & B.regards Ahmed Elhoussiny,CCIE# 21988 (R&S) Network Consultant & Cisco Academy Instructor Blogs and organic groups at http://www.ccie.netReceived on Thu May 21 2009 - 14:50:45 ART
This archive was generated by hypermail 2.2.0 : Mon Jun 01 2009 - 07:04:43 ART