- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: random-detect + fair-queue in CBWFQ posted 03/23/2006
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

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

- 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?


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
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? :)


Subscription information may be found at: