Explanation needed - Random-detech ECN and policer

[lgordnier]

so I'm working with a partner and they have some very specific policy-maps that need to be transferred to non-cisco networking equipment. I'm looking to get a good understanding of the existing cisco map.  A portion of this map is utilizing random-detect ecn under a class - and then a policer within that class.

What exactly is this doing?

policy-map WAN-QoS

 Class RTP

  priority percent 55

 Class OFFICE2

  bandwidth percent 20

 class Traffic22

  bandwidth percent 5

  random-detect

  random-detect ecn

   police cir percent 40

   exceed-action drop

class class-default

 bandwidth percent 20

So my question is.... under class Traffic22 - we're giving 5%. what is the random-detect ecn policier at 40% doing?  is this 40% of that given 5%?

[Giuseppe Larosa · Accepted solution]

Hello LGordonier,

I agree that this is a strange configuration.

The policy-map is a form of LLQ  + CBWFQ  (priority command - > LLQ, bandwidth percent -> standard Queue in CBWFQ).

The LLQ-CBWFQ is elastic by default so the stated bandwidth percent 5 for class Traffic22 should be considered the minimum amount of BW guaranteed to this class even in congestion.

However, if there is no congestion or other classes are not using all of their BW Quotas the elastic capabilities of LLQ-CBWFQ on standard queues (not using priority ) allows them to go over their quota.

Here, I see an attempt to put an upper limit to BW usage by class Traffic22.

class Traffic22

  bandwidth percent 5

  random-detect

  random-detect ecn

   police cir percent 40

   exceed-action drop

I have found the following thread in Cisco Learning Network explaining what the random-detect ecn should do

https://learningnetwork.cisco.com/thread/104203?dtid=osscdc000283

And also I have found the command in QoS command reference for ASR 9000

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/qos/command/reference/b-qos-cr-asr9k/Congestion_Management_Commands.html?dtid=osscdc000283#wp3145726977

However, in both cases there is no mention of a policer attached to the random-detect ecn command.

So we can make the following interpretation:

the Traffic22 class is a standard queue in LLQ/CBWFQ with a minimal BW of 5 percent.

Traffic22 class uses WRED and WRED with ECN in case of congestion.

In case of congestion Traffic22 class is not allowed to get more then 40% of BW by the policer cir percent 40

exceed-action drop

However, it could be helpful to know what Cisco platform is this and what type of linecard is involved and the type and version of network operating system ( IOS, IOS XE or IOS XR)

Hope to help

Giuseppe

[lgordnier]

Thanks Giuseppe.

this would be for IOS and IOSXE as far as I know - but is used on multiple platforms for sure.

The policer is what is really throwing me through a loop  here. It would make sense if they're trying to achieve a maximum 40% traffic for class Traffic22 with the policer, I've just never seen it used like this before. So follow-up question to your response would be - does the policer do anything when there is congestion present? The class Traffic22 would still be limited to the previously configured 5%, correct?

[Giuseppe Larosa]

Hello,

my opinion is that policer should be triggered by wred when congestion is near to occurs.

So I see it as an upper limit of 40% of BW for Traffic Class Traffic22 in case of congestion.

Or the policer limits to 40% in all cases

Hope to help

Giuseppe

[lgordnier]

so assuming you're right, the 'bandwidth percent 5' statement is doing nothing?

[Giuseppe Larosa]

Hello,

the bandwidth percent 5 creates the standard queue that WRED with ECN will manage, so we cannot say it is doing nothing.

In addition if all classes are using their assigned percentages traffic will be at least  5% in case of congestion for Traffic class Traffic22.

It provides the lower limit not the upper limit that in this specific case is provided by the policer.

Hope to help

Giuseppe

[Joseph W. Doherty]

"the bandwidth percent 5 creates the standard queue that WRED with ECN will manage, so we cannot say it is doing nothing."

