From: Petr Lapukhov (petrsoft@gmail.com)
Date: Thu Mar 23 2006 - 09:50:56 GMT-3
Okay, i'm not a QoS guru, so here are some of my
humble comments :))
Looking at
policy MNP
class ABC
shape XYZ
fair-queue
random-detect
I just want to note:
1) that config will only work for class-default: non-default classes do
not permit WFQ.
2) if we need to change SHAPER's queue behavior/drop policy, we must
use NESTED service policy e.g.
policy-map RED
class class-default
fair-queue
random-detect
policy-map MNP
class ABC
shape average XYZ
service-policy RED
Now we have infamous WFQ working for shaper's queue + RED as drop policy
for the same queue too.
HTH
Petr
PS
What if we have WFQ (which uses IPP to weight flows) + RED dscp-based? :)
23.03.06, Alexei Monastyrnyi <alexeim@orcsoftware.com> NAPISAL(A):
>
> oops.. sorry, posted to the wrong chain initially...
>
> As DQOS Exam Guide states "CBWFQ can use WFQ as the default behavior for
> unclassified
> traffic. Packet loss behavior can take advantage of WRED..."
>
> "Weighted" part of RED is either dscp-based or precedence-based, so IMO
> if we switch on WRED for any class in CBWFQ, we override the default
> modified tail-drop which comes with WFQ out of the box.
>
> Hope DQOS citation does not break NDA... :-)
>
> The interesting thing here is when it comes to shaping queuing. If we put
> "
>
> class ABC
> shape XYZ
> fair-queue
> random-detect
>
> - does it modify a drop policy for shaping queue or is it for congestion
> management only?
>
> IMO it drop policy for shaping should be modified by doing this,
> otherwise we don't have any mean to control it. Thought it was not
> promised. :-)
> One more point tfor this is that we don't have any explicit congestion
> management queuing for the class in this case but queuing inherited from
> physical interface or sub-interface. Modifying tail-drop behavior for
> those queues from MQC doesn't seem to be viable.
>
> Any comments from gurus?
>
> A.
>
> on 23/03/2006 09:23 Petr Lapukhov wrote:
> > Hello group,
> >
> > Maybe this is too much of a theoretical question, but..
> >
> > It would be really nice to know, how do "random-detect" and "fair-queue"
> > work together in CBWFQ.
> >
> > I understand the concept of RED with FIFO queueing, actually this is how
> it
> > worked back in days:
> >
> > RED/WRED/Flow WRED - all were considered a "queueing strategies", and
> when
> > you enable
> > random-detect on interface, you have to disable fair-queue, etc. The
> queue
> > becomes
> > FIFO, and RED is actually a _drop_ strategy.
> >
> > Okay, now, if we have bandwidth configured in CBWFQ class, the class'
> queue
> > becomes FIFO.
> > So one can easily understand how RED works here, no problems.
> >
> > But then, we come to work with class-default. We can turn on WFQ/RED at
> the
> > same time, withing class-default.
> >
> > Recalling that WFQ has, by itself, it's own drop strategy, which is
> based
> > on queue-limit, CDT and SNs of each flow, i become puzzled here.
> >
> > How does RED incorporate in WFQ? Does it works per-flow, with CDT
> > being one of the thresholds? How does it affect original WFQ drop
> behavior?
> >
> > Maybe someone here knows the answer? :)
> >
> > TIA
> > Petr
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:39 GMT-3