Are packets that exceed the QoS class-default dropped?

[yutashimamura2920]

QoS is configured on the IOS-XE SD-WAN Router currently in operation.
I checked the QoS statistics with show policy-map and found the following.
The bandwidth is 100 Mbps, and Queue 2 is allocated 34% bandwidth (31280 kbps).
If more traffic flows to Queue 2 than the bandwidth allocated to Queue 2 (31280 kbps), will the packet be dropped? Or, if there is another available bandwidth, will it be used(not drop)

[Kanan Huseynli · Accepted solution]

Hi,

only for LLQ (queue0 in SDWAN) policing is applied other than guaranteed bandwidth.

For other queues (where "bandwidth") keyword is used, you % shows minimum guaranteed bandwidth for that class (i.e queue) in case of congestion. When there is available bandwidth, specific queue can use more than configured %.

[yutashimamura2920]

The bandwidth is 100Mbps, but even when users are using only 30-40Mbps, packets appear to be dropped by class-default.
Is this expected behavior?

[Joseph W. Doherty]

---

@yutashimamura2920 wrote:

The bandwidth is 100Mbps, but even when users are using only 30-40Mbps, packets appear to be dropped by class-default.
Is this expected behavior?

---

Yes and no - or "it depends".

Drops are not uncommon with "bursty" traffic,.  Overall average utilization might not be anywhere near 100%, such as your 30 to 40%, but a transient burst can fill a queue which then begins to drop packets.

