In the previous installments of this series, we looked at controlling presentation layer protocols, particularly ICA, with various methods. These methods included ICA Priority Packet Tagging (old school) and adjusting the various THINWIRE properties of a given server. Additionally, we looked at how Citrix Policy, a component of Presentation Server, can be used to greatly enhance and finely tune the bandwidth used by various VIRTUAL CHANNELS inside of an ICA Packet.
In this final installment of the series, we will investigate methods for “protecting” the fragile presentation layer protocols with third party tools. All of our optimizations to this point are for naught, if the bigger and hungrier protocols (such as SMTP, FTP, HTTP, etc) are competing on our network links against ICA/RDP for bandwidth. We will look at how to guarantee some Quality of Service and provide consistent bandwidth for ICA and RDP. Server-based applications battle for bandwidth with print traffic, streaming media, peer-to-peer traffic, web browsing, large email attachments, network backups and other bandwidth-hungry applications every day. To achieve predictable and consistent performance, increase employee efficiency and realize the other benefits of central computing you need to take action to intelligently monitor and control your Wide Area Network (WAN) applications and protocols. Tuning ICA and RDP to consume the minimum amounts of bandwidth needed to function simply isn’t enough. I am frequently asked in the field, “How much bandwidth does ICA/RDP require per user session?” While this question is not easily answered as it depends on the types of applications, the client-type connecting and features of ICA and RDP being used, it can be answered typically after a short evaluation period. More often my response will be, “what other type of traffic do you have competing with ICA/RDP on your links?” Frequently complaints of server performance are linked to over-subscribed or poorly managed LAN/WAN links where ICA/RDP is competing (and losing) to other protocols. Like all good engineers, I take pride in my builds. The last thing I want to see is a perfectly designed, perfectly built and perfectly tuned server farm gain a reputation of poor performance especially when it comes to WAN connections.
So, what is the solution? Well, I have to say that I don’t typically side with a particular vendor or manufacturer in these articles (for many and varied reasons)… But, in this article, I will tell you that the solution to be found is Packeteer PacketShapers. I “discovered” PacketShapers several years ago when supporting a larger Citrix implementation where a good deal of the user population was scattered around various sites in the United States. Simply put, we implemented PacketShapers to analyze and control the bandwidth of their WAN links and create our own “virtual partitions” within the links to control the impact of various applications that competed with our ICA sessions. Needless to say, the solution was an immediate hit! While this article is an endorsement for the Packeteer’s products, it is not meant ONLY as that. In addition, it is to enumerate WHY we need to protect and guarantee our network traffic that could be applied to nearly any implementation, server-based computing or otherwise.
What is a PacketShaper?
So without further ado, what is a PacketShaper and how does it work? PacketShapers are basically network appliances that are placed at various locations (design dependent) to analyze and protect network protocols and the applications (thereby the performance of the applications) that use those protocols. Courtesy of the Packeteer website, I have included a picture below (in Figure 1) of some of the models of PacketShapers that exist.
Figure 1: Sample PacketShapers
There are a variety of models to accommodate networks of various sizes and complexities. Consult Packeteer or one of their resellers for a breakdown of the models and assistance in designing and implementing their solutions.
PacketShapers are bandwidth management and application performance devices that classify, analyze, control, and report on over 400 applications. It enables you to use its OSI layer 2-7 classification and analysis capabilities as a foundation for intelligently controlling your application performance. PacketShapers align each application’s performance with business objectives, allocating ample bandwidth to mission-critical Citrix applications and throttling back non-business-critical traffic.
HOW DO THEY DO WHAT THEY DO?
Packeteer PacketShapers allow us to protect and guarantee ICA/RDP session performance through a four step process.
Step 1 – Traffic Classification. PacketShapers can be deployed in a “monitor only” mode or a “monitor and shape” mode. Traffic Classification is the process of looking at ALL traffic (layers 2-7 of the OSI) and interrogating the type of traffic, HTTP, SMTP, etc. BUT, it goes MUCH deeper than simply identifying the protocols discovered. The solution can also look inside packets to investigate what the packet is transporting. For example, instead of simply identifying a packet as ICA, PacketShapers can look inside the non-encrypted packets and determine the actual PUBLISHED application, Word vs. Excel for instance. Imagine the power of creating SLAs that protect ICA from “mean” network traffic and then taking it FURTHER to say that Excel is “more important” to the company’s business objectives than Word and throttling the performance accordingly!
Step 2 – Behavior Analysis. Behavior Analysis allows for detailed reporting on various traffic patterns, bandwidth consumed, etc., to provide the answer to the question, “Why is Citrix so SLOW today?” We can look at real-time and historical reports and graphs to determine if the tremendous amounts of peer-to-peer file-sharing apps are REALLY impacting our business critical applications!
Step 3 – Performance Control. Performance Control is, in my opinion, the major reason for implementing the solution. This is the end-game feature that will PROTECT and GUARANTEE our ICA/RDP traffic on the LAN/WAN. This feature allows for the protection of ICA/RDP, latency-sensitive protocols, against the more bursty-natured protocols such as SMTP, FTP, HTTP and the like. More over, PacketShapers can look deeper into the traffic; inside the non-encrypted ICA packet to make policy arguments such as printing should be faster for our financial and billing Published Applications than printing from our Word Published Application.
Step 4 – Reporting. Reporting is the feature that no true enterprise solution can live without! And there is nothing finer than the ability to create dynamic, real-time reports with graphs and charts outlining performance with nothing more than a couple of mouse clicks! You can also look at the historical performance to allow some WONDERFUL trend-analysis… “Why is Epic slower today than last Friday when I used it?” – (Now you can answer the question with something more factually based instead of the quickest witticism you can dream up about the user’s incorrect operation of the computer being the root of the problem!)
Performance Control (Or Why We Came to the Party in the First Place!)
So we have mounds of traffic classification data, lots of nice reports on WHERE things are breaking and WHY… now is the time to implement some “control” within the traffic to guarantee and protect the ICA/RDP traffic. Packeteer implements this with a feature called “partitions”. Partitions are a “virtual pipe” inside the actual bandwidth available and come in two flavors, Hierarchical and Dynamic. Figure 2 below depicts the TOTAL link in the dark blue with the various smaller differently colored “pipes” representing partitions.
Figure 2: Bandwidth “Partitions”
Hierarchical partitions are useful for creating preset virtual pipe percentages, such as 20% for HTTP for all connections. I enjoy using this type of partition to carve out specific amounts of bandwidth for a given traffic type.
Dynamic partitions are used on a “per-user” basis to guarantee a predetermined amount of bandwidth for a given user, such as 60kbps for Citrix traffic, regardless of which published applications a user may use.
Additionally, partitions can be configured as “burstable”. Burstable partitions allow a partition to consume MORE bandwidth if more bandwidth is available. For instance, suppose it is 2 a.m. and there is NOTHING else on the link, why confine Citrix traffic for a given user to just 60kbps if the full link speed is available?
A final concept to understand about PacketShapers is a Rate Policy. A Rate Policy is in some ways the REVERSE of a partition. A rate policy is more dynamic in nature and in many ways more useful to controlling and protecting ICA and RDP traffic. Rate Policies allow for a MINIMUM amount of bandwidth to be granted to a type of traffic (and that can also burst) but not necessarily confined a particular user. This can be combined with testing and reporting to determine, for instance, that your ICA/RDP sessions perform at an acceptable level with perhaps a minimum of 30kbps of bandwidth. A Rate Policy could be used to set this as the minimum for ICA/RDP ANYTIME it occurs on the link. The PacketShaper would dynamically throttle back the OTHER traffic on the link, thus protecting and guaranteeing the ICA/RDP session performance.
While this is not meant to be the final word on third party solutions, Packeteer makes a solution that is easy to implement, support and maintain. Cisco and other vendors make similar if not competing solutions, but I am a big fan of those products that “just work”.
We have taken our final look at bandwidth management and explored how a particular third-party solution, Packeteer’s Packetshapers, can be leveraged to protect and guarantee session bandwidth for RDP and ICA. This article, combined with practices from the first and second in the series allows a server-based administrator to create a service level agreement for the presentation layer protocols that aligns with business objectives and presents the user population with a consistent performance level for their ICA/RDP session, regardless of the competing traffic that may exist on our links.
For more information on Packeteer and their bandwidth management solution, please refer to their solutions around Citrix (and RDP) at http://www.packeteer.com/prod-sol/solutions/citrix_screens.cfm.