Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

QoS - WRED min/max threshold values

Dears

Would like your assistance please on how to determine best values for min/max threshold values that could  fit to network

I know probably I would do some tests/iteration till we reach best values however I have some queries please

- When to change default values ?

- How could I proceed/criteria of such tests ?

- What step values would I use in increasing/decreasing threshold values ?

Many Thanks

Regards

Sherif Ismail

Everyone's tags (6)
6 REPLIES
Super Bronze

Re: QoS - WRED min/max threshold values

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

Not the answer you're hoping for, but I would highly recommend you avoid using WRED unless you'll be using WRED to implement tiered threshold drop points (i.e. not really using WRED's min-max for same traffic early random drops).

WRED's "best values", for optimal early dropping usage, are not easily determined.  Conceptionally WRED is wonderful, but in practice it's very difficult to optimally use.  If you search the Internet, you'll find lots of RED "improved" variants.  Even Dr. Floyd, who defined RED, revised the suggested initial parameter settings.  (BTW, Cisco's defaults don't appear to agree with Dr. Floyd's recommendations, so I'm guessing Cisco too was trying to "improve" RED.)  Also, on some Cisco's platforms you'll might find FRED, a flow based RED, that's supposed to an improvement over WRED.

In practice, I've found WRED works better with many flows vs. few flows.  It also works better with similar traffic flows.  Its purpose really is to try to obtain best "goodput", but I've found per flow tail dropping (e.g. fair-queue) seems to work as well if not better in a wider range of situations without complex parameter settings.

QoS - WRED min/max threshold values

Dear Joseph
Many thanks for your reply/time

So If I understood correctly WRED would be recommended to use if we want to have different drop thresholds within same queue/class otherwise leave normal tail-drop as global synchronization effect can be neglected , correct ?

Thanks

Regards

Sherif Ismail

Super Bronze

Re: QoS - WRED min/max threshold values

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

Yes, WRED can be very useful if you're trying to provide different dropping thresholds for DSCP AFx1, AFx2 and AFx3.

Regarding class tail drop, what I'm suggesting is using fair-queue within the class so flow queues experience tail drop, not the whole class.  This avoids the global tail-drop synchronization effect and first drops packets from flows causing the congestion.  (One of the issues with WRED, it may drop packets that are not causing congestion.)

BTW, depending on the platform, you might be able to use both WRED and fair-queue within the same class.

QoS - WRED min/max threshold values

Hi Joseph

Yes this would be v.good idea especially that I want to apply WRED for internet traffic & don't know min/max thresholds values I should use

WRED with fair-queue is interesting but seems complex ... How does it works ?

||||

For sake of knowledge If we want to get optimum values for min/max thresholds then only way is to get packet generator and have defined steps from Cisco default values till we reach best results , correct ?

Many thanks for your assistance

Regards

Sherif Ismail

Super Bronze

Re: QoS - WRED min/max threshold values

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

WRED with fair-queue is interesting but seems complex ... How does it works ?

No, it's not much more complex.  You use fair-queue to share bandwidth between flows, and drop packets from flows with the most packets.  WRED is used to globally drop subclasses of traffic.

For example, consider four flows two telnet and two FTP.  One telnet flow is someone interactively typing, the other is listing the Internet routing table without pause.  One FTP flow is copying a small read-me file, another is copying a multigigabit data file.

If you only used fair-queue alone, it should only drop packets from the two bandwidth hungry flows, one FTP and one telnet, but if consider telnet always more important than FTP, tiered WRED can be used to drop all FTP traffic (hopefully) before fair-queue drops any of the bandwidth hungry telnet flow.  If there's still congestion, fair-queue should drop packets from the bandwidth hungry telnet flow before dropping any from the other telnet flow.

NB: Normally, you might have FTP and telnet in different classes, but the prior is just an example of how you can use the two together.

For sake of knowledge If we want to get optimum values for min/max thresholds then only way is to get packet generator and have defined steps from Cisco default values till we reach best results , correct ?

No, you can pre-compute what you want to use, but again, it's very "messy".

Forgetting WRED, what's the ideal buffer/queue size for a single FIFO queue?  You probably need to consider end-to-end latency.  You probably need to consider interface bandwidth.  You probably need to consider bandwidth to your egress interface.  You probably need to consider do you have mixed applications sharing the queue.  You probably need to consider expected traffic mix passing across the interface.  You probably need to consider each application's latency, jitter and drop requirements.

Once you understand how to use the prior for a single FIFO queue, for WRED, you then need to account for WRED uses a moving queue depth average, not an instantaneous depth.  You probably then need to account for how fast you want WRED to "track" the instantaneous value.  Once you believe you've figured out what MAX should be, MIN is usually okay to be MIN * 3 = MAX.  Drop rate at MAX - 1 is usually okay at 10%.

Once you can do all that, repeat for different markings (i.e. the W part of WRED) and you'll probably want to account for how different WRED values will now interact.

Some guidelines: you only want to apply WRED to rate responsive traffic (e.g. TCP) and for applications that don't require best possible performance (e.g. background large data transfers).  Also, you generally don't want to exceed about a 1% overall drop rate.

For additional fun, any of the above changes, new traffic mix, change in interface bandwidth, repeat above.

I've done lots of QoS, including lots of work with WRED.  My experience has been, it can be tuned, but the effort to do so, and the effort to maintain optimal settings, are rarely worth the effort except in some very special cases.

One thing I did often use if for, just to "count" different packet marking egressing an interface - i.e. no intentional drop management with it.

QoS - WRED min/max threshold values

Many thanks Joseph for your detailed answer

1123
Views
15
Helpful
6
Replies
CreatePlease login to create content