LLQ for Citrix Traffic?

[afilandro]

We have setup an ACL which includes any to any port 1494 to try and give Citrix traffic priority with a diffserv matched marking of AF21 (DSCP18)..

What is occuring, it seems from user feedback, is during times of congestion---although the interactive (citrix) class is allocated 40% of a 512k link (225kb/sec) and are using a max on 30sec averages of around 100kb/sec..they are "feeling" the congestion points with frozen screens and some citrix "jitter" affects.

Is it that this type of traffic really needs a low latency queue??...has anyone had any practical working experience with prioritization of ICA traffic on frame-relay links ---or have seen normal prioritization schemes not "work as advertised" in this sense.

Here is some output:

Class-map: INTERACTIVE (match-any)

13524037 packets, 752792837 bytes

5 minute offered rate 31000 bps, drop rate 0 bps

Match: ip dscp af21

13524037 packets, 752792837 bytes

5 minute rate 31000 bps

Queueing

Output Queue: Conversation 44

Bandwidth 44 (%)

Bandwidth 225 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 93226/5647275

(depth/total drops/no-buffer drops) 0/532/0

Class-map: class-default (match-any)

3142847 packets, 663729517 bytes

5 minute offered rate 19000 bps, drop rate 0 bps

Match: any

Queueing

Output Queue: Conversation 48

Bandwidth 25 (%)

Bandwidth 128 (kbps)

(pkts matched/bytes matched) 148331/183119515

(depth/total drops/no-buffer drops) 0/25/0

exponential weight: 9

mean queue depth: 0

[dgahm]

I have quite a lot of experience with supporting Citrix over WAN links, including frame relay. Here is what I have learned:

1. Weighted fair queuing usually works quite well as it protects small packet interactive sessions. Fair queue is also easy to implement.

2. If you use CBWFQ you need to use NBAR with the Citrix PDLM to tag packets based on the ICA Priority tag. This will allow you to put print jobs and audio in your default class, and screen updates in a protected class. Print jobs (depending on how printers are setup) with your QOS could cause the symptoms you describe. Do you allow audio through Citrix?

3. The network is often blamed for performance issues, but usually not at fault. Assuming your traffic loads were light in both directions on your link, and the performance was bad at the same time, then QOS was not the problem. It is possible that packet loss, and retransmissions could cause your symptoms. A Sniffer is a powerful tool in running down these kinds of problems. Another useful technique, is to have the user ping the Citrix server when the freezes are occurring. If ping response is good then the server is likely bogged down, which is not uncommon. If ping response is slow and times erratic, then congestion may be the problem, and QOS may be the fix. If pings are being dropped, but successful response times are stable, then you may have link errors.

I would never use LLQ for Citrix. It is not needed, and you may want to carry voice over your links someday, and it does require LLQ.

[afilandro]

Excellent response thanks very much dgahm!

I didnt want to run an LLQ for Citrix because it didnt fit into our "structure-map"....We have been using sniffers to try and find the problem and there does seem now to be a correlation between a server delay potentially causing this "sluggishness". Very good idea with the pings I will give that a shot!

Thanks again

Alan

[rpickard]

would it be possible for you to post the show run ?

I am working on a production issue that seems simular to this.

Thanks,

Richard

CCIE | NNCSE

//