In your (SD-WAN generated?) policy, the class-default queue-limit of 130 is possibly a bit shallow for 100 Mbps, and I see WRED is also being used (which I generally recommend to be only be used by QoS experts) which its stats (if I'm reading them correctly) are showing tail drops (which a major goal of RED is to avoid).

[yutashimamura2920]

@Joseph W. Doherty 
Thank you very much!
I understand that burst traffic causes drops, but currently the Drop Counter is constantly going up.
This is a very strange phenomenon and I would like to know what the expected behavior is.

[Joseph W. Doherty]

Possibly what is happening is high frequency burst occurrences which overflow physical and/or logical queue sizes, which will cause rapidly increasing drop counts.

Such a case is not a strange phenomenon nor unexpected behavior when queuing resources are inadequate.

The usual "solution" is provide more bandwidth.

An alternate solution is better manage bandwidth using QoS.

BTW the two solution approaches are not mutually exclusive and, if fact, an optimal solution often requires both.

Also BTW, "optimal" is often much dependent on cost, and as LAN bandwidth is often much less expensive than WAN bandwidth "optimal" can be different for same issue on LAN vs. WAN.

[Joseph W. Doherty]

---

@Kanan Huseynli wrote:

only for LLQ (queue0 in SDWAN) policing is applied other than guaranteed bandwidth.

Assuming this SD-WAN LLQ works as it has traditionally, a LLQ's implicit policer only appears to active when LLQ packets are queued.  I.e. LLQ's implicit policer may permit LLQ to use up to 100% of the bandwidth.

---

@Kanan Huseynli wrote:

For other queues (where "bandwidth") keyword is used, you % shows minimum guaranteed bandwidth for that class (i.e queue) in case of congestion.

---

Well, that percentage, as an actual minimum, depends on how the policy was defined such that all 100% is allocated (in this policy it was).

Also, the minimum assumes all classes want to exceed their allocations and that you're using all bandwidth capacity.

The prior two statements might not be clear, so the following might help:

Given:

policy-map 100percentAllocated
class a
bandwidth percent 25
class b
bandwidth percent 25
class c
bandwidth percent 25
class d
bandwidth percent 25

The above class minimums would only be the actual minimums if all 4 classes were using that percentage or wanted more than that percentage.

But say classes C and D were currently inactive. Classes A and B minimums would be 50%.

Given:

policy-map 75percentAllocated
class a
bandwidth percent 25
class b
bandwidth percent 25
class c
bandwidth percent 25

If all the classes wanted all the bandwidth, the actual minimums would be 1/3 to each class, not 1/4.

What's actually happening, bandwidth allocations set ratios between the classes.

So, given:

policy-map 8percentAllocated
class a
bandwidth percent 2
class b
bandwidth percent 2
class c
bandwidth percent 2
class d
bandwidth percent 2

You would get pretty much the same results as the 100percentAllocated policy.

[Kanan Huseynli]

Hi @Joseph W. Doherty ,

you are right, about LLQ statement. It is active only when congestion happens.

Regarding "bandwidth" command, I don't see point that my statement does not match yours. I mentioned that it gets minimum % ("at least") during congestion, so indeed if some queues are inactive others can use more. With bandwidth percent 25, queue gets its minimum 25% depending on the condition it can be 50%, 75% or 90%.

[Joseph W. Doherty]

Ah, but look at my 75 or 8 percent allocated policies.  For those policies the minimum is more than the configured class allocated percentage.  Agree?

For the defined minimum to actually be the minimum, policy must allocate 100 percent.

So, where are statements differ, without additional qualifying information, yours may be incorrect.

I note this because if you look at a class with 25% and assume that's the actual minimum; it might not be.  Such would be the case for my 75% policy.

Then, although not shown in OP, another case where percentage might be misunderstood is for "remaining percent".

For example:

Policy-map 100percentAllocated

Class a

Bandwidth percent 50

Class b

Bandwidth remaining percent 75

Class c

Bandwidth remaining percent 25

So, what's the minimum for class C? 

Spoiler

12.5%

[Kanan Huseynli]

Hi @Joseph W. Doherty ,

for your above cases (where only 3x25% or 4x2%) rest-remaining % should be under class-default. When there is congestion and all these explicit queues and default queue are utilized, the first three queues get 25%, why it should be more than 25%, could you please clarify?

Suppose:

Class A matches IPs with Source subnetA - 25%
Class B matches IPs with Source subnetB - 25%
Class C matches IPs with Source subnetC - 25%

Rest traffic (traffic sources other than subnet A/B/C) will go to class-default  which has remaining % i.e last 25%.
Now, network is utilizing, all queues are used, Class A should get its 25% no more.

[Joseph W. Doherty]

Ah, class class-default.

The only wrinkle it brings is it's always present.  I didn't include it because I thought it might distract as it appears "different".

Those policies would still provide higher percentages, then configured, if all the traffic matched just the defined classes, i.e. no class-default traffic.  However, if you prefer, let me revamp those two policies as:

policy-map 75percentAllocated
 class a
  bandwidth percent 25
 class b
  bandwidth percent 25
 class class-default
  bandwidth percent 25

policy-map 8percentAllocated
 class a
  bandwidth percent 2
 class b
  bandwidth percent 2
 class c
  bandwidth percent 2
 class class-default
  bandwidth percent 2

So for the revised sample polices, 75% would actually guarantee 33 and 1/3 % to each class, while the 8% policy would guarantee 25% to each class.

@Kanan Huseynli agree?

BTW, when you do have an implicit class-default, or it's explicit, but its bandwidth allocation isn't configured, what allocation does it obtain?  I would assume it would acquire all the remaining (not allocated) bandwidth, but I don't recall ever seeing that clearly documented.  You can certainly configure less.  I do recall, since HQF CBWFQ, class-default requires a minimum of 1%.  Pre HQF CBWFQ, I recall, you could only allocate 75%, aggregate, to the other classes, unless you overrode that with another configuration statement (max-reserved-bandwidth), allowing you to optionally allocate 100% to the aggregate of the non-default classes.

If I've been unclear, basically I'm just mentioned when looking at class bandwidth allocations, the bandwidth percent (or kbps) might not be the actual value.  In the policies above, the guaranteed value is more than shown, and in my class remaining example (within a prior reply), the guarantee percentage is less than shown.  If you really need specific bandwidth guarantees, you should understand what a particular configuration will provide.

[Kanan Huseynli]

Hi, @Joseph W. Doherty ,

yes, I got your points. As I know, class default should use rest of available bandwidth, however not use. Also, will check docs and maybe some QoS based outputs can show actual % when no explicit % is configured for class default.

[yutashimamura2920]

Let me ask one more question.

I have implemented 92% policing settings at 100Mbps and have set 12M for Q0 (LLQ). I wonder if It can use only 80Mbps for the remaining Queue?
If LLQ is using only 2M, can the remaining Queue use 10M (remaining bandwidth in LLQ) + 80M for a total of 90M available?

[Joseph W. Doherty]

To your second question, by default, classes do not reserve unused bandwidth, so whatever LLQ is not using is available to other classes.

To your first question, would need clarification exactly what you're doing as policing does not queue traffic.  However, depending on policer's parameters, a physical interface could still queue, and could lead to CBWFQ queuing, but I'm unsure what the actual bandwidth distribution would be.

Understand, if you want sub rate queuing you shape, not police.