From: Petr Lapukhov (petrsoft@gmail.com)
Date: Thu Mar 23 2006 - 11:23:03 GMT-3
>So this one should give a shaping with FIFO + WRED inside a class and
>without nested policies.
>policy MNP
> class ABC
> shape XYZ
> random-detect
Alexei, a little problem here - that snippet wont work without "bandwidth"
specified for class.
This is obvious - RED/WRED works for non-default classes too,
but ONLY if you specify bandwidth. Bandwidth is required for CBWFQ to
properly queue packets ( in case of congestion) in every individual
class' FIFO queue. And WRED just specifies drop policy here.
But now, pay attention!
That WRED drop behavior will only affect packets AFTER they leave
shaper's queue, and ONLY if we have congestion on interface,
so that class' FIFO is filled with packets.
And if you need to create congestion with shaper, and dequeue
packets with RED drop in SHAPER's queue - you need nested policy here.
This is (how I think) CBWFQ works.. :)
HTH
Petr
23.03.06, Alexei Monastyrnyi <alexeim@orcsoftware.com> NAPISAL(A):
>
> agree about WFQ being for class-default only... but WRED is viable for
> all classes according to DQOS guide and I don't see any contradictions
> inhere, cause Weighted in WRED is not connected by any mean to Weighted
> in WFQ, they are just two different semantics for Weighted... :-)
>
> So this one should give a shaping with FIFO + WRED inside a class and
> without nested policies.
>
> policy MNP
> class ABC
> shape XYZ
> random-detect
>
>
> You are 100% right that overcoming of FIFO limitation for non-default
> class may be done via nested policies.
>
> A.
>
> on 23/03/2006 13:50 Petr Lapukhov wrote:
> > 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
> >>>
> >
> > _______________________________________________________________________
> > 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