Your OP noted "I am unexpereienced with QoS." From you last post reply to mine, yes, I would tend to agree with you. ;)
It's a bit unclear why you're looking for confirmation and/or critique of your policy, such as knowing your classification and queuing strategy is already correct. (I suspect it isn't, but it's possible it is, QoS policies are tailored for specific results, and I don't know all your criteria. Possibly you're also trying to work within the framework of whatever [usually inadequate, IMO - laugh] QoS support your MPLS vendor supports.)
I suspect you've read somewhere FQ is used for congestion management, but it, and RED, can both be used to manage congestion. Neither truly avoids congestion, because both drop packets (excluding RED that can set the congestion bit) when there's congestion, and for traffic that "slows" its transmission rate when drops are detected, like TCP, both can avoid massive congestion. However, WRED is more likely to still have global (i.e. within a class) sync issues (you understand it tail drops all when you go past its max value, right?) and WRED might also be more likely to cause TCP starvation, by default, if TCP and non-TCP traffic are subjected to the same WRED processing.
As to FQ should be configured in class default, where did you read that? Something dated? Perhaps in pre-HQF documentation, which supported FQ, actually WFQ, only in class-default. One of the nicest feature improvements in HQF was support of FQ in any bandwidth class.
You've taken much interest in WRED. I don't blame you, I too drank that kool-aid years ago. However, trying to get WRED to work optimally lead me to read much about it, starting with Dr. Floyd's original paper on it. What's immediately telling, was Dr. Floyd needing to "fix" some of REDs parameters almost immediately when it was tried. Since then, you'll find lots and lots of RED variants to "improve" it. It does make one wonder, why there are so many "improved" variants of RED. (Oh, and BTW, the Cisco implementation usually don't seem to follow Dr. Floyd's parameter recommendations.)
In the usual Cisco implementation, WRED tails drops, where RED appears to work better if it head drops. This because tail drops delay the sender from detecting the drop, i.e negating much of the point of "early" dropping.
(Oh, one interesting feature of RED is how it can drop received packets when the interface queue is actually empty or conversely not drop packets when there's a massive queue. Both due to RED's use of a moving average of computed queue depth. i.e. it's really a feature, and there's a reason for it, but it's interesting just the same.)
Another issue with the usual Cisco implementation (excluding the Cisco FRED variant), it's not flow aware, i.e. it can drop a packet from a flow that not contributing to the congestion.
What have you read about setting WRED parameters? Are you going to use the Cisco defaults (as you didn't post any)? You're aware how different platforms might assign completely different parameters for the same link? Again, such make one wonder about choice of these parameters, if even Cisco is inconsistent.
The problem with the typical Cisco WRED, like you'll find on a 3900, it's difficult to get it to work optimally. The issues, noted above, especially lack of targeting flows causing congestion, and it tail dropping, I'm found, it's not really better than FQ tail dropping individual flows, the ones with congestion. Additionally, FQ, protects light bandwidth usage flows from being delayed by heavy bandwidth usage flows. I.e. generally you obtain a much better network application experience.
I might also mention, for about 10 years, I developed QoS for a large international software development company, supporting all kinds of WAN links, such as leased lines, frame-relay, ATM, MPLS and Internet VPN. I like to brag we had some offices where our links ran at 100%, all the time, during business hours, yet we had everything from VoIP, video conferencing, video streaming, interactive application (including, like you note, some very sensitive to delay and/or packet loss) to backups on those links - QoS making it all possible. I.e. Let's say I have a bit of experience of what really works, or not, in the real world.
Also BTW, Cisco's typical WRED can be easily used for tiered dropping.
class•