From: Alexei Monastyrnyi (alexeim@orcsoftware.com)
Date: Thu Mar 23 2006 - 10:55:09 GMT-3
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