What you've described creates several, generally, "impossible" issues.
You describe both your "up" and "down" bandwidths as variable. Generally, QoS manages congestion at bottlenecks. If we don't know the bandwidth we have, i.e. there's no indication to us there's congestion, we cannot manage it via QoS.
There's one exception (of which I'm aware), Cisco has a dynamic shaper that works with some of their DMVPN tunnels, Adaptive QoS, but that doesn't help us here.
W/o that feature we can shape for the "usual" expected "up" bandwidth (which you note as 5 Mbps). Two possible issues, doing that though. First, if there's actually more bandwidth that's available, your traffic will not take advantage of it. Second, if there's less actual bandwidth, your QoS will not manage the congestion the way we want.
Note: I'm not current on ISR 1K QoS features. However, assuming it supports the usual QoS MQC, some variations of what @Georg Pauwen already supported might work for you.
First, possibly something like:
policy-map up1
class class-default
shape average 5000000 !set value to correspond with bandwidth that's always available
In the past, I believe I noted shapers sometimes used FQ, but also recall noticing later shapers no longer did.
If so, on your ISR, you'll need a policy closer to what Georg described.
policy-map up2parent
class class-default
shape average 5000000
service-policy up2child
policy-map up2child
class class-default
fair-queue
FQ, in the above, might be sufficient, but if you find you actually need to further prioritize some particular traffic, what Georg described, or a variation of it, could be used.
class-map special match-any !or -all
match . . .
policy-map up3parent
class class-default
shape average 5000000
service-policy up2child
policy-map up3child
class special
fair-queue
bandwidth percent 90 !adjust percentage values as desired - they should add to 100
class class-default
fair-queue
bandwidth percent 10 !adjust percentage values as desired - they should add to 100
One difference from what Georg suggested, I recommend to only use "priority" for real-time traffic, like VoIP. The bandwidth command doesn't "cap" that class's bandwidth, and if you set percentages to 99:1, you'll get similar priority for your special class as if you used the priority command.
Managing "down" bandwidth, effectively, is quite difficult. From what you've described, suspect if you manage your "up" bandwidth, you may resolve you issue.
