Yes, you might have insufficient bandwidth for the offered load. Excluding bulk data transfers, for interactive type traffic, if your average load utilization exceeds about two thirds, you're likely to have queuing. Assuming, though, its an issue of a few "bandwidth hogs" adversely impacting other traffic . . .
Good place to start is with FQ for all traffic. If using CBWFQ, something like:
policy-map sample
class default-class
fair-queue
interface multi x
service-policy output sample
You would implement that on both sides.
If a single FQ doesn't solve your problem, there are two approaches you can take (which are not exclusive). You can either set IP Precedence (or DSCP CS), if FQ does WFQ (many Cisco implementations do), and/or you can break other traffic into their own classes using CBWFQ.
If you use IP Precedence, you might try IP Prec 0 for background, IP Prec 2 for normal and IP Prec 4 for critical. WFQ will allow more bandwidth, per flow, if the flow has a higher IP Prec value.
I would not recommend using "priority bandwidth", except for real-time traffic. Nor do I generally recommend policing traffic if priorization is available.
As sample CBWFQ policy for three priority tiers could be as follows:
policy-map sample2
class criticaltraffic
bandwidth remaining percent 60
class backgroundtraffic
bandwidth remaining percent 10
class default-class
bandwidth remaining percent 30
For the above, you'll need to define class-maps for the explicit classes.
[edit]
If your running a very recent 12.4T version, you could add fair-queue to each class, which would avoid single class queue.
