Campus QoS part 2- Ingress Queuing and Scheduling

Introduction

This is the second posting that discusses the QoS aspects of the Catalyst 3750- the first part can be found here: “Campus QoS- part 1- classification and marking on the Catalyst 3750”.

In this article we will focus on Ingress Queuing and Scheduling. Congestion on the ingress side of the switch is far less likely to occur than on the egress side since the throughput of the internal ring of the switch is likely to be far greater than the aggregate rate at which traffic is being received. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nonetheless, ingress queuing and scheduling could be a factor in specific instances where there are speed mismatches and also at points of aggregation in the distribution and core layer.

COS/DSCP Queue Maps

The first step post classification and marking is mapping incoming traffic to specific queues. There are two queues on the ingress side (versus 4 on the egress). This mapping is done based on the layer 2 (COS) or layer 3 (IPP or DSCP) marking. When mls qos has been enabled on the switch the following map tables are used to determine which traffic is placed into which ingress queue.

 

 

 

 

 

 

Which input-q mapping is used depends on whether the layer 2 or layer 3 marking of the incoming traffic has been trusted (or marked by the switch in the service-policy). If you have used “mls qos trust cos” on the receiving interface then the cos-input-q table is used. In all likelihood the layer 2 and layer 3 map tables should be equivalent. Whenever layer 2 is trusted, the layer 3 is built from the layer 2 using cos-dscp-map tables as shown below:

 

 

 

 

 

 

 

It therefore makes sense (in this instance) that COS 0, 1, 2, 3, 4, 5, 6, 7 input-q maps should mimic DSCP 0, 8, 16, 24, 32, 40, 48, 56.

Whilst on the subject of cos-dscp maps, let’s take a look at what the AutoQos macro does for us.

 

 

 

 

Having issued the above command within one or more interfaces, we will take another look at the cos-input-q, dscp-input-q and cos-dscp map tables.

 

 

 

 

 

 

 

By looking above the first thing to point out is that COS 5 no longer maps to DSCP CS5 but rather EF (46). I would expect COS 5 input-q and DSCP 46 input-q maps to be equivalent.

 

 

 

 

 

 

Looking at the cos-input-q maps above we can see COS 3 (our VOIP control) and COS 5 (Real Time Media) maps to Q2 Threshold profile 3 (Q2T3). This is indeed reflected in the dscp-input-q maps (VOIP control is CS3 and VOIP media is EF or in decimal 24/46).

 

 

 

 

 

 

 

 

 

 

 

 

Weighted Tail Drop

Before talking about the threshold values, let’s take a quick look at the properties of the two queues on the ingress side. The default buffer size, thresholds and bandwidth (we’ll come to thresholds and bandwidth in a second so for the time being let’s focus on buffer size) is shown below:

 

 

 

 

 

 

 

 

The buffers that are allocated to each interface are divided 90:10 between Q1:Q2. In other words Q1 is a lot bigger than Q2! This makes sense since by default the vast majority of our traffic is placed into Q1.

When AutoQoS has been run let’s take a look at how this changes:

 

 

 

 

 

 

 

 

 

We can see the buffers are divided up two thirds: one third. More traffic utilizes Q2 when AutoQoS has been invoked.

Up to now we have shown certain types of traffic are placed into Q1 and certain types of traffic are placed into Q2. In the context of VOIP, our control and media traffic is placed into Q2. This mapping of traffic into specific queues is either based on layer 2 or 3 markings depending on what was used during classification and marking. We have also shown the sizes of the two queues can be manipulated.

Upon closed inspection you can see in the dscp/cos-input-q maps that we assign specific COS/DSCP values a Queue # as well as a Threshold #. The Threshold is the percentage of how full a particular queue is. When we assign a COS/DSCP value to a Q#T# we are saying that the frame will only be placed into the Q so long as it is not already occupied up to a certain percentage, This certain percentage is what T# is.

So for example, going back to dscp-input-q maps from earlier (after AutoQoS has done its magic):

 

 

 

 

 

 

 

 

 

You can see that incoming traffic marked with DSCP value CS1 (8) which is typically used for Scavenger class traffic (such as Microsoft Automatic updates;) is going to be placed into input Q1 so long as Q1 is not full beyond what Threshold 1 is set to.

 

 

 

 

 

 

 

 

 

