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

[Peter Paluch]

Hello Adam,

To my best knowledge, a class using the priority command is both guaranteed and policed to the configured rate. Even if there is more capacity currently available, a priority class is policed to its configured rate, not extending into the unused capacity. So, a priority queue can not use extra bandwidth.

Classes configured with the bandwidth command are guaranteed their rate in moments of congestion. However, if there is extra capacity, these classes can also use the extra bandwidth as necessary.

Best regards,

Peter

[Tymofii Dmytrenko]

Great input, Peter.

I recently faced a problem with LLQ that was not explicitly policing my egress traffic, while I mistakenly thought that LLQ means guaranteed and limited BW.  As result, my service provider policed all excessive traffic and I had voice/video degradation. I have planned to perform the same testing to prove the logic but luckily found your comment.

It looks rational to me now. Cisco always states that LLQ and CBWFQ are only in effect when there's a congestion. No congestion = no queuing. No queuing = no drops (we tail drop, but there's no tail).

Thanks again.

Tim

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

You can insert an explicit policer within your LLQ class.  It will insure you don't exceed your bandwidth limit.

[Tymofii Dmytrenko]

Yes. I know that.

It won't help me anyway :) The only thing that can protect my voice and video in this case is a careful planning for BW allocation on the VC itself (configure correct MAX bitrate for the call). Also, a CAC may help... but this one, being a more proper solution, will require more time and efforts in our case.

[Jon Marshall]

Adam

This is a question that gets a number of different answers, the priority part of your question that is.

Quoting Peter -

To my best knowledge, a class using the priority command is both guaranteed and policed to the configured rate.

This can be interpreted a number of ways and that's the problem. From the Cisco QOS doc on this -

The queueing system imposes an important exception to this rule with a priority class. As noted above, the offered load of a priority class is metered by a traffic policer.  During congestion conditions, a priority class       cannot use any excess bandwidth.

They do seem to contradict each other and from memory when we have had these discussions before it is still not entirely clear.  So there are 2 possibilities when we have extra bandwidth -

1) priority queue cannot use it and is policed to it's configured limit

or

2) priority queue can use spare bandwidth if available and does not police it.

Either way, as Peter says the priority queue is guaranteed a certain amount of bandwidth. To me it would make sense that the priority queue could use additional bandwidth, although that additional bandwidth would not be priority queued as such.

The priority queue would only need to be policed during times of congestion so as to prevent the other queues being starved but there is no reason why it needs policing if there is additional bandwidth to use.

Edit - just to be clear i'm not saying my version is correct so perhaps a simple test would clarify.

Jon

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information  contained within this   posting without consideration and with the  reader's understanding that   there's no implied or expressed suitability  or fitness for any  purpose.  Information provided is for informational  purposes only and  should not  be construed as rendering professional  advice of any kind.  Usage of  this posting's information is solely at  reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

My understanding is the priority class implicit policer(s) only affects packets in the actual (singular) LLQ.  In other words, a priority class, in some situations, can use more bandwidth than it has been "allocated".  (NB: using an explicit policer can preclude that.)

[Jon Marshall]

Joseph

