Your question probably got overlooked because of the forum you selected. I just stumbled across it while doing a search on "QoS". I believe you would get response in the "WAN, Routing and Switching" forum. QoS might indeed help. (Quick test - if remote desktop is only sluggish during peak usage, then QoS might help.)

What QoS does best is manage bandwidth instead of treating all traffic alike. For instance, you can insure your RDP traffic is not pushed aside by other bulk traffic, like file transfers. You can also use it to retain control of your bandwidth in certain situations.

You mention you're using frame-relay with a hub and spoke design. Depending on how you've sized your connections to the frame-relay cloud, it's often easy to overrun a frame-relay egress (from the cloud to your site) link. Most common causes are hub site having more bandwidth then some remote sites or aggregate of remote sites having more bandwidth than the hub. Either situation usually entails a single FIFO queue which often delays time sensitive traffic. You prevent this by using traffic shaping.

Once you preclude bottlenecks forming in the frame-relay cloud, you then can manage your RDP traffic to have sufficient bandwidth for it to operate best.

What QoS won't help you with is if you have insufficient bandwidth to support your RDP traffic or distance based latency.

If you can provide more information about all your physical link bandwidths and their CIRs, I could offer some specific suggestions.

No problem, thanks for the input on the forums.

Your description of the RDP traffic being pushed aside by other traffic seems to be an accurate description to what I think is happening. Internet downloads (legitimate) are being done from the local desktop as opposed to the remote desktop, such as large PDF's and occasionally some video or graphics files. If that is the case, I believe QoS would help guarantee the RDP traffic has a certain amount of bandwidth and continue to run smoothly no matter what is happening at the local desktop level.

While for most internet usage, they should be using the remote desktop's internet connection (which uses the main office), they complain about the security measures we have in place and until we find a better solution, this is the way it will be for some time.

About our network:

4 remote offices using a 128 kbps Frame Relay link into the central office for data, burstable to 512 kbps (these offices run with 2-3 people only). We have a total of 1.54 mbps of bandwidth for all 4 of these sites.

1 remote office uses a 512 kbps, burstable to 1.54 mbps - note, this is the office where most of the complaints come from - and the only one that uses their local desktops for anything, they also have 6-7 users. They have a private line into the main office with their own T1 card in our smart jack. We have 1.54 of bandwidth available to them.

Our central office uses a full T1 for internet traffic only and a connection for the 4 offices coming in on the 128 / 512 setup. The 512/1.54 connection has it's own line coming into the building into our routers.

Does that help?

For your one office with the 512/1544 that connects to your HQ 1544, first check whether WFQ is active both sides. If not, activate it and see if that cures the problem to that remote office. If not, you can define a policy somewhat like this.

(NB: syntax likely off)

ip access-list extended RDP_Servers

ip permit tcp host (your server IP) any

ip permit tcp any host (your server IP)

class-map RDP_Servers

match group name RDP_Servers

policy-map

class RDP_Servers

bandwidth percentage 25

(apply to HQ and remote) serial #

service-policy out RDP_Servers

For your other links, assuming most data is from HQ to remote and assuming you've assigned subinterface per PVC, first try:

HUB serial #.##

traffic shape rate 512000 (think it bps)

If that alone doesn't do the trick, try:

policy-map 512_RDP

class class-default

shape 512000

service-policy RDP_Servers (requires all above for support 1.5 Mbps)

(apply to HQ) serial #.##

service-policy out 512_RDP

For 128/512 remotes, assure they're running WFQ. If that alone doesn't address the problem, try using the policy for HQ/remote 1.5 links. After that, try a policy similar to the last but shape to 350 Kbps.