LLQ Bandwidth Provisioning

[Aileron88]

Hi everyone,

When provisioning bandwidth for the priority queue using the 'priority' command, is this an ABSOLUTE maximum that the priority queue can get? So say if none of the other bandwidth is being used, can the priority queue use this extra bandwidth?

In the same vein, if you assign a class say 30% bandwidth is this a minumum guarentee BUT the class can use whatevers free at that moment? If I had another two classes with 10% each, could the class with 30% use this 10% if it's not being used?

Thanks,

Adam

[jox198501]

hi joseph

can you pls explain me what is "the rate of the queue" ?

"IOS LLQ accepts two configuration parameters for a priority queue: the rate of the queue expressed in KB per second, and an optional burst size configured in bytes"

is it the rate of, lets say, video packets that are prioritized (marked with additional data fields due to qos, so that rate is higher then regular video stream without qos ?)

i can not connect terms queue and rate, because i undesrtand queue as a buffer wich stores packets.

thanks in advance.

[Aileron88]

Appreciate you looking into this guys. Peter I'd be very interested to read your results. I'm in the process of setting up a home lab so once this is done I too will run some tests on this.

Can I just confirm that IOS realises congestion from the fullness of the Tx Ring?

Thanks,

Adam

[Peter Paluch]

Gentlemen,

Thank you for your support and interested. I have the experiment planned on my ToDo list for the nearest Monday or Tuesday, and will update this thread as soon as I have any relevant output.

Should I by any means forget to post the results here by Tuesday, please don't hesitate to give me a friendly kick in a private message or via e-mail

Best regards,

Peter

[Peter Paluch]

Gentlemen,

I have performed the tests. In short: Joseph is correct, as was to be expected I wanted to publish all the results directly here but for some inexplicable reason, the CSC refuses to post the content, telling me that it can not be displayed. Probably some strange special characters made it into the text and I cannot see them. Therefore, I am attaching the results in a PDF file. Sorry for the inconvenience... I've spent more that 30 minutes forcing the CSC to accept my post but it is apparently running its own version of artificial intelligence... and beats mine

Best regards,

Peter

[rrsstefano]

Hi Peter and all,

I want to resume this interesting discussion to ask you about how is managed , during congestion, UNUSUED priority queue bandwidth; for example if it  was congestion BUT my voice flows are not present, other classes CAN use extra bandwidth from the PQ ?

Thanks a lot for all suggestion!!

[Joseph W. Doherty]

Yes.

[rrsstefano]

OK....and viceversa during congestion, if congestion is caused by best effort traffic ( class-default )

and other reserved classes ( badwitdh classes ) are not claiming all bandwidth...priory traffic can use extra bandwidth so reducing and dropping class-default traffic?

Thanks a lot

[Joseph W. Doherty]

Yes and no (for the converse).

LLQ has an implict policer which impacts traffic that's queue in the LLQ. Interface congestion, caused by other classes, will likely cause LLQ to queue, and if it does, the implicit policer comes into play. I.e. at such time you cannot obtain more bandwidth for LLQ traffic than you've provisioned for it.

If the interface is not congested, then LLQ can use more bandwidth than it's provisioned for.

NB: The above was true for ISRs some time back (see Peter Paluch's test results in this thread). Cannot say with 100% sureness, that it applies to latest platforms.

[rrsstefano]

Thanks Joseph!!

My question arised because looking at very interesting Peter's test I see that on test made overloading the line ( test 3 )

the rate obtained on the PQ is about 2Mbps while the priority set to 1 Mbps...so I was in doubt how to

consider it

It seems go over the policer limit

Thanks a lot

[Joseph W. Doherty]

Yes, PQ can exceed its implicit policer, again packets are being queue.

For example, if you have LLQ set to 1 Mbps, you may be able to transmit up to interface rate, but the moment you try to exceed the interface rate, packets will queue and that's when the LLQ implicit policer should rate limit traffic.

[rrsstefano]

Yes...but it seems to go over policer limit just during congestion...if I was interpreting statistics reported correctly...I'm a bit confused....

queue stats for all priority classes:

Queueing

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/209052/0

(pkts output/bytes output) 90949/50385746

Class-map: cm_PRIO (match-all)

300001 packets, 166200554 bytes

5 minute offered rate 2694000 bps, drop rate 1765000 bps

Match: access-group name acl_PRIO

Priority: 1000 kbps, burst bytes 25000, b/w exceed drops: 209052

Class-map: class-default (match-any)

900084 packets, 498607508 bytes

5 minute offered rate 7216000 bps, drop rate 2537000 bps

Match: any

queue limit 64 packets

(queue depth/total drops/no-buffer drops) 0/311864/0

(pkts output/bytes output) 588220/325839242

Thanks

[Joseph W. Doherty]

What from your stats, do you believe, tells you the LLQ policer is allowing overrate during congestion?

[rrsstefano]

Hi joseph...my fault...offered rate is not the rate on the wire...I have to subtract the drop rate

I misinterpreted the counter...now is clear

Thanks

[Joseph W. Doherty]

Yup.