QoS on an HP 6125 XLG switch running Comware 7

The short answer is no.  Your queuing policy needs to be applied outbound at the point of bottleneck.  In this case, the bottleneck is the WAN connection (20 Mbps) between the pfSense and the 1841.  Thus, the proper location of your queuing policies are outbound on the LAN interface (a bit of a misnomer) of the pfSense and outbound on Fa0/01 of the 1841, which you have.

All that being said, your policy on the 1841 is flawed.  In your example, you've reserved 1 Mbps of bandwidth for VoIP and applied the policy to a 100 Mbps interface.  What happens when the PCs start pushing 70Mbps of traffic while trying to make a VoIP call?  From a queuing standpoint on the 1841, the answer is nothing.  There is only 70 Mbps of data flowing out Fa0/1.  Therefore, there is always 1 Mbps available for VoIP.  However, once this traffic reaches the pfSense,  at least 50 Mbps of data and VoIP will be dropped.  Your calls would be terrible at best.

Without getting into all of the details, and using your prior example, the policy should be something like this:

class-map match-any CM-VOICE-TRAFFIC
 match access-group 145
!
policy-map PM-PRIORITISE-VOICE-child
 class CM-VOICE-TRAFFIC
   set ip dscp ef
   priority 1000
 class class-default
   fair-queue
!
policy-map Shape-20Mb-parent
 class class-default
  shape average 20000000
  service-policy PM-PRIORITISE-VOICE-child
!
interface FastEthernet0/1
 service-policy output Shape-20Mb-parent
!
access-list 145 permit ip 10.0.59.0 0.0.0.255 any

This policy creates an artificial bandwidth limit on all traffic leaving the Fa0/1 on the 1841.  Thus, the pfSense will never have the opportunity to drop traffic indiscriminately.  Also, instead of the bandwidth command, the priority command should be used to limit latency and jitter.  The tagging and the ACL change should be self-explanatory.

To answer your questions:

• RDP traffic should get up to the 25% of the remaining bandwidth. Where the already reserved bandwidth is the 35% ( class-default gets 25% by default and EF get 10% ). So, if i'm right, you assigned ~665Kbps to RDP. Anyway you should check if you're dropping packets issuing the command below:

show policy-map <your wan interface> output class REMOTEDESKTOP

and checking for dropped packets.

• Cisco assign a queue to each user-defined class that includes the bandwidth or police commands. To make a long-story simple those commands define the amount of bandwidth assigned to every queue during congestions.

• In theory every TCP based stream should be OK with drops. In practice some of them aren't. Dropping precedence bits tell the routers what packets should be dropped, within a given class, before congestion happens. Since RDP is the only type of traffic defined in your REMOTEDESKTOP class, you should not worry about it.

• Bandwidth percentage are not in order ( as Jeremy stated ).

That said, there are a lot of things that i would change in your configuration:

• There are no matches between some of classes of the setTos and the useTos policy-map. For instance the one named AF-HIGH is processing no packets since no class in setTos sets DSCP to AF41.

• BE class in setTos is somehow self-defeating since it makes the class-default class useless. Note that class-default is the only system-defined class and get the 25% of the bandwidth by default ( 100 - max-reserved-bandwidth ) .

• bandwidth remaining percent is not the best options ( as Jeremy explained ). I would change it to bandwidth percent.

• I would prefer to mark EF packets by myself and not to rely on the phones' settings.