Threshold 1 has been set to 8 percent. So incoming traffic with DSCP 8 will be placed into Q1 so long as Q1 is not more than 8% full. Whilst Q1 is 8% full (or more) then all frames with DSCP 8 (on this receiving interface) will be dropped.

Compare this with DSCP 0 which is placed into Q1T3.  T3 is not configurable and is an implicit 100%. This means that incoming traffic with DSCP 0 will be placed into Q1 unless it is totally full. And remember Q1 is (post AutoQoS) assigned 67% of the buffers.

So you can see that even though DSCP 0 and DSCP 8 are both being placed into input Q1, DSCP 0 traffic (Best Effort) has more importance since this type of traffic can be buffered should there be a congested shared bus. Contrast this with our Scavenger class traffic which can only be buffered up to a certain point (8% of the 67% allocated to Q1) before it is dropped. This is done so that our Scavenger class traffic cannot be the cause of congestion- aka congestion avoidance.

Scheduling

The last thing we are going to talk about is the algorithm for de-queuing which is otherwise known as scheduling. In the context of the input side of the switch, bandwidth represents the amount of traffic we can place onto the internal ring of the switch. This is finite. If both Q1 and Q2 are occupied then the composition of the traffic that is taken from Q1 and Q2 and placed onto the ring is subject to the configuration of the shared round robin scheduler. In the example below 90% of the traffic being placed onto the ring is taken from Q1 and 10% is taken from Q2 (with a small caveat to follow!). So let’s just make up some numbers and say that during every transmit interval we are able to place 1000 Ethernet frames onto the ring and both Q1 and Q2 are non-idle to the point where there are more than 1000 Ethernet frames in both queues, then 900 frames will be taken from Q1 and 100 frames will be taken from Q2. The bandwidth 90:10 is actually a weight not a percentage but since 90+10 = 100 it is in effect become a percentage. However we could have coinfigured 9:1 or 18:2, etc, etc to achieve the same thing.

 

 

 

 

 

 

 

The significance of shared round robin is important to understand- shared implies that if a particular queue does not require the configured bandwidth then this bandwidth can be released and shared by other queues. Going back to our earlier example- if Q1 is idle and Q2 has more than 1000 frames, then the SRR scheduler will apportion the bandwidth that has been assigned to Q1 to Q2 and thus Q2 receives 100% of the bandwidth. You can think of shared round robin as defining a minimum bandwidth guarantee when all queues are congested. However, unlike it’s sibling shaped round robin (used on the egress side), there is no maximum bandwidth defined using shared round robin. The maximum is 100% of the interface bandwidth.

Back to the caveat mentioned in the above discussion. Notice the following line that is highlighted below:

 

 

 

 

 

 

 

 

 

 

 

There is an additional consideration when considering ingress bandwidth. 10% of the bandwidth has been assigned as priority bandwidth to Q2 and the remaining 90% is shared according to the weighting defined above (90:10). So back to our example: 1000 frames every transmit interval- 10% comes from Q2 (100 frames). This is guaranteed to be placed onto the ring even if the ring is over-subscribed. That is what we mean by priority bandwidth (as opposed to a strict priority queue which we will talk about on the egress side). The remainder of the bandwidth that is placed onto the ring is not guaranteed and will be buffered in the queues should the ring be congested. This non-priority bandwidth is split according to the weighting 90:10. So the amount of traffic taken from Q2 is 10% of 1000 frames + 10% of 900 frames = 190 frames. The amount of traffic taken from Q1 is 90% of 900 frames = 810 frames. It should be mentioned again that all bandwidth can be shared if a particular queue is idle- this is not affected by the priority bandwidth.

Only one queue can be assigned up to 40% of ingress priority bandwidth- the default is 10% to Q2. This can be changed- in the example below we are assigned 40% to Q1.

 

 

That’s about it for now- look out for part 3 which will talk about egress queuing and scheduling.

Vik Malhi
Instructor, IPexpert Inc

Campus QoS part 2- Ingress Queuing and Scheduling, 5.0 out of 5 based on 4 ratings

Tags: 3750 qos, CCIE, ccie qos, ccie voice, cos-dscp, cos-input, dscp-input, priority queue, shared round robin, srr