Unclear the meaning of the various QoS bandwidth allocations, less than the line's bandwidth, unless this is for real-time traffic. Also unclear the 6 Mbps bearer over the 10 Mbps, unless this is a 10 Mbps Ethernet handoff but traffic above 6 Mbps is rate limited or shaped. (Important to know, also whether it applies both for ingress and egress, since your spoke sites tally 8 Mbps.)
You written you have a hub and spoke. Does this mean there should not be traffic between spoke sites, or there can not be traffic between spoke sites? If traffic is only between the hub and spokes, and you don't have that many spokes, you could configure QoS on the hub unique for each spoke and not rely on the provider's QoS model.
In my prior note, I asked whether you could verify bandwidth allocations for the provider's non-real-time classes. Some models use classes of nearly the same bandwidths, some with very different allocations. For either, if CBWFQ is being used, it's important to understand the bandwidth allocation define a minimum and sets the ratios between classes.
If for instance, the bandwidths were something like Silver 40%, Bronze 20% and BE 10%, the ratio of 4:2:1 is maintained if the classes want additional bandwidth and it's available. If both Silver and BE wanted all the bandwidth (and there's no Bronze traffic), Silver would obtain 80% and BE 20%. If Silver only used 50% (again no Bronze), and BE wanted all the bandwidth, it would get the other 50%. So, when choosing what classes to place different types of traffic in, not only determine the minimum that traffic needs, but whether it should obtain more available bandwidth than other classes.
Know how you want to use the classes, then determine how to mark the traffic to be placed into the classes.
Within your network, if possible, you can classify and mark traffic on the first network device and later, if you chose, use those marking for congestion management. On your CE router, it's often possible to combine the classification and congestion management at the same time.
An example of separate classification and congestion management on CE.
(pseudo code)
class-map match-any classifyGold
match dscp EF
class-map match-any classifySilver
match protocol citrix
match protocol telnet
class-map match-any classifyScavenger
match protocol ftp
policy-map classifyMyTraffic
class classifyGold
set dscp ef
class classifySilver
set dscp cs3
class classifyScavenger
set dscp af13
class class-default
set dscp be
class match-any Gold
match dscp ef
class match-any Silver
match dscp cs3
class match-any Scavenger
match dscp af31
policy-map toMPLS
class Gold
priority percent 40
set ip precedence 5
class Silver
bandwidth remaining percent ##
set ip precedence 4
class Scavenger
bandwidth remaining percent 1
set ip precedence 2
class class-default
set ip precedence 0
fastethernet 1
service policy input classifyMyTraffic
serial 1
service policy output toMPLS
An example of combined classification and congestion management on CE.
(pseudo code)
class match-any Gold
match dscp EF
class match-any Silver
match protocol citrix
match protocol telnet
class match-any Scavenger
match protocol ftp
policy-map toMPLS
class Gold
priority percent 40
set ip precedence 5
class Silver
bandwidth remaining percent ##
set ip precedence 4
class Scavenger
bandwidth remaining percent 1
set ip precedence 2
class class-default
set ip precedence 0
serial 1
service policy output toMPLS
