Hi John,

It looks like you may work for a bank (from your e-mail address). Your 
banks (assuming they are brick and mortar, which may be wrong!) don't have 
more than one queue, do they? ;-)

One queue is much easier to deal with and actually does a better job of 
providing service. Banks, post offices, airlines, etc., learned that long 
ago. The airline example might fit best: one queue for frequent flyers and 
one queue for the plebeians, in other words, one queue for each priority 
level. Is that sort of like what you're talking about with one priority 
queue and everything else in the ordinary queue?

Determining how much bandwidth to give to the priority queue is a classic 
and difficult issue. When I'm waiting in line at the airline counters and I 
see the plebeians getting faster service then me because the airline didn't 
put enough clerks on the frequent flyer queue, I get irritated. (Actually I 
don't fly that much anymore, but that used to be the case before I 
simplified my life. ;-)

Priscilla

At 10:10 AM 12/6/01, John Neiberger wrote:
>So, it appears that while we can configure two priority queues, IOS ends
>up combining them into a single priority queue.  Is that correct?
>
>This seems to make some sense given the definition of 'priority queue'.
>  How could you give absolute priority to two separate queues?
>
>If that's the case, then you definitely would want to place voice
>traffic in the priority queue by itself.  Perhaps then use the
>'bandwidth' queueing command for video traffic and then WFQ with or
>without WRED for the rest of the traffic.
>
>Then again, when configuring LLQ, we are not configuring an absolute
>priority queue.  In this case, the priority queue is good up to a
>certain point, limited by the amount of bandwidth apportioned to that
>queue.  Let's say we have created a 384k PQ but we have a full T-1
>available.  This simply means that any traffic in that queue gets
>absolute priority UP TO 384k.  Anything over that gets dropped.
>
>It seems to me that this leaves a lot of room for other priority
>queues.  Why should we not be able to create yet another PQ with 384k,
>for example?  In my mind this would mean that for a given cycle, the two
>priority queues would each get 384k of the 1544k available for output.
>
>However, I think this highlights the issue.  We now have two priority
>queues and they can't be serviced at the same time, unless some sort of
>interleaving were possible.  Hmmm.....food for thought.
>
>Queueing is just so much fun.  :-)
>
>John
>
> >>> "VoIP Guy"  12/6/01 6:40:40 AM >>>
>I like to learn, so forgive me if I am beating this subject, but in
>order
>for me to become a CCIE, I need to know everything.  I've been reading
>up on
>the real story on two priority queues, been asking a couple of CCIE's
>and
>been on CCO.  Just as I suspected, there is only 1 PQ in LLQ, or any
>queuing
>method for that matter.  If you enter two (or more) different classes
>to
>have strict priority, the all enter the same priority queue.  To quote
>from
>Cisco:
>
>"...The Low Latency Queueing feature provides strict priority queueing
>for
>CBWFQ, reducing jitter in voice conversations. Configured by the
>priority
>command, Low Latency Queueing enables use of a single, strict priority
>queue
>within CBWFQ at the class level, allowing you to direct traffic
>belonging to
>a class to the CBWFQ strict priority queue. To enqueue class traffic to
>the
>strict priority queue, you configure the priority command for the
>class
>after you specify the named class within a policy map. (Classes to
>which the
>priority command is applied are considered priority classes.) Within a
>policy map, you can give one or more classes priority status. When
>multiple
>classes within a single policy map are configured as priority classes,
>all
>traffic from these classes is enqueued to the same, single, strict
>priority
>queue...."
>
>Here is the link for surther study.
>
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120
>
>t/120t7/pqcbwfq.htm
>
>I am still researching Mike's claim that states that fast-switching
>bypasses
>the counters for the queue.  I will set up an experiment later on today
>in
>the lab.  I know for a fact that with fast-switching, there still are
>queues, but maybe Mike's right in stating that the counters aren't
>used.
>I'll let you know.
>
>Steve
>
>
>
>""Steve Ridder""  wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > It definitly works, but I've always been told to use 1 priority queue
>for
> > voice, then CBQ the SNA and video and WFQ with WRED on the rest.
> >
> > They say voice is most important because it has the highest human
> > perception, and humans will notice bad voice before bad video.
> >
> > Steve
> >
> >
> > ""John Neiberger""  wrote in message
> > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > I can immediately think of one example.  Let's say you have a T-1
>access
> > > link with multiple data types that include VoIP and video
>conferencing.
> > > You want to make sure that VoIP traffic gets its own priority
>queue, so
> > > let's say you give it 384k.  You then want to give the video
> > > conferencing traffic another priority queue because it's such a
> > > high-visibility technology, so you allow it to use another 384k.
> > >
> > > This would leave roughly half of the link available for other data
> > > types during periods of congestion while making sure your high
>priority
> > > applications (pun intended) do not drop packets and have the
>lowest
> > > latency possible on that link.
> > >
> > > I will be attempting exactly this sometime next year when we roll
>out
> > > VoIP to a branch that already has video conferencing.  To make
>matters
> > > more interesting, this is on a frame relay link, not a
>point-to-point
> > > link.  Lotsa fun!
> > >
> > > I had heard, though, that only one priority statement was
>possible.
> > > You're saying that you successfully used two?  That's good news for
>me,
> > > I was starting to get worried.  I'd be interested to find out if
>it
> > > truly behaved as expected when experiencing congestion.  If you
>test
> > > this out, please let us know what you find.
> > >
> > > Regards,
> > > John
> > >
> > > >>> "VoIP Guy"  12/5/01 1:51:13 PM >>>
> > > Has anyone ever seen 2 priority queue's in LLQ?  What would be the
> > > reason
> > > and how would those 2 get serviced?  Round Robin?  FIFO?  It does
>work
> > > beucasue I just saw it on a config and tried it myself, but can't
> > > figure out
> > > why they did it.
> > >
> > > Steve
________________________

Priscilla Oppenheimer
http://www.priscilla.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=28309&t=28227
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to