Introduction
Latency is the delay it takes for a package to travel from the server to the client, and vice versa. A simple ping command will tell you the latency for that ping to arrive to its destination. (called the entry “time=”)
A LAN environment usually has a low latency, as it has to travel a short distance.
When going over WAN connections or using the internet (which uses a lot of routers to go from a to b) latency can increase. The biggest latency is seen when crossing continents or using satellites. In combination with poor bandwidth this is fatal.
So, what do we need for smooth operation?
A user’s session needs roughly 20kbit for a Citrix session, and 30kbit for a Terminal Server session. Latency should be under 150 to operate smoothly.
Keep in mind that if the user is not using applications, nothing other than probably the keepalives (will come back to that later) will consume some minor bandwidth, but mostly nothing will go over the line.
So it’s all about active sessions that take up bandwidth. A session can take more if the bandwidth is available, but will still work when the available bandwidth becomes smaller.
Changing the packet acknowledgements timer
The TCP/IP communication between the server and the client requires a packet acknowledgement back from the client to the server. If the server does not get back the acknowledgement within 3 seconds, the session is dropped. Now 3 seconds is a lot, but you can have various influences on the network, preventing this acknowledgement to reach the server.
In order to tell the server to resend the acknowledgement request, you need to create a registry key called:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
“TcpMaxDataRetransmissions”=dword:0000000a
This key will create up to 10 new attempts to resend the acknowledgement request.
This setting is helpful in both Microsoft Terminal Server and Citrix sessions, especially in higher latency environments, like while using the internet.
Keepalives
Keepalives are settings that are closely connected to the above TcpMaxDataRetransmissions setting.
Now that we have told the server to take more time if the connection has been lost to retry connectivity, we need to tell the actual running sessions that they should not worry that it’s taking longer than expected.
For RDP that reassuring would be the following key on the server:
[KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
“KeepAliveTime”=dword:0000ea60
“KeepAliveInterval”=dword:000003e8
Citrix keepalives need to be set via the Citrix Management Console as from Citrix XP FR3 and higher. Lower versions need the keepalives activated via the following registry key:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Citrix]
“IcaEnableKeepAlive”=dword:00000001
“IcaKeepAliveInterval”=dword:0000003c
Despite the setting of these keepalives, it might happen that sessions are still cut off during normal use. This is usually due to hardware like firewalls, routers or managed switches with an “idle time” set. They do not always correctly pick up the ongoing traffic, and disconnect the session, while the users are using the application. Set these idle time settings to the maximum, or disable them if possible.
The use of QoS
QoS stands for Quality Of Service, and is a way of delegating a minimum and maximum bandwidth availability to a specific protocol. These days most WAN environments hold many traffic types, and Microsoft’s RDP or Citrix’s ICA is just one of many. As explained earlier, both protocols do not take much bandwidth, but that little they need has to be there for the sessions to be fully functional and stable.
If your router is equipped with QoS functionality, it is highly advisable to make full use of it. The safest thing to set is a minimum that can be taken by RDP or ICA traffic. That way the sessions throughput will never get clogged on the server side, and can take full advantage if more bandwidth is available.
Cisco
In March 2004, Cisco enhanced their NBAR (Network-Based Application Recognition) technology towards the ICA protocol, by making a (free) ICA PDLM (Packet Data Language Module) available called “citrix_ica”. This module works as from IOS 12.3(7)T released in March 2004. This new module can work together fully with the existing ICA priority packet tagging technology already present in the router.
Another important option available in Cisco routers 2600, 3600 and 7200 series is the “Weighted Fair Queuing”. Once activated it allows fairer treatment of smaller packages (like RDP and ICA), versus a larger package. This one is especially important in small bandwidth connections like 64 or 128kb lines.
MTU
MTU stands for Maximum Transmission Unit, and is the largest size packet or frame, specified in octets (eight-bit bytes), that can be sent in a packet- or frame-based network. Ethernet has a standard MTU of 1500. DSL has 1492 and for internet use the standard is 576 (which is the same for dial-up).
On most recent Windows systems, the operating system is able to sense whether your connection should use 1500 or 576 and select the appropriate MTU for the connection. If for some reason you have a client machine that does not seem to like RDP or Citrix traffic, because theirISP has a different value configured in its hardware, or the user has created their own network using a NAT route that does not like the MTU value, you can change it on the client side via:
HKLM\system\currentcontrolset\services\tcpip\parameters\interfaces\”ID for Adapter”
Add a dword value MTU with a value of 1492 decimal.
To find the optimal MTU for that client do a “ping x.x.x.x -f -l 1500”, where x.x.x.x is the address of the Citrix server involved. (If ICMP has been disabled from the router or firewall, use the resolvable router or firewall address, where the Citrix or Terminal Server is located).
Keep lowering the 1500 value until you get a number where you no longer get the message:
“Packet needs to be fragmented but DF set.”
If manually changing the MTU value in the registry is not your cup of tea, you can use the following free tool: http://www.networkingfiles.com/Download/CableNut.htm
Citrix SLR
Citrix SLR stands for SpeedScreen Latency Reduction. This is a technology that gives you 2 features in your session. The first one is a “Local Test Echo”, which allows a user to see the character they type into their session on the screen, without this key press hitting the actual server at that time. The actual key press is sent to the server, at a later time, usually due to latency, while the user is already typing in a new key press. The character is projected onto the session on the client side. This results in the user experiencing a fast performance when it comes to entering data, over high latency lines.
The other feature is called “Mouse Click Feedback”. A user clicks on a button in the session, waiting for a popup or an action. When the action does not start, the user thinks something has gone wrong, and hits the button again. Once the server has finished processing the request due to latency, the result is probably having the button clicked twice (with all surprises that come with that action).
When enabled, the result of a click not reaching the server yet, thus not getting a return package from the server, activates an hourglass for the mouse pointer. This tells the user that the application is still running the last request, done by the mouse. It should buy the server some time to respond to the mouse click back to the client, and free the hourglass back into a normal mouse pointer, so the user can continue.
Both these technologies are an excellent way to go around the latency problem, and of giving the user the feeling of a fast session.
The use of SLR needs to be activated on both the server and the client. On the server it needs to be activated per application via the SLR manager. On the client it needs to be activated in the options tab of the PN client, or in the template.ica file when using the PN Agent, or webclient by adding the following 2 lines (0=off, 1=on, and 2=auto):
ZLKeyboardMode=1
ZLMouseMode=1
Latency Thresholds for SLR:
If latency is greater than 250 milliseconds, set SLR to On.
If latency is between 150 and 250 milliseconds, set SLR to Auto.
If latency is between 50 and 80 milliseconds, set SLR to Off.
A full Citrix article on SLR can be found here.
Virtual Channels
Virtual Channels is the way all the functionality is divided over the protocol.
For example the screen scraping, the data transfer, clipboard, the printing, etc all have their own virtual channel in the RDP or ICA protocol. Most of this functionality are really options that can be enabled or disabled in the connection configuration settings for both RDP as ICA. Disabling all unneeded features will result in a lower load and a smoother experience for the user.
A main difference between RDP and ICA regarding printing over the virtual channel, is that in Citrix ICA the maximum usable bandwidth for printing can be set in the Citrix Management Console until MPS 3.0 and with a policy in CPS 4.0. Microsoft RDP does not have this functionality and will take all available bandwidth it can for printing the job, making the needed bandwidth go way over 30kb per session.
When using Citrix, it is highly advisable to set a maximum for the print job bandwidth (the best set bandwidth can be reached in a mix where the minimal setting still works on all printers and the end users are still happy with printing performance).
Conclusion
Fighting low bandwidth and latency can be an intensive job, and can require cooperation with the network group, the firewall guys, the hardware guys, and the system administrator or end users on the client side. Finding out a culprit for disconnected sessions for a specific user or site is also intensive. Hopefully the above advice gives you a handle on bringing these challenges to a successful ending.
