Elliot, your suggested QoS policy-map looks to be much like "the book" would recommend, but in my, not so humble opinion (laugh), I think "the book" is (cough, cough) less than optimal.
My "generic" policy is:
policy-map Generic
class real-time
priority percent 35 !or 40
class foreground !or priority
bandwidth remaining percent 81
fair-queue
class background !or scavenger
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue
How do you use the above. Well, you start with everything in class-default, unless you have a good reason to direct traffic to another class. As you note, not all platforms support all QoS features, and for the above, things like class queue sizes and/or FQ sizes might need to be tweaked (if platform supports).
The foreground class should, generally, only have light bandwidth usage flows in it, those that really deserve/need better treatment. For a "poster child" example, something like Telnet or SSH might use this class (but you got to watch for exceptions to the norm - in the past, my class-maps would dynamically chose policy class using some form of dynamic bandwidth usage beyond just the kind of traffic - you can also stub your toe on things like SCP and SSH "look alike").
(In fact, with so much done within NetBEUI and HTTP [and now HTTPS] it's difficult to "type" traffic. So, FQ, at least, generally round-robins flows. However, sometimes you can also [additionally] classify based on actual bandwidth usage [which encryption cannot hide] and/or other "hints", such as packet's size [non-max sized filled packets, often indicate a lower usage flow, but not always] and/or TCP push bit.)
The background class can be used for bandwidth hogs that don't need timely (as in interactive) response times. "Poster children" for this class might be system backups, email server-to-server, etc.
FQ in class-default, generally does a very good job of keeping some (few) bandwidth hogs flows from being adverse to interactive type traffic flows.
Some problems with a "the book" approach, similar to what you posted, include:
As noted in a separate posting, low bandwidth allocations also make for low dequeuing priority relative to other classes. So, for example, the 5% allocated to VoIP signally and routing protocol classes create a dequeuing ratio of 1:5 relative to class-default. So, if a bandwidth hog fills class default, if signally and/or routing protocol classes' traffic is delayed, could that be a problem?
As also noted in a separate posting, I recommend against using RED. But I didn't note why.
Well, for starters, it's curious there are so many proposed RED variants to "improve" (as in "fixing") RED, that alone should make one wonder. Heck, Cisco has its own (better IMO) variant, FRED, but it's only provided, I recall (?), on Catalyst 4500s.
Some of the problems with RED, since it works on moving averages, it can actually drop packets even when queue is currently empty and conversely allow tail drops when queue rapidly fills.
As RED actual queues can be bigger than moving average value, actual packet drops can also be delayed resulting in a delay notification to sender to "slow" its transmission rate.
RED is only suitable for TCP and/or other flow rate adaptive traffic. (Using it in class-default, may needlessly drop traffic where RED is of no benefit [for its intended purpose].)
Mixing FQ and RED is counter productive. FQ will tail-drop specific flows filling flow queues [also against actual queue sizes], while RED drops against all traffic, globally. Although bandwidth hog packets are more likely to be dropped, RED can drop packets from "innocent" (not filling pipe) flows.
I recall (?) Cisco's RED defaults don't generally correspond to Dr. Floyd's (creator of RED) recommendations, and often need some major adjustments to obtain optimal results (why I recommend RED only be used by QoS experts).
IMO (again, not so humble, laugh) FQ is much, much (much) better to use, in many cases, than WRED. Cisco's FRED, though, being flow based, better targets the "guilty" bandwidth hogs, but it too takes some "tweaking" to work optimally.
Oh, one area RED can be used, it works well if you have need for WTD, although that too will require changing WRED settings. But those are pretty easy to set for optimal usage (again, for WTD).
