Re: QoS on C3750 - ssr-queue bandwith share & shape

parisdooz12 · ‎04-04-2012

Hi,

something is not clear for me about output queuing on C3750.

1) Imagine I configure an interfac as following:

Switch(config)# interface gigabitethernet1/0/1

Switch(config-if)# srr-queue bandwidth shape 25 0 0 0

Switch(config-if)# srr-queue bandwidth share 30 20 25 25


If I understand well, it means:
- According to the 1st line: Queue #1 has max 1/25 of the bandwidth. However, it doesn't mean that it is a priority-que
- According to the 2d line: the 1st value (=30) is ignored as shape take precedence on "share". Queues #2,#3,#4 are shared.
=> Question #1: what are the ratios between the different queues in this case? 25% for queue 1, but what for queues #2,#3,#4?

2) I now I add command priority-queue:
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# srr-queue bandwidth shape 25 0 0 0
 Switch(config-if)# srr-queue bandwidth share 30 20 25 25
Switch(config-if)# srr-queue priority-queue out
If I understand well, it means:
- Queue #1 act now as high priority-queue

- Queue #1 still have a maximum of 25% of the bandwidth?



=> Question #2:is it the correct interpretation, and do "srr-queue priority-queue out" always apply to queue#1?

Thanks by advance for your help!

D.

Joseph W. Doherty · ‎04-04-2012

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

#1 ratios are: 6:4:5:5 NB: queue 1's shared 30 isn't ignored, it's still used in bandwidth ratio calculations but queue 1, because of the shape command, won't be allowed to exceed 1/25.

{correction}

#1 would be 4% (1/25) for queue 1 and queues 2 through 4 share the available bandwidth in ratios 4:5:5.

#2 no, queue 1, with PQ, has 100% guarantee. With PQ ratios change to 4:5:5 for queues 2 through 4, i.e. for bandwidth not being used by queue 1.

parisdooz12 · ‎04-04-2012

To be sure to well understand:

- for #1, in my example, it means that queue#1 has a minimal bandwidth of 25 and a max of 30?

- for #2: what does limit the trafic in queue #1, to protect other queues from starvation (I mean, what is the equivalent of router policing rule applied on the PQ?)

Joseph W. Doherty · ‎04-04-2012

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

- for #1, in my example, it means that queue#1 has a minimal bandwidth of 25 and a max of 30?

- for #2: what does limit the trafic in queue #1, to protect other queues from starvation (I mean, what is the equivalent of router policing rule applied on the PQ?)

#1 neither, it has a maximum bandwidth of 4% (1/25). The 30 is used as part of scheduling ratios.

#2 nothing, works like PQ on routers. To preclude starvation, you could set a very high share ratio and then set a shape cap, e.g.:

srr-queue bandwidth shape 3 0 0 0

srr-queue bandwidth shape 0 0 0 0 

srr-queue bandwidth share 97 1 1 1
srr-queue bandwidth share 255 1 1 1

parisdooz12 · ‎04-04-2012

Sorry, but it is still not totally clear for me:

#1: ok for 4% max. 30 for queue#1 in the "share" is used for scheduling ratios, but it means that 30% of time is for 1st queue, which in the same time is policed to 4% of the bandwdith ... so there is a waste of time lost for queue 1 (in the prvious example) ..? Your example for #2 seems to me even more strange (if you had wroten for exemple srr-queue bandwidth share 4 32 32 32, ok, I would understand)

