From: P729 (p729@cox.net)
Date: Fri Feb 14 2003 - 19:53:37 GMT-3
You're describing strict priority for all queues. Some implementations offer
only one priority queue, with the others serviced in a WRR fashion.
Regards,
Mas Kato
https://ecardfile.com/id/mkato
----- Original Message -----
From: "OhioHondo" <ohiohondo@columbus.rr.com>
To: "Brian McGahan" <brian@cyscoexpert.com>; "'P729'" <p729@cox.net>;
<ccielab@groupstudy.com>
Sent: Friday, February 14, 2003 12:35 PM
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