NOTE: My question is similar to the below post but in my case I do not see the PRIORITY working . . .
Again, I've already posted what you're doing will be ineffective, and why that's so.
To recap that, if your ingress is physically limited to some bandwidth, and downstream of that bandwidth you shape a higher bandwidth port for the same bandwidth as the upstream supports, the shaper won't queue any traffic, and if no traffic is queued, there's nothing to prioritize.
If you wanted to see your shaper do "something", shape slower than your 16 Mbps. Then you should be able to see some traffic getting priority. However, doing this, you've only mostly held back your non-priority traffic. If you queue enough of your non-priority traffic that it starts to drop packets, depending on the nature of that traffic, it may slow its transmission rate allowing more bandwidth, upstream, for your priority traffic.
As noted above, if some traffic "sees" drops, it may slow its transmission rate. So you might also police inbound non-priority traffic trying to keep bandwidth available for your priority traffic. Likewise, some traffic, for example, TCP, will also slow it's transmission rate if you slow its returning ACKs. Both of these approaches aren't very dynamic regarding the needs of the priority traffic. You may not preserve enough bandwidth for your priority traffic and/or allow bandwidth to go unused.
Where you really want your inbound QoS policy is on the service provider's egress port, unfortunately most service providers will not support/allow this.
Trying to manage ingress bandwidth, at the receiving end, can be very difficult especially if only using router QoS features. "Special" dedicated traffic shaping appliances can do much more, but even they are not 100% effective in all cases. However, if you really need to better manage ingress bandwidth, and your service provider won't provide QoS on their end of the link, that's likely your most effective option.
