Comments on ipSpace.net: CB-WFQ misconceptions

Last line of the "High queue" printout, ...

2011-02-08T09:49:51.000+01:00

Last line of the "High queue" printout, the 'depth' value. It indicates there are 4 packets in the high queue waiting to be transmitted, so the congestion is obviously there.

Hi Ivan, About the depth which is 4...what is the...

2011-02-08T06:53:33.000+01:00

Hi Ivan,

About the depth which is 4...what is the reference on the output why you mentioned it is congested?

Thanks a lot

Steve, I agree with your "lesson learned&quo...

2009-12-10T17:19:10.000+01:00

Steve,

I agree with your "lesson learned", it's just another way of saying what I did. I was simply pointing out that the "common wisdom" on how CB-WFQ works (and what the default behavior is) is plain wrong, so I don't understand precisly why it seems you're somewhat cross with me.

As for HQF: if you browsed through the list of "related posts" (just below the article text), you'd find links to the HQF tests I did (and if you had read them, you'd have discovered I adore HQF).

Your original tested yielded exactly the results o...

2009-12-10T16:57:22.000+01:00

Your original tested yielded exactly the results one might expect on a ISR or 7200 running code prior to 12.4.20T. The bottom line is that a class based queue in not guaranteed any significant bandwidth unless there is a bandwidth statement applied. You chose to forgo the minimum bandwidth guarantee to do WFQ in the default class, thus the default class was essentially serviced in a best effort manor, and the 10.0.3.2 flow received less bandwidth. Lesson learned hear is to be explicit in your configurations and don't always rely on defaults if you don't know the default behavior for a particular device.

Now as mentioned earlier, Cisco made a code change to the ISR/7200 QoS code starting in 12.4.20T finishing in 12.4.22T. This code change eliminated the WFQ option in the class-default and now allows for FQ to be enable in any non-priority class in conjunction with the bandwidth command. This change makes the queuing behavior more like the 7500, flexwan and SIP200. :-D

Ivan, Can't go past any QoS discussion :) Her...

2009-11-07T11:50:12.000+01:00

Ivan,

Can't go past any QoS discussion :) Here is the summary of the "research" i did back in days on CBWFQ (classic)

http://blog.internetworkexpert.com/2008/08/17/insights-on-cbwfq/

Back then i tried to do some "reverse engineering" on CBWFQ, to show how exactly it adapts the classif WFQ weighting formula. Right now i'm trying to come with a similar writeup on HQF, though it significantly tougher - they hide all "implementation-dependent" details now.

As it can be seen, CBWFQ really treats class-default "poorly", even with fair-queue enabled. Cisco never clarified that misconcept, and I personally had some real-life issues with it :)

My understanding is that under congestion any rema...

2009-11-06T17:37:57.000+01:00

My understanding is that under congestion any remaining bandwidth after queuing allocations gets assigned proportionately. So of the remaining 128K, High would get 50%, and class-default would get an implied 50%. You can influence this with the command bandwidth remaining.

I would have tried this with UDP mode of TTCP

2009-11-06T14:48:21.000+01:00

I would have tried this with UDP mode of TTCP

I agree with you that class High can theoritically...

2009-11-06T00:12:19.000+01:00

I agree with you that class High can theoritically starve the default class...

...However if you ran 2 simultaneous TCP sessions during your test, after a few "moments", shouldn't the behavior of TCP (slow start, round trip time measurement, congestion window, and all the stuff like that... I'm not an TCP expert ;) ) equal balance the throughput of both TCP sessions?

Yah. I dealt with that at one site by using a &quo...

2009-11-05T02:21:07.000+01:00

Yah. I dealt with that at one site by using a "police cir percent <bw> pir percent <bw>" style policy over several classes. That way, classes can exceed their minimum guaranteed bandwidth but can't consume the entire link.

The demonstrated result is the correct behaviour. ...

2009-11-05T00:13:06.000+01:00

The demonstrated result is the correct behaviour. The "bandwidth" or "bandwidth percent" commands allocates the configured bandwidth for a class/queue. In case of more traffic or congestion, these classes will starve the class-default class, essentially making it a "sacrificial goat". This is CB-WFQ.

On the other hand, "priority" command will absolutely cut-off at the configured bandwidth but that makes it LLQ. 8-)

