WAN Optimisation Products, in the Network Performance / WAN Optimization forum on BrianMadden.com

Hi folks,

I have a central HQ site with 4 branch offices, each branch office is distributed accross the globe, most with fairly high latency connections. Each branch office is connected to the main HQ via a VPN.

I use a citrix server to distribute applications from the HQ.

I also have a packeteer, packetshaping at each site.

I want to try and speed things up, is Cisco's WAAFS the only appliance which will speed up Citrix traffic?

Also, I may well be looking at more data than just citrix traffic to traverse my VPNs and so am looking at Riverbed, and Bluecoat ProxySG systems, does anyone one have any prefernces there? and why.
Bluecoat have made some improvements recently to their product, so, it is winning with me so far.

I plan to get a demo of each piece of kit.

Also, as Bluecoat have purchased packeteer, could it be worth waiting to see how they integrate the iShaper product into the bluecoat systems? or has that been done already?

Look forward to your responses
J

We looked at BlueCoat and decided to not go there.

Although the recent acquisition of Packateer makes it very appealing, it won't be available for use with their stuff until the end of 2009.

We found out that unless you buy the top end model ($$$$) from BlueCoat the unit you buy is the same version as the next one up with the only difference being the processors are intentionally throttle down and capped. When we contacted a peer of ours who went through a BlueCoat install, they recanted a horror story of bad installation and perfomance after the fact with the end result being an engineer from Blue Coat being sent out to totaly rip out the newly installed, and replace it with an upper model. IMHO its a poor design which is too bad as there are a lot of things that are appealing and have potential.

Friend of mine uses Packateer with Riverbeds....no issues mixing the two.

We are still undecided on some of the other vendors but Silverpeak & Riverbed are still fron-runners. Not really looking at Citrix WanScaler.

Any WAN accelerator will speedup Citrix TCP/IP traffic.


-Mark

Hi,

You might also want to take a look at the new player Replify in the wan optimization market. They have a complete virtual and software solution for Application Acceleration. There great advantage is not having the need to ship hardware to all the locations. The virtual environment makes it easy to expand and move Virtual Appliances. Based on what application the user is using acceleration can be done.

- Marcel.

Hey guys,

First off I wouldn't waste your time with Riverbed on interactive traffic, their technology relies on hard-drive based block level caching which is both too macro an algorithm for thin Citix streams and also introduces too much latency to the transaction. (slowing down user experience) They're great on large data movement and point solutions like MAPI acceleration, but they simply bypass interactive and latency sensitive traffic over their devices.

Bluecoat, even with recent acquisitions also has similar technical challenges when working on latency sensitive real-time apps like these. The Packeteer product is terrific, but it's a packet shaper alone, and we all know congestion and traffic priority are not the sole root-cause of Citrix performance and scaling issues. (not to mention how long it will take Bluecoat to build a single integrated solution for you, if ever)

Mentioned on these forums before by others before me, Expand Networks not only has memory based (non-latent) compression, a QOS system close to Packeteer's, and caching - but also has Citrix and MS Term Services plug-ins. They multiplex interactive traffic sessions and match/compress across all the sessions at once. They see significant reductions in traffic size, but more importantly fast track packets to the wire.

Again, I'm not going to push advertising here, by all means I suggest a pilot of your top options. But for a long list of technical reasons you would be doing yourself a disservice not to check out the information and case-studies at Expand's site. Expand has been accelerating Citrix traffic for over seven years, they partnered directly with Citrix originally to accelerate their WAN deployments and then Citrix ran off and bought the wrong company for the job!(Orbital)

Expand is not losing a single competitive interactive traffic acceleration deal, there's a reason why.

Marcel, Expand also has a VM based offering as well, just FYI

-Mike

Disclaimer: I work for Expand Networks now, but have years of experience at VARs implementing all the major WAN Accelerators.

I'll assume that the inter-site VPN's happen on your internet routers, so that all remote site traffic is "cleartext" by the time it gets to the Packetshapers & potential compression product.

A few things to consider here:

a) Can Citrix ICA actually be accelerated?

There are several aspects to "acceleration", including compression, increasing the "window size", fast ramping, and making CIFS work faster. ICA traffic is already compressed & encrypted by the Citrix XenApp server (= presentation server), so there is little gains to be had there (note 1). ICA is not known as something that typically sends huge amounts of data, so the issues of window size are less likely to be an issue. It's not CIFS, so we can forget THAT one.... Fast Ramping is where we locally increase the initial window size very rapidly (we can do this because we KNOW what bandwidth is available): this *can* help ICA, in that the small number of packets needed to repaint the screen will get down the wire a bit quicker.