I have just asked for clarification in the Ask the Experts Catalyst QOS (although it's not strictly Catalyst related).

My understanding is similiar to yours. I think the LLQ can expand into the available bandwidth but that any additional bandwidth is not treated with priority.

I have also asked for clarification of when the LLQ is active. I recall reading that even if the link is not congested it is still important to be able to place VOIP packets on the wire in front of larger packets that may introduce too much delay. If this is the case then the LLQ must be active at all times. And that's why it's important to realise that any extra bandwidth the LLQ uses above it's guaranteed rate would not be treated with the same priority.

I say i recall reading it but i have no idea where i read it so i may be misremembering.

Jon

[Aileron88]

Jon,

Thanks for looking into this, I really appreciate your time.

With regards to the priority queue, I agree that it should be able to use more bandwidth BUT I can see an issue with this. If the PQ is using e.g 33% of the interface bandwidth and there is more additional bandwidth available and it uses it...but then other classes that are guaranteed a minimum bandwidth begin creating traffic and the interface becomes congested then the PQ would have to back off to it's maximum value. So the traffic that was 'bursting' above the PQs priority allocation would suffer, which could then lead to dropped voice/video calls.

So although it would make sense to be able to use the bandwidth that was available, at the same time it would make sense to not be able to use it. I guess it comes down to the fact that the priority queue bandwidth should be worked out well enough that you know what you're allowing through as priority.

I can see both sides of the matter, and I'm not sure which one I'd prefer! Ultimately allowing less through and guaranteeing service, or allowing more through but not guaranteeing service.

Thanks again for the help,

Adam

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Jon, the LLQ doesn't expand, it's strictly a question, I believe, whether its queue contains packets.

For example, you have a priority class set to 10% of a link, but the priority class traffic is actually offered at 50% of link capacity.  If there's an interpacket gap that allows each packet to be transmitted before the next arrives, the implicit policer never engages since the priority packets are not queued.  Each is immediately transmitted as it arrives.

Further assume another flow starts up, non-priority, and it takes 25% of link capacity.  If this traffic is paced such that it too is interleaved with the priority class traffic, we still obtain 50% link capacity (75% combined) for LLQ traffic although the implicit policer is set to 10%.  Again, nothing is queued; both traffic flows packets are transmitted immediately as they arrive.

Lastly assume the new flow increase its flow rate such that it now wants all the link capacity.  Now the priority class will be rate limited to 10% as its packets are queued, but its queued packets will be serviced before any of the other flow's packets (leaving that flow 90% of link capacity).

PS:

I've seen the above cause a small issue if you're running across a service provider that rate limits your priority traffic.  For priority traffic itself, it doesn't matter much whether you or your service provider drops the traffic, but it's often easier to see the drops on your equipment.  (I.e., one reason to use an explicit policer.)

[Jon Marshall]

Joseph

Jon, the LLQ doesn't expand, it's strictly a question, I believe, whether its queue contains packets

No, it doesn't, and if i said anything that gave that impression then apologies. I guess it was this sentence

I think the LLQ can expand into the available bandwidth but that any additional bandwidth is not treated with priority.

what i meant was that if there is spare bandwidth then the traffic that would be placed in the priority queue can use it. But that the additional bandwidth is not part of the LLQ ie. as i said above it is not treated with priority. So i think we are agreeing on that.

As for the other point about the LLQ being active all the time then perhaps i have misremembered and you generally have a better understanding of QOS intracacies than i do.

Like i said in one of my previous posts, it's good to have you back on these forums

Jon

[Jon Marshall]

All

Just got a response in Ask the Experts Catalyst QOS -(my questions in bold)

During times when there is additional bandwidth available can the priority queue use spare available bandwidth from the other queues ?

Yes it can. Infact unused bandwidth is distributed proportionately among all queues. However, if priority class data is eating up free bandwidth and the device gets congested,  the priority class traffic above the allocated bandwidth is discarded. This is true for both bandwidth and priority classes.

If a bandwidth or priority class should not exceed its allocated bandwidth during periods of no congestion, you can combine the priority command with the police command.

And if there is available bandwidth, which presumably means the link is not congested ?, does IOS still allocate packets into their configured queues.

When there is no congestion, the limits configured under the classes go fuzzy.  There is extra bandwidth and everybody gets a proportianal share of the extra bandwidth. With fluid queue boundaries, some packets may be using the extra (unused) portion of the bandwidth for that queue and IOS does not update the policy-map counters.

But even with no congestion is it not still important to make sure certain packets ie. VOIP do not get delayed due to larger non VOIP packets being sent ?

With sufficient bandwidth available, there is no need to buffer packets. I believe this rules out possibility of latency. I am not sure if there is any other way latency can be seen except when traffic is buffered before being transmitted on the wire.

My understanding was that the priority queue was still active even during non-congested times but that any additional bandwidth it used outside of it's guaranteed limit would not be treated as priority ?

Priority queue is active during non-congested times as in the traffic going to the priority queue gets more bandwidth than minimum gurantee. You are definitely correct with the fact that any additional bandwidth being used is non priority and can be confiscated when the link gets congested.

So the anwers seems to be yes it can use additional bandwidth. Adam this wouldn't starve any other queues because it is only using spare bandwidth. If congestion kicked in then the LLQ would be policed.

Joseph, the 3rd question would indeed backup what you were saying (not that i didn't trust you ). The last question is somewhat fuzzy but i think it also backups up what you were saying although i might post a follow up.

I am sure i read somewhere that VOIP packets can suffer even with no congestion but have no idea where i read that.

Jon

[Peter Paluch]

Jon,

Often it is explained that the policy-map configured on an interface actually kicks into action only if there is a backpressure from the interface, i.e. when its Tx ring fills over the preconfigured threshold. That could eventually explain these things that even a policed class could, under circumstances, go over its maximum bandwidth in cases with no congestion on the interface.

I would like to test this assumption. I don't know if I manage to do it today or during the next week, but I plan to perform a rather simple scenario: over 100Mbps FastEthernets on an 1841/2801/2811 routers, route an UDP flow of substantially slower bandwidth, say, 5-10 Mbps, and assign it to a priority queue. Then, configure the queue with the priority 1000 command. A small UDP flow like this one should not result in congestion of the FE interfaces. Yet, if I see the UDP flow being policed to 1Mbps then the implicit policer in the priority queue must kick in even with no congestion.

Best regards,

Peter

[Joseph W. Doherty]

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

Peter if you do find the time for a test like you describe, assuming the implicit LLQ policer does not rate limit, also try adding an explicit policer.  The former I wouldn't expect to engage; the latter I would expect to engage regardless of TX queue.

If you can, you might also try sending a 2nd UDP flow, non-LLQ, at 100 Mbps or better.  Here too I would expect implicit LLQ policer to engage.

[Jon Marshall]

Hi Peter

Yes would be interesting to see. I have been hitting the books on QOS to catch up on it again.

All the stuff i read suggests the priority queue only kicks in, like the other queues, when there is congestion which is what Shashank and Joseph were suggesting, so it looks like i definitely misremebered in terms of the LLQ being active all the time.

It's kind of catch 22 though. We are all talking about whether the priority queue can go above it's configured limit. But considering wihout congestion the queues don't become "active" as such then any traffic can use any bandwidth if it is available. So traffic marked as priority isn't really priority traffic if there is no congestion, it is simply just packets to be placed on the wire.

Only when there is congestion do the queues kick in and then in that instance obviously the policer would be relevant to stop the other queues being starved.

If your test proves that the LLQ is being policed even when there is no congestion then that suggests the LLQ is active all the time which goes against everything i have read today and what the others have said.

Will be interesting to see !

Jon