One of the most important principles to keep in mind when designing QoS solutions is that traffic shaping and priority is a pretty much one-sided affair, where the SENDER has arguably the most important important role in traffic shaping.
Picture in your mind a data network being like a network of railway stations with people moving between metropolitan destinations - the railways stations are like routers, a LAN is like a town serviced by a railway station and the railways lines are the data links.
There are a few nicely analogous properties:
The capacity of the railways station is limited by the number of staff on hand to sell tickets and control entry and exit to the platforms. The more staff on deck, the more passenger movements they can handle. This is analogous to the CPU capacity of the router as the higher performance CPU you have, the more data packets you can move.
If you can only handle 100 passengers per hour, but you start getting trains arriving carrying 120 passengers in an hour, you have to put passengers in queues at the platform exit gates while you process their tickets. If they keep arriving at a rate faster than you can possibly process them, then you have no choice but to simply send them back - i.e. dropped packets. Once you start dropping packets, though, it doesn't stop them from coming - it just causes grief with those passengers wanting to get through, and with their families waiting for them to arrive! ;-)
Note that dropping packets is an effective way to manage your exit queues, but it doesn't stop the remote stations from sending passengers. To make sure that you don;t have to drop packets, you have to tell the other end to stop sending them! Unfortunately, there is no analogous technical protocol to a stationmaster getting on the phone and asking the remote master to slow down on the passengers! The only way to do it in the routing world is to get on the phone and ask the administrator of the remote router to shape traffic according to your requirements.
Then there's the capacity of the trains (number of seats and number of services/day) is like the bandwidth available on the link. The more services per day and the more carriages on the train increases the bit-rate on that line. As discussed previously, a high capacity link is no use if the station at the other end can't cope with the traffic throughput!
Last of all, there's first class an economy tickets. If you have a first class ticket, then not only do you get a comfy plush couch to ride in, but you also get to go straight to the front of the queuing minions, or you get to use the special red-carpeted queue that is processed ahead of all the others. This means that VIP passengers will always get first access to the train services and will always get to the destination on time.
Once again, if you have VIP queues at the /destination/ it can only help you improve exit time when those first class passengers get off the train and move through the exit gates. If those passengers are not allowed to get on the train in the first place, red carpet service at the destination is no help at all!
The important point that are worth noting, is that you really need to start your traffic management efforts from the end that is /sending/ the passengers rather than to try to manage your input queues. There are some proprietary solutions that allow independent routers to exchange traffic information to convey inbound capacity to a sending router but no open standards that I am aware of. Remember that there are several points of possible congestion - including the router CPU capabilities, and not just the bandwidth capabilities of the network links.
I hope this analogous treatment of QoS operations helps you to understand underlying constraints in data systems and if you have any questions or comments, I'll be delighted to hear from you!