Does the fact that reserving any percentage gives ...

2009-11-04T21:05:22.000+01:00

Does the fact that reserving any percentage gives it higher priority so the WAN queue is serviced more often have an effect causing the disparity?

Mike

sorry Ivan, i cudnt get you. My explanation was -...

2009-11-04T20:39:46.000+01:00

sorry Ivan, i cudnt get you.

My explanation was -
ON HFQ images i.e. 12.4(22)T and onwards, class "with bandwidth" keyword have an inbuilt-policer applied

and the class "without bandwidth" have implicit bandwidth reservation..

yes they are totally different as both are polar points and apply to different classes...

anything missed? you'll like to elaborate.

Thanks.

P.S: i'm lost in my empirical labs based on your MPLS architecture stuff for SP lab :)

Just a bit of a warning: there's a huge differ...

2009-11-04T17:37:48.000+01:00

Just a bit of a warning: there's a huge difference between "implicit bandwidth reservation" and "inbuilt policer".

No, the interface was a point-to-point 256 kbps li...

2009-11-04T17:35:56.000+01:00

No, the interface was a point-to-point 256 kbps link (yeah, I know, the "clock rate" command was configured on the other side).

this restriction of unequal distribution for "...

2009-11-04T17:15:04.000+01:00

this restriction of unequal distribution for "classes without bandwidth keyword" has been fixed in IOS 12.4(22)T onwards which support HQF..on those IOS, regardless of configuration, class class-default in HQF images will always have an implicit bandwidth reservation equal to the unused interface bandwidth not consumed by user-defined classes.

So on 12.4(22)T onwards, CBWFQ has kind of inbuilt policer (somewhat like LLQ)

12.4(22)T onwards support Hierarchical Queueing Framework (HQF) feature.. In HQF images, flow-based fair-queues, configurable in both user-defined classes and class default with fair-queue, are scheduled equally (instead of by Weight). By default, the class-default class receives a minimum of 1% of the interface or parent shape bandwidth. It is also possible to explicitly configure the bandwidth CLI in class default.

few more details/results given on my blog -

http://eminent-ccie.blogspot.com/2009/09/qos-congestion-management-demystified.html

http://eminent-ccie.blogspot.com/2009/11/cbwfq-and-llq-revisited.html

cheers
Swap
#19804

Shouldn't you be using a nested service-policy...

2009-11-04T17:01:28.000+01:00

Shouldn't you be using a nested service-policy and shape the interface down to 256K (Assuming that you have a 256K CIR) and then allocate your 50 percent from that?

Amazed to see how the bandwidth allocation is more...

2009-11-04T14:23:47.000+01:00

Amazed to see how the bandwidth allocation is more than allocated. I think Cisco is trying to put us in the dark and will come up with new solution after showing the limitation of previous one.
But the results and comment helped me to for my exam.

Thanks Ivan

Sure. That's why I've reserved 50% ... but...

2009-11-04T14:11:47.000+01:00

Sure. That's why I've reserved 50% ... but it got almost 100% :-E

Did you take into account that by default you can ...

2009-11-04T14:06:09.000+01:00

Did you take into account that by default you can only reserve 75% of the max bandwidth?

If you'd get drops on a WAN link running two p...

2009-11-04T13:45:45.000+01:00

If you'd get drops on a WAN link running two parallel TCP sessions, something would be awfully wrong. You don't need drops to have a congested line.

You're absolutely correct. I was writing about...

2009-11-04T13:45:03.000+01:00

You're absolutely correct. I was writing about HQF a few days ago and a comment Petr made on that post triggered this investigation.

WRONG. If you look at the printout, you'll fin...

2009-11-04T13:44:21.000+01:00

WRONG. If you look at the printout, you'll find that the depth of the HIGH queue is 4, so the congestion is there.

You're absolutely correct. The drawback is tha...

2009-11-04T13:43:22.000+01:00

You're absolutely correct. The drawback is that you have FIFO queuing in the Others class (unless you use HQF).

Absolutely agree with you. My point was that a cla...

2009-11-04T13:42:43.000+01:00

Absolutely agree with you. My point was that a class with 'bandwidth' action can get WAY MORE than you'd expect UNDER CONGESTION and starve the default class.

Where's your drops!?

2009-11-04T12:38:41.000+01:00

Where's your drops!?