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.
