It's not recommended to allocated 80% of the total bandwidth to priority traffic. The rule of thumb is 33% max as that much % can starve other traffic. It seems you are experiencing data starvation in your other classes.
QoS design needs to be understood by the person who is implementing it as there are plenty of variables on each design.
My best recommendation is to read the QoS SRND at this URL:
"Will the following confige cause data slowness, If I am reading it correct, looks like rdp will have a 5% cap on available bandwidth "
What do you consider "data slowness"?
RDP isn't capped at 5% with the bandwidth statement, the bandwidth statement guarantees a minimum of 5% (although I believe FQ in class-default can disrupt the guarantee on some platform's IOS). A class using just a bandwidth statement could obtain 100%.
The shaper value of 1,000,000, might be a cause of slowness if more bandwidth was actually available.
I don't get it; you re worried about the rest of the traffic, how well will it flow? or about the RDP sessions?
The good thing about bandwidth percent is that it's not FIXED; it's only guarantees that will not drop behind that percentage, but it can go higher if there's available BW, or can use 0, if there s no traffic of that type.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...