CBWFQ/LLQ Bandwidth allocation question, please help

[blackladyJR]

Hello,

After reading multiple document, I have left with many question marks in my head. Can you please help to clarify?

I know by default total bandwidth is 75% for all the class defined in the policy map including voice and data (i.e including the bandwidth from LLQ). So here is the example:

Say we stay with the default so 25% belongs to default class and say we have a T1 serial so bandwidth is 1536 on the interface.

Now, 25% of 1536 is 384k. So we are left with 1152k to work with for all the voice and AFxx I assume. Say we have 128k for voice in LLQ. So that left with 1024k for all the AFxx class to use and I assume I just have one AF41 to use all the bandwidth

policy-map test

class EF

set ip dscp ef

priority 128

class AF41

set ip dscp af41

bandwidth 1024

class class-default

So i assume that will be the policy-map. If I want to define the exact above via bandwidth percent, will it be like this?

policy-map test

class EF

set ip dscp ef

priority 128

class AF41

set ip dscp af41

bandwidth percent 67

class class-default

So I am using bandwidth percent so it is the absolute percent to the interface so 1024k of 1536 will be 66.7%. So the default class still will be 25% with 384k, correct? The voice is 8.3% so when I add LLQ + AF41 + BE = 8.3+66.7+25=100% of 1536.

How about if i use bandwidth remaining percent? how would that change?

policy-map test

class EF

set ip dscp ef

priority 128

class AF41

set ip dscp af41

bandwidth remaining percent 73

class class-default

why 73? if the remaining percent is relative term to the bandwidth left after LLQ. Then we have 1536-128=1408 left for AF41 and Default class. So 1024k/1408k = 72.7% while the same 384k Default will be 27.2% in the bandwidth remaining percent perspective.

So is it correct that Default class is 25% in bandwidth percent (absolute) and it is 27.2% under bandwidth remaining percent with 128k LLQ?

So when I use bandwidth percent, when I add up the percent value of AF41 + Default is not equal to 100%. It will be 100% if I add LLQ + AF41 + Default.

but when I use bandwidth remaining percent, then the % value will be 100% when I add AF41 + Default because it is relative term of the remaining bandwidth after LLQ. So 73%+27% in AF41+BE under bandwidth remaining = 100% of 1408k.

[milan.kulik]

Hi Joseph,

ad "how multiple class-default FQ flows also compete for bandwidth")

If you read the Questions/Answers below the article, #8 confirms Sequence Numbers (described in Cisco WFQ documentation) are assigned not only to FQ packets, but also to packets coming to other (User-defined) Classes.

This is exactly what I was missing in all Cisco documents and books :-((

(Cisco trying to keep their know-how possibly?)

I'm not sure if assigning an explicit bandwidth value to the class-default is an optimal solution. You are degrading it to a simple FIFO then, but IMHO, the internal SN algorithm probably keeps running even among less flows (one per a class).

BR,

Milan

[Joseph W. Doherty]

Milan, oh I agree making class-default FIFO isn't optimal (depending on what you're trying to optimize), and yes things may run smoothly between class flows, except, I believe, when one class, class-default, has multiple flows within the class which are competing for bandwidth against single class flows.

The better solution is seen on some platforms such as the 7500, 6500/7600 FlexWAN and SIP-200, which limit the aggregate bandwidth of multiple FQ with class-default. (They also permit FQ within other classes.)

Take a look as section Understand Platform Differences within http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800fe2c1.shtml#platform, although the document is about ATM interfaces, believe scheduling holds true for other interface types.

On platforms that allow class-default FQ flows to schedule against defined classes, the only way I see you can easily guarantee your bandwidth allocations for defined classes is insuring class-default doesn't use FQ.

I'm sure you understand, as number of flows with FQ increase, each individual flow receives proprotional less bandwidth guarantee. Again, the problem is, this would also hold true for other class flows on those platforms which don't constrain class-default FQ.

Given all the variables and if we know the total allowed FQ flows and if we allow for FQ IP Precedence impact, we can predict any individual flow's bandwidth guarantee. A lot of work though, and we hope Cisco doesn't change the internal rules as they might on maximum number of flows permitted or as they done with base weight (4096 vs. 32384).

So, again, your reference is extremely interesting, but you may place your network functioning as intended at risk using undocumented information, and you make a lot of work for yourself (and others to support) if you need to calculate each flow's bandwidth guarantee when using FQ.

Don't misunderstand, I'm not suggesting not to use FQ, just depending on what you're trying to accomplish, the QoS impact might be consirable depending on platform and whether it's active or not.

[blackladyJR]

Here is an interesting page from cisco about IOS 12.2.20T.

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/white_paper_c11-481499.html

It talks about default class with FQ no longer use IP Precedence to determine weight but it serves equally. Maybe I just read this wrong.

Also it mentions we no longer need to assign max-reserved-bandwidth as we can use all 100% (with at least 1% for default class) so the 75% rule is gone in this release.

I am not familar with this HQF of what it means. Does that mean starting this IOS version, all the changes in this link will apply to general CBWFQ?

Here is a link by Andy with simulation of exact same config with an version prior to 12.2.20T and then with exact config with 12.2.20T. The result is dramatic different.

http://cisconinja.wordpress.com/2009/01/22/class-based-weighted-fair-queueing-and-low-latency-queueing-tests/#comment-17

Just look at the very end of his simulation for the two results with two IOS versions.

[Joseph W. Doherty]

Actually, Cisco promised all (router?) QoS would eventually work much as it did on the 7500 some time back. Looks like with 12.4(20)T they have finally done so. I've worked with a couple of 7200s with -G2 processors running 12.4(20)T and had noticed some of the differences but not all of them. I hadn't read the release notes nor the white paper you've reference. (Thanks!)

[milan.kulik]

Hi Joseph,

I made some math excercises on formulas given within the article I found with following conclusions:

The IP Precence can twist the bandwidth guarantee considerably.

I played with maximum 256 flows in class-default. In worst case (256 flows with IP Prec=7) I noticed only 50% of bandwidth reserved by the bandwidth command used for user-defined classes was provided in fact.

But if only 128 Flows presented with IP Prec 7, then the bandwidth provided to the user-defined classes was OK.

When IP Prec 0 was set to all 256 flows in the class-default, the bandwidth provided to user-defined classes was always higher than the reserved values.

I'm not sure if the formulas are correct, I can't see how were derived from the SN formula used by the CBWFQ scheduler (packet lenght was ignored so far).

And it's also possible CBWFQ is calculating with IP Prec also for user-defind classes.

But my feeling here is:

If you set IP Precedence to 0 for the class-default flows (and that's possible while marking incoming packets), you can rely on CBWFQ to provide at least the bandwidth reserved for your user-defined classes even when your class-default is running FQ.

IMHO, Cisco should publish the algorithm to stop all these guessing discussions :-((

BR,

Milan

[blackladyJR]

N/A