So there's not actually a lot we can currently do with JUST ICA traffic (but see Note 1!)

All of the above relate to ALL compression products....

(note 1) However, given that Citrix "owns" ICA, I'm sure we will see some clever things happening, that will allow the ICA session to work out that it's using a WANScaler, and let the WANScaler do the compression & encryption (which WILL give better compression, as it will allow "cross-fertilisation" between sessions)... of course no other products will be able do this sort of thing.

(worth adding that some product vendors will suggest simply "disabling compression and encryption on your Citrix servers"... I'm told that this is no longer a trivial thing to do.... and besides, do you REALLY want to globally diable your ICA encryption?)

b) how do I combine Packetshaper with an external compression product?

Not easy... the problem is that Packetshaper needs to know the available WAN bandwidth... If we put Packeshaper behind the Wanscaler (or any other product for that matter) then the avalable bandwidth can vary, moment to moment, depending on the compression etc. If we put packetshaper in front of the WANScaler etc, the whilst it will now see the raw wan (static) bandwidth then it may not be able to correctly work out the traffic type (certainly not for Expand, Riverbed etc... they all use tunnels!)...

The Wanscaler works a bit differently, in that it retains the same ports, and doesn't do anything to the packet headers, but just compresses the payload... not sure if that's enough for the Packetshaper to classify traffic 100%.

c) Why not just use Packetshaper compression & acceleration?

Doing this certainly gets around the problems in (b), as it knows the WAN bandwidth. Packetshaper "compression" is obvious, "acceleration" it to do with increasing that window size.... so the bit that is missing is the CIFS improvements (which is why they bought the Tacit product).

The missing bit is that the ICA is still encrypted & pre-compressed, and I believe Packetshaper still can't sub-categorise the citrix traffic when using session reliability (ok for the old "port 1494" stuff though) - Wanscaler CAN do this.


d) QoS issues

There is no doubt that Packetshaper is THE #1 QoS product.

For simple site-to-site links though, you might find that the queuing used by Wanscaler (and other products) is enough to make things work fine (in which case, you ignore the packetshaper!).

However, in your case, we're talking VPN's, so there is also a load of internet traffic that the Packetspaer controls (which Wanscaler etc can't do anything with).


So, there's no simple answer to the question, but hopefully the above have explained the issues.


Let me also put my cards on the table: I have worked with (and trained) Packetshapers up until a year or so ago (and will again be working with them, as we cover Bluecoat products). I have worked with (& trained) Wanscalers since Citrix took them over. Historcally also supported the Expand & Peribit (now Juniper) boxes too. Hopefully I have managed to keep the above reasonably true and neutral!


Paul B

Paul,

Some good points in there, but I have to correct you on a couple of your blanket statements.


Not sure how closely you've worked with Expand, honestly, because they blow away native Citrix compression numbers and there IS a lot you can do beyond single session compression in Citrix.

The fact that an entire site's sessions, en-mass, are being analyzed for byte level caching result in significant compression numbers over a standard Citrix compressed session. Expand also uses "packet aggregation" technology that is Citrix specific (understands Citrix headers etc) which also has demonstrable impacts on total compression of Citrix streams and number of round-trips being taken.

To achieve this Expand does require native compression gets turned off in Citrix. The nice bi-product of that is that it reduces server loads and allows more users to be hosted. I myself installed an Expand box at a Citrix user site that was at server and network capacity. Four months later they had doubled the Citrix users in the environment and hadn't upgraded a thing, it was Expand compressing the Citrix, mitigating congestion and latency, and off-loading the Citrix server itself.


-M

Also just FYI-
Bluecoat has DROPPED the Tacit (i-shared) product actually, they're yanking it from all the existing customers and dropping support on it from what I'd heard. Correct me if I'm wrong.

Michael

I agree 100%... if you disable the Citrix ICA compression & encryption, then probably *any* compression product will give an improved compression, as you say, gained from the fact that your compression is now acoss a LOT of users, rather than just ONE user.

The feedback I've had from Citrix PS techies is that disabling the compression is not as simple as it used to be (please correct me if I'm wrong here, happy to learn!). Also, in some environments, the customer might not like the idea of disabling that encryption. (Can the Expand products encrypt the compressed data stream?)

