From: Brian McGahan (brian@cyscoexpert.com)
Date: Fri Feb 14 2003 - 18:11:45 GMT-3
No, the scheduler processes each queue top down for each packet
transmission. When a packet goes to be sent out an interface with a PQ
configured on it, it is checked against the priority-list, classified,
and then buffered. When a packet is ready to be taken out of the buffer
and put into the output queue on the interface, the router checks to see
if there are any packets in the high queue, if not, it checks the medium
queue, then normal, then low. Since this is done every time a packet is
transmitted, the higher queues are always guaranteed to get processed
before the lower ones. This is the reason that legacy PQ is not very
favorable, because the lower queues may not get processed at all if
there are lots of packets in the upper queues.
Remember that LLQ is different than legacy PQ though. In LLQ,
you only have one queue definition. In PQ, you have four.
A good source for descriptions on the different QoS methods is
the Cisco Press book "Inside Cisco IOS Software Architecture". A lot of
it is hard reading, but it gets into the nitty gritty details of how
Cisco routers and IOS work.
http://ciscopress.com/catalog/product.asp?product_id={44BD9713-382F-48A1
-B113-E4A8D0FF4F22}
For more on PQ:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
fqos_c/fqcprt2/qcfconmg.htm#23965
HTH
Brian McGahan, CCIE #8593
Director of Design and Implementation
brian@cyscoexpert.com
CyscoExpert Corporation
Internetwork Consulting & Training
Toll Free: 866.CyscoXP
Fax: 847.674.2625
> -----Original Message-----
> From: OhioHondo [mailto:ohiohondo@columbus.rr.com]
> Sent: Friday, February 14, 2003 2:36 PM
> To: Brian McGahan; 'P729'; ccielab@groupstudy.com
> Subject: RE: QoS need confirm-- a bit long
>
> I have a question on Priority Queuing.
>
> When the highest priority queue is emptied, the next highest queue is
> serviced AND the highest priority queue is not checked again until
that
> queue is emptied. Some thing like:
>
> Empty pri-1 (highest queue)
> Check pri-2 (next highest queue)
> Empty pri-2
>
> Check pri-1 (if there is data, empty pri-1)
> Check pri-2 (if there is data, empty pri-2 and go back to pri-1)
> Check pri-3
>
> If it works this way it should be totally unacceptable for real time
data
> --
> at least on E1 circuits and below.
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Brian McGahan
> Sent: Friday, February 14, 2003 1:54 PM
> To: 'P729'; ccielab@groupstudy.com
> Subject: RE: QoS need confirm-- a bit long
>
>
> My impression of the LLQ was that inside this PQ, it is FIFO. I
> haven't seen any documents that support or deny this though. I was
> actually having a discussion about this yesterday with a student, and
> they were asking the same question. Maybe it's time to open a TAC
case
> on it ;)
>
> Brian McGahan, CCIE #8593
> Director of Design and Implementation
> brian@cyscoexpert.com
>
> CyscoExpert Corporation
> Internetwork Consulting & Training
> Toll Free: 866-CyscoXP
> Outside US: 847.674.3392
> Fax: 847.674.2625
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > P729
> > Sent: Friday, February 14, 2003 12:20 PM
> > To: ccielab@groupstudy.com
> > Subject: Re: QoS need confirm-- a bit long
> >
> > "A strict priority queue (PQ) allows delay-sensitive data such as
> voice to
> > be de-queued and sent before packets in other queues are de-queued."
> > "Bandwidth command: Provides low latency: No"
> >
> > A dilemma I'm currently wrestling with is "what if you have two
forms
> of
> > delay-sensitive traffic, say voice and streaming video?" Both need
to
> be
> > de-queued ahead of other non-priority traffic, yet one can't
"starve"
> the
> > other... The delay tolerance of the video stream is not known, but
> even if
> > it were (it is likely to be more tolerant due to startup
> synchronization
> > and
> > buffering, but with larger packet sizes), how could one "interleave"
> the
> > two
> > types of priority traffic to stay within their respective jitter
> budgets?
> > Are there ways to tune WRR/CBWFQ/etc. to provide more than one
> "pseudo"
> > low-latency queue?
> >
> > Thoughts/experience anyone?
> >
> > Regards,
> >
> > Mas Kato
> > https://ecardfile.com/id/mkato
> >
> > ----- Original Message -----
> > From: "Brian McGahan" <brian@cyscoexpert.com>
> > To: "'Pang Gery'" <pang_gery@yahoo.com.hk>; <ccielab@groupstudy.com>
> > Sent: Friday, February 14, 2003 7:57 AM
> > Subject: RE: QoS need confirm-- a bit long
> >
> >
> > Gery,
> >
> > The bandwidth and the priority statement are different.
> >
> > The bandwidth statement is used to guarantee bandwidth for a
> > certain traffic class. This is a *minimum* guarantee for this class
> of
> > traffic. During periods of congestion, traffic in this class may
> still
> > burst above the configured rate, however it is always guaranteed the
> > minimum that is specified.
> >
> > The priority statement is used to guarantee low latency for
> > traffic. The priority statement is a *maximum* guarantee for this
> class
> > of traffic. All traffic that conforms to the configured rate is
> > guaranteed low latency (always dequeued first), however during
periods
> > of congestion, all traffic over the configured rate is dropped.
> During
> > periods of non-congestion, excess traffic may be transmitted,
however
> it
> > is not guaranteed low latency.
> >
> > For more information see the following article, "Comparing the
> bandwidth
> > and priority Commands of a QoS Service Policy"
> >
> >
>
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a
> > 0080103eae.shtml
> >
> >
> > HTH
> >
> > Brian McGahan, CCIE #8593
> > Director of Design and Implementation
> > brian@cyscoexpert.com
> >
> > CyscoExpert Corporation
> > Internetwork Consulting & Training
> > Toll Free: 866-CyscoXP
> > Outside US: 847.674.3392
> > Fax: 847.674.2625
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> > Of
> > > Pang Gery
> > > Sent: Thursday, February 13, 2003 6:43 AM
> > > To: ccielab@groupstudy.com
> > > Subject: QoS need confirm-- a bit long
> > >
> > > Hi Group,
> > >
> > > I have just reviewed the QoS part and make the following brief
> notes.
> > My
> > > focus is on whether the feature take effect with and without
> > congestioin.
> > > Could you please help to review and correct me if my concept is
> wrong?
> > >
> > > 1.1 Policy-based routing and QoS via BGP
> > >
> > > They just classify packets, will not drop packet, and take
> effect
> > with
> > > and w/o congestion.
> > >
> > > 1.2 CAR
> > >
> > > It can classify and drop packet, and take effect with and w/o
> > > congestion.
> > >
> > > 2.1 Priority Queue / Custom Queue Ip RTP / FR RTP / CBWFQ / LLQ
> > >
> > > Take effect only when congestion.
> > >
> > > 2.2 Question: is the bandwidth command used in policy-map of
CBWFQ
> > same
> > > as the priority command used in LLQ?
> > >
> > > My feeling is the bandwidth is used for data and priority is
> > used
> > > for real-time traffic like voice. Also, bandwidth sets the minimum
> > amount
> > > allocated for 'that traffic' at congestion, when there is no
> > congestion,
> > > 'that traffic' can use more available bandwidth.
> > >
> > > However, the priority command guarantee the maximum resources for
> > > specific traffic whether there is congestion or not.
> > >
> > > 3. GTS / FRTS
> > >
> > > They are not congestion management and will do the shapping
with
> or
> > > without congestion.
> > >
> > > Am I right?
> > >
> > > Thank you very much.
> > >
> > > Gery Pang
> > >
> > >
> > >
> > > Yahoo! =l)G/d(%+H=c .I$U<i,y$h&V
> > > http://voicemail.yahoo.com.hk
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:23 GMT-3