I guess I toally misunderstand the "bandwidth share"! :-(

Joseph W. Doherty · ‎04-04-2012

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

Oops! I was mistaken about share weight being used, as noted by Peter.

I've added corrections to my prior posts. If you're still confused, please let me know.

parisdooz12 · ‎04-05-2012

Hi Joseph,

reading deapier at the documentation, I think I have finally the solution, which is: it is not possible to prevent from starvation through the egress queuing commands.

What happens indeed when configuring "priority-queue out" is that "srr-queue bandwidth share" AND

"srr-queue bandwidth shape" are ignored.

Source:

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml:

"When you configure this command, the SRR weight and queue size ratios are affected because there

is one fewer queue participating in SRR. This means that weight1 in the srr−queue bandwidth

shape or the srr−queue bandwidth share command is ignored (not used in the ratio calculation)"

And after having readen quite all possible doc or forum: I found no solution!

Joseph W. Doherty · ‎04-05-2012

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

reading deapier at the documentation, I think I have finally the solution, which is: it is not possible to prevent from starvation through the egress queuing commands.

What happens indeed when configuring "priority-queue out" is that "srr-queue bandwidth share" AND

"srr-queue bandwidth shape" are ignored.

Source:

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml:

"When you configure this command, the SRR weight and queue size ratios are affected because there

is one fewer queue participating in SRR. This means that weight1 in the srr−queue bandwidth

shape or the srr−queue bandwidth share command is ignored (not used in the ratio calculation)"

And after having readen quite all possible doc or forum: I found no solution!

Yes, that's correct how PQ works, as also noted in my 1st reply to question #2, i.e. PQ gets 100% (if it wants it).

However, one possible solution is given in my 2nd (corrected) reply, which is to use share mode on all queues but give one queue very high priority relative to all the other queues. This will give it PQ like dequeuing but preclude this queue from taking all the bandwidth. (Normally, traffic that's allowed into a PQ should be a "known" quantity, i.e. you should not the maximum amount of bandwidth you need to provision for it.)

Peter Paluch · ‎04-04-2012

Joseph,

#1 ratios are: 6:4:5:5  NB: queue 1's shared 30 isn't ignored, it's  still used in bandwidth ratio calculations but queue 1, because of the  shape command, won't be allowed to exceed 1/25.

Hmm... Documents state otherwise: if a queue is shaped, its shared weight is ignored when computing weights and ratios for shared queues. With this approach, the shared queue weight ratios would be 20/70, 25/70, 25/70 = 28.57%, 35.71%, 35.71%. If the shaped queue weight was not ignored, the shared queue weight ratios would be 20%, 25%, 25%.

I am basing my opinion on the following document:

https://supportforums.cisco.com/docs/DOC-8093#_Toc191205663

It is also corroborated by the 3750 Command Reference at

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_58_se/command/reference/cli3.html#wp1947494

Examples

This example shows how to configure the queues for the same port for both shaping and sharing. Because the weight ratios for queues 2, 3, and 4 are set to 0, these queues operate in shared mode. The bandwidth weight for queue 1 is 1/8, which is 12.5 percent. Queue 1 is guaranteed this bandwidth and limited to it; it does not extend its slot to the other queues even if the other queues have no traffic and are idle. Queues 2, 3, and 4 are in shared mode, and the setting for queue 1 is ignored. The bandwidth ratio allocated for the queues in shared mode is 4/(4+4+4), which is 33 percent:

Switch(config)# interface gigabitethernet2/0/1

Switch(config-if)# srr-queue bandwidth shape 8 0 0 0

Switch(config-if)# srr-queue bandwidth share 4 4 4 4

Best regards,

Peter

Joseph W. Doherty · ‎04-04-2012

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, thank you for the correction!!!

This morning, I was looking at other Cisco documentation, and it wasn't as clear. If you examine the diagram at: http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml#def-config, it shows a default configuration using 4% for Q1, and 25% for queues 2 through 4. I also noticed above it: "All four queues participate in the SRR unless the priority queue is enabled . . .", which doesn't explictly mention excluding shape values, as does your documentation.

Your doc reference best explains this but even it can be confusing or incorrect. For example:

Its possible to over allocate available egress bandwidth with a combination of shaped and shared weights. Oversubscribing the available egress bandwidth is legal, and permitted by IOS. If the switch is configued in such a way, then shaped tx queues will take priority over shared tx queues. If tx queue 1 & 2 are configured to shape at 33% of the egress bandwidth, and tx queues 3 & 4 are configured to share a 25% each, then what happens to the guarantee for the shared tx queues. This guarantee cannot be met. More than 100% of the available egress bandwidth has been configured. Here’s how the interface has been configured:

Switch(config)#int gi1/0/26

Switch(config-if)#srr-queue bandwidth shape 3 3 0 0

Switch-38(config-if)#srr-queue bandwidth share 1 1 25 25

When this port becomes completely over subscribed on all tx queues, the tx queues will drain like this:

- tx queue 1 and 2 output roughly 33% each

- tx queue 3 and 4 output roughly 15% each

In the above, the 25s are not percentages, they are weights (same point of confusion in the document I looked at too). If they are understood to divide remaining (non-shaped) bandwidth 1:1, and total shaped bandwidth is 66.7%, then queues 3 and 4 would equally divide the non-shaped 33%.