As a note, it's more the class that defines there will be a queue (or queues; i.e. FQ). The bandwidth statement defines it will be a single queue, while the bandwidth percentage defines this class's bandwidth allocation relative to other class queues (excluding LLQ). WRED does interact with the class queue although (I believe I've noticed) the class queue might still have FIFO drops independent of WRED.

[Giuseppe Larosa]

Hello Joseph,

>> The bandwidth statement defines it will be a single queue

This is what I wanted to point out in my answer.

>> WRED does interact with the class queue although (I believe I've noticed) the class queue might still have FIFO drops independent of WRED. 

tuning WRED thresholds and testing it is really difficult in my experience I have found it very challenging because we  were able to make tests with "dumb" traffic generators to create a background traffic and then we had put over it some smart traffic generators (that implements the TCP protocol actually like an iperf tool for example it was before tools like iperf were available) to create selected flows and then look for their throughput results.

In a context like this the variation in results repeating the tests is comparable to what you get when you change the WRED thresholds so it  was not possible to find clear benefits of one set of values over another (for the selective and random drop feature of WRED).

What I have seen in tests is that we cannot use arbitrary too high thresholds or packets are dropped on the linecard because it has finite resources (memory for I/O) even in Cisco 12000 linecards (that were the most powerful on those times to be compared to CRS-1 or CRS-3 now).

Hope to help

Giuseppe

[Joseph W. Doherty]

"tuning WRED thresholds and testing it is really difficult in my experience I have found it very challenging . . ."

It sure is! In other postings, I've often recommended against using WRED because of that, and other issues.

[Joseph W. Doherty]

"my opinion is that policer should be triggered by wred when congestion is near to occurs."

I'm of the opinion that the policed 40% is independent of WRED.

"So I see it as an upper limit of 40% of BW for Traffic Class Traffic22 in case of congestion."

Also of the opinion policer independent of congestion.

"Or the policer limits to 40% in all cases"

Agreed.

[Joseph W. Doherty]

"the Traffic22 class is a standard queue in LLQ/CBWFQ with a minimal BW of 5 percent."

Agreed but note this because policy map allocates 100%, not just because bandwidth defined as 5%. Also, the 5% would apply when all the other classes are getting their full allocations. (What actually happens, the bandwidth allocation value actually sets the ratio that class obtains vs. other classes. So, for example, if there was just also the class-default active, with its 20%, bandwidth would be allocated between the two classes in a ratio of 5:20 or 1:4.)

"Traffic22 class uses WRED and WRED with ECN in case of congestion."

Correct if ECN actually in operation, otherwise (from the references you've provided) WRED drops rather than mark. (Also keep in mind WRED can "do its thing" when there no actual congestion at the moment or conversely do nothing when there is actual congestion at the moment [this because WRED uses moving queue depth averages, not at the instant queue depths].)

"In case of congestion Traffic22 class is not allowed to get more then 40% of BW by the policer cir percent 40"

As also noted in my other post, congestion shouldn't matter to the policer.

[Joseph W. Doherty]

"So my question is.... under class Traffic22 - we're giving 5%. what is the random-detect ecn policier at 40% doing? is this 40% of that given 5%?"

NB: Giuseppe has well answered this, but I'll answer this too to provide an additional explanation.

The policer will drop all traffic in this class that exceeds 40% of the "assumed" bandwidth (to what the policy has been applied to, e.g. interface bandwidth statement or parent policy shaper).

WRED will ECN mark (for a ECN capable TCP flow) or drop packets based on its own moving average queued packets values, starting at its min threshold up to is max threshold. (NB: there's a linear drop chance percentage, zero at min, some max [default usually 10%] at max, 100% beyond max.)

The bandwidth percentage determine the bandwidth allocation relative to other active class queues, excluding LLQ. (Since 100% has been defined/allocated, if all other classes were active, and they all wanted all the bandwidth, this class should obtain 5% of the bandwidth.)

BTW, not knowing what traffic is in Traffic22 class, and it being a "ordinary" bandwidth class, unclear why it's policed. Using ECN is a bit unusual too. Also the LLQ class is an unusually high percentage.