cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
320
Views
0
Helpful
2
Replies

Catalyst 6500?2Q2T Queuing and Dropping

kfarrington
Level 3
Level 3

All,

I am still a little confused as to the point of txq buffer tuning.

1. Why do we need to assign a percentage of the 128KB for each queue? As we use wrr for queue transmission?

So would it be correct that 30% of 128KB (38.4KB) is for Q1 and 70% (89.6KB) is for Q2 and this is ONLY for storing packets in, which in theory should not happen often?

2. Please see below :- from the 6500 qos document http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a008049b062.pdf

"For example, if Q1 is to service Scavenger/Bulk (CoS 1) and Best Effort (CoS 0) traffic, then assigning

30% of the buffer space to the first queue is adequate; the remaining 70% can be assigned to Q2.

The WRR weights can be set to the same ratio of 30:70 for servicing Q1:Q2."

My question is: that if most of your traffic is going to be in Q1 with higher priority traffic in Q2, would it not be better to leave the Q1 with more buffer space as Q2 whill be serviced more freqently? Thus more packets would need to be buffered in Q1 than there would need to be buffered in Q2?

I am a little confused.

Many thx,

Ken

1 Accepted Solution

Accepted Solutions

andrew.burns
Level 7
Level 7

Hi,

It's correct that a receive queue probably won't fill up much (unless the backplane is congested) but transmit queues, especially uplinks, are almost guaranteed to be oversubscribed and will regularly overflow the transmit queues and drop packets (unless you don't have very much traffic).

If we're implementing qos then by definition we have some traffic that is more important than others - and it's this "less important" traffic that we want to drop packets from - not our more important traffic. So, one of the tricks to qos is correctly sizing the queues to match your traffic patterns which takes some time and effort (netflow is very useful for this). Say you only have two apps and app1 takes up 80% of the bandwidth and app2 takes up 20%. Assuming you assign app1 to Q1 and app2 to Q2 then the most efficient queue allocation is 80% to Q1 and 20% to Q2. Remember, that's just for queue efficiency (minimising unecessary drops) - what really controls qos behaviour is the wrr weights. If the wrr weights are 50:50 then you don't have any qos as both apps get the same treatment. If the queues are incorrectly sized then you'll be getting unecesssary drops in the queues - the trick is to make Q1 as big as you can without pushing the drops into Q2. As soon as Q2 starts getting drops then either the txq-ratios are incorrectly sized or the wrr weights are wrong. (Of course, in the real world you never get perfection - if the uplink is too heavily over-subscribed you'll get drops in higher higher queues no matter what you do.)

Cisco recommend that you estimate the queue sizes first, based on your local traffic proportions, and only modify the queues sizes if the wrr values don't stop the drops in Q2. What you're after is all drops in Q1, and the trick is to find the combination of wrr weights/queue lengths that give you that.

The document you link to is the SRND for QoS which might not be appropriate for your environment, i.e. if you're not implementing a bulk/scavenger class then the values given will be way off. (The ratio of 30%/70% to Q1/Q2 doesn't make sense without a scavenger class.)

HTH

Andrew.

View solution in original post

2 Replies 2

andrew.burns
Level 7
Level 7

Hi,

It's correct that a receive queue probably won't fill up much (unless the backplane is congested) but transmit queues, especially uplinks, are almost guaranteed to be oversubscribed and will regularly overflow the transmit queues and drop packets (unless you don't have very much traffic).

If we're implementing qos then by definition we have some traffic that is more important than others - and it's this "less important" traffic that we want to drop packets from - not our more important traffic. So, one of the tricks to qos is correctly sizing the queues to match your traffic patterns which takes some time and effort (netflow is very useful for this). Say you only have two apps and app1 takes up 80% of the bandwidth and app2 takes up 20%. Assuming you assign app1 to Q1 and app2 to Q2 then the most efficient queue allocation is 80% to Q1 and 20% to Q2. Remember, that's just for queue efficiency (minimising unecessary drops) - what really controls qos behaviour is the wrr weights. If the wrr weights are 50:50 then you don't have any qos as both apps get the same treatment. If the queues are incorrectly sized then you'll be getting unecesssary drops in the queues - the trick is to make Q1 as big as you can without pushing the drops into Q2. As soon as Q2 starts getting drops then either the txq-ratios are incorrectly sized or the wrr weights are wrong. (Of course, in the real world you never get perfection - if the uplink is too heavily over-subscribed you'll get drops in higher higher queues no matter what you do.)

Cisco recommend that you estimate the queue sizes first, based on your local traffic proportions, and only modify the queues sizes if the wrr values don't stop the drops in Q2. What you're after is all drops in Q1, and the trick is to find the combination of wrr weights/queue lengths that give you that.

The document you link to is the SRND for QoS which might not be appropriate for your environment, i.e. if you're not implementing a bulk/scavenger class then the values given will be way off. (The ratio of 30%/70% to Q1/Q2 doesn't make sense without a scavenger class.)

HTH

Andrew.

Andrew, That is a very clear and fantastic response. That has made sense and thankyou for this.

Best regards,

Ken

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco