ā12-03-2013 04:08 AM - edited ā03-04-2019 09:44 PM
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
ā12-03-2013 06:03 AM
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.
ā12-10-2013 03:10 AM
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
ā12-10-2013 07:15 AM
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.
ā12-11-2013 09:00 AM
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
ā12-11-2013 10:49 AM
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.
ā12-15-2013 04:46 PM
Many thanks Joseph for your detailed answer
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide