If you would like to read part 2 of this article series please read Bandwidth Management: Part 2 – Leveraging Citrix Policy to Optimize Bandwidth Usage.
Introduction
Believe it or not, server based computing has some major “design challenges” that some detractors would consider death knells for the technology. Printing, Application Integration, Cost and Bandwidth Management are a few of the more common issues that arise during the life cycle of a server-based environment. Bandwidth Management, though often one of the LAST concerns in many architects’ minds, should be chief among the considerations for a successful implementation.
True enough that ICA and RDP are VERY good citizens, as far as presentation layer protocols go, on our corporate LAN/WANs. However, presentation layer protocols are very susceptible to latency and connection instability. Thus we, as architects, must consider strategies to this issue. There are two main strategies of bandwidth management. INTERNAL and EXTERNAL bandwidth management solutions exist to help control ICA/RDP on the network. In part one of this article series we will look at controlling ICA/RDP traffic WITHIN the ICA Packets, or INTERNAL, particularly focusing on some “older” or “seasoned” methods of dealing with this issue. Keep in mind that a holistic approach of both INTERNAL and EXTERNAL solutions is necessary. It really does little good to implement all the recommendations in this article only to have an EXTERNAL FTP application crush the network and starve out our ICA connections, for instance.
In modern (read the last couple years) implementations of Windows Terminal Services, all session traffic (whether ICA or RDP) is encapsulated within a TCP Frame (or Datagram) that is sent out on the network with the rest of the traffic. Thus, on the network, an ICA packet that contains screen updates has no “perceivable” difference from the next ICA packet that contains a print job, for example. On the surface this seems like a “non-issue” until we look at the “flexibility” of a session on the wire.
If we make the assumption that a typical ICA/RDP session consumes about 20-30kbps while active then we can do the math pretty easily and see that a normal 100Mbps network link can hold a LOT of simultaneous active sessions. Where this becomes the design challenge is the WAN or remote users. Ask yourself this question. Have I ever had a remote office in which ICA sessions seem to be fine 90% of the time but occasionally we have periods of REALLY slow-to-respond sessions or possibly even session drops? If this is your network, you may have a need to leverage bandwidth management. The “little known fact” about ICA/RDP connections is that the 20-30kbps is for the DAILY average… it does NOT include the occasional MONOLITHIC print jobs that occur through ICA or the web browser of graphically intense websites for instance. When users access sites like these or print large jobs inside of ICA/RDP the ICA packets (and data transmission) increasing DRAMACTICALLY! On a local area network this is typically a non-issue, but on a WAN or remotely, the impact can be catastrophic. This can introduce the latency and “spiking” in the link that KILLS the performance of presentation layer protocols.
So, we look at the methods that are available with Citrix Presentation Server 4.0 (sorry Terminal Services only users, there simply aren’t enough ways of improving the protocol to write an article about yet). Again, we are focusing this article and the practices on what we can do “natively” with Presentation Server and ICA to control the bandwidth usage. There are basically three “sub-methods” to INTERNALLY control the way ICA rides on the network:
- ICA PRIORITY PACKET TAGGING
- ADJUSTING THE THINWIRE PROPERTIES FOR A GIVEN SERVER
- CITRIX POLICY
NOTE:
While Citrix Policy is the preferred method today, we will be saving that one for part two in this series as it is a subject warranting an entire article to it!
ICA PRIORITY PACKET TAGGING
ICA PRIORITY PACKET TAGGING is a feature that Citrix leverages internal to the ICA Packet. Basically, there are 32 virtual channels available in a standard ICA packet. Of the available 32, only about 6-10 are actually used during a typical Citrix session (and many have never been used as they are there for developers to extend the protocol). An example of the use of a virtual channel would be drive redirection or the ability to connect to and use local client-side drive during an ICA session. Many “features” of ICA have multiple virtual channels available to them, such as printing. Each of the 32 virtual channels ICA each is given a “default” priority of importance for transmission and reassembly on the other end… the idea being that screen updates should be MORE important than say, audio. So a few years ago, Citrix partnered with CISCO and some other name brand manufacturers to allow their QoS devices to “see” into an ICA packet and allow the smart guys to change the priority of the packets as they pass through switches to better fit network design. For more information on this, I would encourage you to review your QoS literature provided by your switch/router manufacturer. But, before you get too far into that delightful read, I will let you know that users of Presentation Server 3 and 4 that have the Session Reliability protocol enabled (that is most of you and for good reason) , you will NOT be able to use the QoS feature of your hardware devices to “read” the ICA packets any longer. It seems that Session Reliability “disables” the ability to read into the ICA packet for the tagging information. So, for those of you that still want to try this option out, there is basically one way to do it, edit the registry on your Presentation Servers. The following table will describe the various ICA Virtual Channels, their default priorities (which can be quite enlightening) and then the following section will describe the method by which you can adjust these. Please keep in mind that you should THOROUGHLY test these changes in your labs prior to implementing this in your production environment. Also, please review the information available on this subject in Citrix’s Knowledgebase as the virtual channel definitions and default priorities are subject to change.
Virtual Channel
Default Priority
Description
CTXTW
0
Remote Session Screen Update (THINWIRE)
CTXWI
0
Seamless Windows Screen Update (THINWIRE)
CTXCLIP
1
Clipboard
CTXCAM
1
Client Audio Mapping
CTXLIC
1
License Management
CTXVFM
1
Video Server (Dead – Remember VideoFrame ?)
CTXPN
1
Program Neighborhood
CTXCCM
2
Client COM Port Mapping
CTXCDM
2
Client Drive Mapping
CTXCM
3
Client Management (Auto-Update)
CTXLPT1
3
Printer Mapping for Non-Spooling Clients
CTXLPT2
3
Printer Mapping for Non-Spooling Clients
CTXCOM1
3
Printer Mapping for Non-Spooling Clients
CTXCOM2
3
Printer Mapping for Non-Spooling Clients
CTXCPM
3
Printer Mapping for Spooling Clients (nearly all)
Table 1: Brief List of Some Default ICA Virtual Channels
In order to adjust the settings of a given server, one simply needs to edit the following registry key:
HKLM\System\CurrentControlSet\Control\Terminal Server\Wds\icawd\Priority
Simply edit the PRIORITY REG MUTLI STRING value to contain the virtual channels to with their desired settings as follows
CTXCOM1,1
CTXLPT1,2
CTXCLIP,3
CTXPN ,0NOTE:
The “channel name” must be 7 characters long, if not, you must pad the value with trailing spaces as seen above with CTXPN!
DISPLAY and PRINTER BANDWIDTH SETTINGS
ICA Display used to be referred to as Thinwire; named so after the Thinwire Virtual Channel that controlled screen updates, redraws and refreshes. The guys at marketing must have not liked the name Thinwire, so it was killed off around the same time that MetaFrame 1.8 disappeared from the landscape. Either way, the next option around managing bandwidth can be found in two flavors, FARM level settings and then adjusting the same settings independently on the servers that are a member of the farm. For the purposes of brevity, we will look only at the farm level settings.
The first of these settings are the ICA Display settings as detailed in Figure 1 below.
Figure 1: Farm Level ICA Settings
The section around ICA DISPLAY as depicted above with the arrow allows you to adjust the ICA Display or “Thinwire” settings for all servers in the farm. Typically, the settings listed here are sufficient for most environments, but it may be on occasion, that you wish to make some “adjustments” to these. Table 2 describes the feature and the pros/cons around the adjustments.
Setting
Default
When to use
Discard redundant graphics operations
ENABLED
Excellent feature that eliminates a great deal of “unnecessary” screen redraws. The basic premise is that ONLY the section of the screen that has changed will be “transmitted” thus greatly reducing bandwidth needed. This is why “animations” can cause HUGE bandwidth concerns through session (such as JavaScript for scrolling banners on web sites!)
RECOMMENDED SETTING – ENABLED
WHEN TO CHANGE – CERTAIN applications that may use highly customized “rendering” may fail to draw information correctly if this is enabled… thus disabling will make the app work correctly. Keep in mind that this is a FARM-WIDE setting that would effect EVERY session on EVERY server.
Alternate caching method
ENABLED
Another great improvement to the PS product (though it has been around for a bit). Basically this feature changes the “way” the screen is rendered instead of top to bottom to left to right… it allows works well with applications that are “multi-page” like websites thus “only” showing the screen to the user when the ENTIRE page it ready to view (this saves us from the render a screen, scroll the page, wait, render the screen, scroll the page, wait, etc…)
RECOMMENDED SETTING – ENABLED
WHEN TO CHANGE – No valid reasons observed to change this in the last few years.
Maximum memory to use for each session’s graphics in kilobytes
5625
A LONG time ago, Citrix and Microsoft decided that 5.5 MB of RAM was “sufficient” to create a virtual video card for each session. It is this “limitation” that defines the maximum resolution settings and color palette combinations. Basically, this is why you can’t run a session at 32Bit color at 1600×1200 resolution.
RECOMMENDED SETTING – 5625 (the max)
WHEN TO CHANGE – If you are running a 256 Color app that operates at 800×600, you can “crank this down” to save a SMALL amount of memory per session.
Degradation Bias
DEGRADE RESOLUTION FIRST
This just tells the server to “adjust” the settings for a user DOWN to fit within the “virtual” video cards 5.5 MB of RAM.
RECOMMENDED SETTING – Depends on the environment, if the apps are picture or desktop publishing, decreasing the “resolution” first is typically the better way, if they are spreadsheet or diagramming applications, typically reducing colors would be the preferred settings
Notify user to session degradation
ENABLED
Does what it says…
RECOMMENDED SETTING – In many environments, disable this… it is just one more “popup” for users to open a help desk ticket about?
Table 2: Brief List of Some Default ICA Virtual Channels
The last of the FARM Level settings that I would recommend looking at would be the SPEEDSCREEN features of BROWSER ACCELERATION, FLASH ACCELLERATION and MULTI-MEDIA ACCELLERATION. We will be covering these features in more detail in the next article (and managing them through policy to some extent) so I will save the “gory” details until then. The only points I will make here would be that USUALLY clients benefit from these features being enabled and that these features exist to a greater or lesser extent based on the version of Presentation Server your environment has deployed.
The last FARM LEVEL setting (although it is really SERVER by SERVER) that we can look at would be printer bandwidth. This is a REALLY good settings to “CAP” across the board as by default it is unlimited. So, to refresh your mind as to WHY we would want to cap this… I have 15 users at a remote location across a ISDN link. The performance of all sessions is acceptable until someone prints at which time all sessions freeze (or drop) until the print job is completed. So, managing printer bandwidth through ICA is a great idea! It is VERY easy to do, simply navigate the Presentation Server Management Console to the Printer Management node and then select the Bandwidth tab. Look at Figure 2 which contains the “edit” feature of the tool.
Figure 2: Farm Level Printer Bandwidth Settings
I would recommend setting a “limit” on this based on several factors… and it is more of an “art than a science”. A few of the factors would be type of print jobs, location of clients and the printers they will print to, and “tolerance” level to slow the job down to keep if from crushing the network but not anger the user who is waiting on the output!
In a large farm, you can edit a single server then simply COPY the setting to all other servers. Now, I am a big fan of this feature and it has been around for a couple of version, but I will point out a few limitations.
- Limiting Printing Bandwidth ONLY works for printing THROUGH ICA (so if the Presentation Server is printing DIRECTLY to a locally attached printer on the server (rare) or to a NETWORK PRINT QUEUE (common) then it will NOT control the bandwidth – only through ICA connections (usually auto-created printers)
- The setting affects ALL users that use the configure server… so local area network users that MAY not need throttled will ALSO be throttled!
As previously stated, depending on your version of Presentation Server you will have more or less functionality with this feature. In the next article we will look at the MUCH superior method (available to PS 3 and 4 users) of leveraging Citrix Policy to control print bandwidth (and other types of traffic) on a user-by-user, network-by-network, or connection-by-connection basis… so tune in next month for the much awaited sequel!
Conclusion
We have taken our first look at bandwidth management and explored some of the typical scenarios around the implementation of such a solution. In this article, the first of the series, we looked at the historical way (and in same cases still the best) of controlling bandwidth using INTERNAL methods, those native to the product. In the next articles in the series, we will look more closely at the new kid on the block, Citrix Policy to control all aspects of INTERNAL Bandwidth Management and EXTERNAL solutions to control bandwidth on the network as a whole.
If you would like to read part 2 of this article series please read Bandwidth Management: Part 2 – Leveraging Citrix Policy to Optimize Bandwidth Usage.
