Well, one reason of using minimum bandwidth guarantees, for policy classes, it helps insure such a class cannot monopolize all the bandwidth. This being the usual case, generally it causes no harm to allow a class to be "uncapped", i.e. use all available, otherwise not being used, bandwidth.
Where limiting class bandwidth, can be needed, is when a class is prioritized such that when it "grabs" bandwidth it can do so at the expense of other lower priority classes. This is acceptable when all the priority traffic really needs the bandwidth, it's not acceptable when there are one or more flows in the high priority class that shouldn't be using that class. For example, all VoIP carrier traffic, in a priority class, is generally fine, but a FTP transfer, in such a class, is generally not so fine.
IMO, perhaps a very good general QoS policy might be:
policy-map Sample
class RealTime
priority percent 35
class HiPriority
bandwidth remaining percent 81
fair-queue
class LoPriority
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue
In the above, things like VoIP carrier traffic go into the RealTime class. Most all other traffic goes into class-default, where its FQ shares bandwidth, usually pretty well.
For known bulk traffic, perhaps like FTP transfers, it can be directed to the LoPriority class. As noted, FQ, would probably keep such flow(s) from being adverse to the other flows, but there are situations where it won't. One issue is FQ doesn't really allocated a queue for every flow, so a bulk flow FQ queue might be shared with other non-bulk traffic.
The HiPriority class should only have traffic directed to it that you really want to insure is a little more "equal" then other BE traffic. For example, you might direct VoIP control traffic to this class. If, somehow, some flow in this class starts to run "amok", FQ in this class will likely help "protect" other flows in this class. What can also help, as this class has a large bandwidth guarantee, if the device supports, setting a low value for its class flow queues. This will "target" the flow(s) filling the bandwidth for aggressive dropping.
Such an "amok" flow will be a bit hard on lessor priority flows. You can decrease the ratio of bandwidth guarantees between this class and the BE (i.e. class-default) class, to mitigate the impact, but then you decrease the dequeuing priority and increase drop probability for other flows in this class. What's actually best depends on your QoS needs.
BTW, I see you're using WRED. I generally recommend it not be used by other than QoS experts. It's much more difficult to "get right" then most of its cursory literature implies. I won't go into all the problems with WRED, but besides the many other variants, even Cisco has another variant, FRED, only available on one of its platforms.