Funnily enough, the gains on the server (by no longer having to compress & encrypt) is a thing that often gets forgotten about (and is one of the *netscaler's* purposes in life, for web servers!).

Going back to the original issue though, there's STILL the problem of matching the "effective WAN bandwidth" of the compressed link between the "compression box" and the Packetshaper.


(and interesting to hear about Bluecoat dropping iShared... to be honest, not a huge surprise, it was an "overkill" solution in many ways)


Paul

Hey Paul,

Appreciate your response.


Actually not just any compression device can't work with this traffic, you need something with memory based caching so it's fast enough to not add latency to the traffic, so that's a tricky game. Cisco also has memory based caching, but they've got a bunch of clean-up to do on their WAAS stuff IMO... I've only competed against them but it's taken several engineers many days to get those things up.

Ok... so the packetshaper issue. I personally would do 1 of 2 things with it. Place it prior to the accelerator in the clear traffic side and not use it for anything but traffic shaping. If you leverage it for some specific QOS function that is just irreplaceable.

Or option two, I'd force the vendor that proved best on the traffic to give me some kind of buy-back deal and be sure their QOS was good enough for what I needed.

OR... as you did point out, just go with the status quo, but why not test one or two solutions and see if they make life/performance/scalability easier?

-M

p.s.
And yeah, Expand has 3DES and AES256 encryption point to point on the compressed stream.

Michael

I was just looking at Citrix article CTX113505, where it says a couple of things that seem to be at odds with what you are saying.

"Fact C: Encryption or data scrambling cannot be disabled in Presentation Server through the supplied administration tools. The administration tool only allows encryption to be set to one of the following: Basic, 40bit, 56bit, and 128bit. Even Basic encryption still scrambles the data, thus it is still encrypted."

So how DO you manage to suitably disable encryption in PS4.5, so that Expand / others can compress it? Or *is* it now a "problem" with PS4.5? (I'm asking because this sort of thing comes up when I'm giving training.... but I'm an "appliance" person, not a "PS" person)

You also mentioned that disabling compression & encryption decreased CPU workload, allowing more users (which makes a LOT of sense, we say the same ething for SSL offload on netscalers), but the article then says:

"If one was able to disable ICA encryption and compression, there would not be an increase in single server scalability. The CPU utilization savings one would see by disabling these ICA features would be offset by the increased workload on the CPU for putting more data onto the wire."

(to be honest, I think the author is pushing his luck there.... the workload of doing compression & encryption is a LOT more than the workload of putting even 5 or 10 times the amount of data onto the ethernet (in fact, most of that workload will be handled by the LAN card!!!)



Paul

Paul,

Good questions and well put.

As I've experienced and understood, just like with RDP and the “Low” Encryption setting, “Basic” encryption within PS only encrypts the data sent from the client to the server not server to client. So we don't disable with 4.5, we set basic.

I'd believe that the server CPU load being relieved from compression is negligible as the algorithm is pretty weak. Encryption is a different story, performance will certainly be affected by the CPU load increase in scale with the level of client encryption.

Here is some info from a Microsoft document I found quickly speaking about RDP (should also apply to ICA):



On Encryption:

“…In terms of a performance hit, encryption requires a significant amount of CPU time. For example, a resource intensive slide show on a 233 MHz CEPC uses more than 15 percent of the time on decryption and on a 1.8 GHz CEPC, about 3 to 4 percent.”


On Compression:

“From the data flow diagram, this decompression occurs when the client receives a bitmap cache order or a bitmap cache miss occurs. When running a resource intensive slide show on a 233 MHz CEPC, there were no bitmap cache misses. The profiler also shows that this decompression did not use very much of the CPU. However, when running a less resource intensive slide show, the CPU spent 15 percent of the time in bitmap decompression.”

The entire document: http://msdn.microsoft.com/en-us/library/bb931330.aspx#opp_14


Expand has a ton of resources and actual case studies on optimizing SBC traffic and scaling environments if you're interested, contact me off forum for some if you'd like.

As to where Citrix will be going with ICA in the future... time will tell. But the more they close the protocol the less the community is going to want to work with it.... that's been a consistent trend in IT I think we'll agree.

I'll be at VMworld in Vegas if you will be, swing by the booth.

-M