Tim Greene over at Network World has just posted a great article titled The ABCs of WAN Optimization Savings. The article walks through the various functions of today's WAN optimization devices and how these technologies add up to big savings for IT. Citrix is singled out in the article for our dominance in speeding up virtual desktops and applications, something we have offered since delivering ICA acceleration with Branch Repeater 5 back in February.

As part of the HDX technology framework, Branch Repeater includes a suite of WAN optimization technologies that have been adapted for virtual environments. Since the underlying WAN optimization technologies are discussed in the Network World article, I will explain how Branch Repeater is unique in applying these to accelerate and optimize virtual desktops and applications.

Compression and caching - By default, XenApp compresses all ICA traffic to optimize individual user sessions. Branch Repeater automatically negotiates with XenApp to disable the native ICA compression in order to cache common graphics and data locally in the branch and compress traffic across multiple user sessions. Branch Repeater is the only WAN optimization solution that can inspect the ICA virtual channel to help determine whether to store cached data objects in memory or on disk. This helps to minimize latency for interactive traffic (screen updates, mouse movements) while maximizing compression ratios for bulk transfers within ICA (printing, file transfers).

TCP acceleration - Like any TCP-based traffic, ICA performance can suffer due to high latency and packet loss common on long distance WAN connections. Branch Repeater overcomes these issues with adaptive TCP flow control that senses these conditions and responds by optimizing TCP behavior.

QoS and traffic prioritization - In many networks, ICA shares the wire with other bandwidth hungry applications. Network congestion can 'starve out' ICA traffic causing slow and inconsistent performance. Branch Repeater prioritizes traffic and allocates bandwidth to ensure reliable, high-performance for virtual desktops and applications. However, not all data transmitted within ICA should receive equal priority. For instance, interactive screen data should be prioritized above print jobs. To address such conflicts, Branch Repeater provides the only ICA-aware QoS engine that can granularly allocate bandwidth based on virtual channel priority tags.

Branch Repeater ICA acceleration goes beyond optimizing each of these core technologies for virtual desktop and application delivery. Virtual environments tend to be far more dynamic and flexible than traditional enterprise applications. For this reason, Branch Repeater is fully integrated with XenApp and other HDX technologies to apply the right mix of optimizations for every scenario over any network. And since many of the techniques involve peering inside the ICA session, Branch Repeater works with native ICA encryption (Basic and Advanced RC-5) so there is no compromise to end-to-end security.

The Network World article wraps up by suggesting that businesses consider WAN optimization gear when deploying new applications. Rolling the cost of WAN optimization into a larger IT project - such as desktop virtualization - can be a cost-effective way to pay for the solution. So if you are considering deploying virtual desktops (VDI) in your organization, be sure to include Branch Repeater as part of your plans.

Take this quick survey to tell us more about the solutions your organization uses to optimize your WAN. 

HDX MediaStream does a fantastic job of reducing the network bandwidth requirements for streamed video compared with rending the video on the server. When using HDX MediaStream your bandwidth requirements roughly equal the bit rate of the source video file. For lower quality clips, like those found on YouTube, this is around 256Kbps. For full HD content the bandwidth requirements can be as high as 8Mbps.

While this works great over a high speed LAN, trying to push that amount of data over typical branch office T-1 is another story. This problem is magnified even more when you have multiple users in the branch office who are repeatedly pulling down the same video content. In this situation, the video quality suffers and other business applications can be impacted. This issue has nothing to do with XenApp or XenDesktop. It is purely a function of the size of video file and the limited amount of available network bandwidth.

What can you do about this? Well if the culprit is the latest viral video making its way around the Internet you could attempt to block access to sites like YouTube. However, what if the video is for legitimate business purposes? I talked to one customer at Synergy who is rolling out a corporate compliance training video to their entire company using XenApp but is worried about the impact to network bandwidth.

Enter Citrix Branch Repeater and HDX IntelliCache. With Branch Repeater 5 we now participate in the ICA session and accelerate the ICA virtual channel used by HDX MediaStream. The first time the video is streamed to the branch office, Branch Repeater caches the content locally. The next time the video is requested, Branch Repeater serves the content from its local cache rather than pulling it across the WAN. Using branch caching, you can reduce the bandwidth requirements for on-demand videos by up to 90%.

Don't just take my word for it. You can see a demo if this in action on the latest edition of Brian Madden TV. (If you don't want to watch the entire episode you can jump ahead to 5:49 into the clip).

Have you been hearing about the new Citrix HDX Technologies? Have you heard that HDX enables branch office users to get that "high definition" XenApp experience? Are you still trying to figure out what this all really means?

• What is driving branch offices to virtualize their applications
• What are branch offices doing about the WAN
• What Citrix Branch Repeater does for XenApp
• How HDX Broadcast and HDX IntelliCache deliver a high-def branch experience

The whitepaper (CTX120455) is available for download on the Branch Repeater section of the Citrix Knowledge Center.

HTTP Callouts

New in NetScaler 9.0 is the ability to perform a callout using HTTP to an external server. An HTTP Callout is a means to process incoming packets on the NetScaler using an external service that can be a virtual server on the NetScaler itself, a back-end server, or an third party service.

Traditionally, the NetScaler used to verify these packets internally using in-built policies but with specialized services being available for validation, they can be integrated with the NetScaler using this feature.

An HTTP callout will consist of a NetScaler policy expression that can send a simple HTTP request to an external service, wait for the response and then parse the response to produce a simple result. The result will then be used like any other policy expression evaluation result.

The HTTP callout expression:

SYS.HTTP_CALLOUT(<name of HTTP Callout>)

To define the HTTP callout:

set policy httpCallout <name>
	[-IPAddress < ip_addr|ipv6_addr>]
	[-port <port>]
      	[-vServer <string>]
	[-returnType <returnType>]
	[-httpMethod ( GET | POST )]
	[-hostExpr <string>]
	[-urlStemExpr <string>]
	[-headers <name(value)> ...]
	[-parameters <name(value)> ...]
	[-fullReqExpr <string>]
	[-resultExpr <string>]

Where:

-returnType must be one of TEXT, NUM or BOOL.

-IPAddress IP address of the server to which callout is made

-port Port of the server to which callout is made

-vserver must be one of the vservers added using the "add lb/cs/cr vserver" command. The service type of the vserver must be HTTP.

-httpMethod could be GET or POST.

-hostExpr Complex PI string expression for value of the Host header.

-urlStemExpr Complex PI string expression for generating the URL stem.

-headers Every header name must have a corresponding value. These headers will be inserted in the request. Header name is string. Header values are Complex PI Expressions.

-parameters Every parameter name must have a corresponding value. These parameter names are put in the URL query if the request has a GET method or they are put in the body if the request has a POST method. One must not rely on the order in which the parameters are inserted. Parameter name is a string. The parameter values can be computed using Complex PI String expressions. The parameter values will be URL encoded.

-fullReqExpr A complex PI String expressions computes the entire request. It is the user's responsibility to provide a well formed and sane HTTP request. The system will not do any sanity checking. If full request is specified then none of the other arguments can be specified.

HTTP callouts are available with HTTP or TCP Content Switching, Responder and Rewrite functionality.

The basic communication flow for HTTP callout is:

1. User sends request
2. Policy sends HTTP request to an external service
3. Result used like any other policy evaluation result
4. Available for multiple features

HTTP Callout Deployment Scenarios

The examples in this section illustrate how to use HTTP callouts to perform various tasks. In all cases, the NetScaler performs a callout to an external server where a callout agent is configured to respond to the request from the NetScaler based on the data that is present on the external server.

This section describes how to configure HTTP callouts in the following scenarios:

1. Filter clients based on an IP blacklist.
2. Fetch and update content on the fly using Edge Side Includes (ESI) markup language.
3. Authenticate users and control access to resources.
4. Filter Outlook Web Access (OWA) spam.

Filtering clients based on an IP blacklist

HTTP callouts can be used to block requests from clients that are blacklisted by the administrator. This list of clients can either be a publicly known blacklist or one that is maintained specifically by the administrator or a combination of both.

The source IP address of the incoming client request is checked against the external pre-configured blacklist and based on whether the IP address has been blacklisted or not, the transaction is either blocked by the NetScaler or the NetScaler continues to process the transaction normally.

The HTTP callout feature facilitates this by allowing the NetScaler to communicate with the external server that maintains a database of such blacklisted IP addresses.

The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.

ESI support for fetching and updating content dynamically

Edge Side Includes (ESI) is a markup language for edge-level dynamic Web content assembly. It helps in accelerating dynamic Web-based applications by defining a simple markup language to describe cacheable and non-cacheable Web page components that can be aggregated, assembled, and delivered at the network edge.

Using HTTP callouts on the NetScaler, you can read through the ESI constructs and aggregate or assemble content dynamically.

The following outlines the requirements to implement this configuration:
1. Enable Rewrite on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Rewrite action to replace the ESI content with the callout response body.
4. Bind the Rewrite action to a Rewrite policy.
5. Bind the Rewrite policy globally on the NetScaler.

Access Control and Authentication

In high security environments, it may be mandatory to externally authenticate a user before a resource is accessed by clients. On the NetScaler, you can use HTTP callouts to externally authenticate a user based on supplied credentials. There are different ways that authentication credentials might be supplied; the client could be sending the user name and password in HTTP headers in the request, or, the credentials could be fetched from the URL or the HTTP body.

The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.

OWA-based spam filtering

Spam filtering is the ability to dynamically block emails that are not from a known or trusted source or has inappropriate content. Spam filtering requires business logic that indicates a particular kind of message is a spam.

Using HTTP callouts, you can take out any portion of the incoming message and check with the configured external callout server that has the rules to detect if the message is a legitimate email or spam. In case of a spam email, the sender will not be notified that the email is marked as spam because it will only alert spammers to modify their messages.

The following outlines the requirements to implement this configuration:
1. Enable Responder on the NetScaler.
2. Create an HTTP callout on the NetScaler and configure it with details about the external server and other required parameters.
3. Create a Responder policy to analyze the response.
4. Bind the Responder policy globally on the NetScaler.
5. Create a callout agent on the remote server.

Read about the Citrix Application Switch with Version 9.0 here.

Try the Citrix Application Switch with Version 9.0 here.

Tap into the power of AppExpert!

Monitoring the Wanscaler This is the fouth video in the four part series of configuring a Wanscaler environment for FTP demonstrations. The first in this series is Configuring the W2K3 machine. The second is configuring the XPclient, third is configuring the Linktropy Wan simulator, and fourth is monitoring the Wanscaler

Configuring the XPclient. This is the second video in the four part series of configuring a Wanscaler environment for FTP demonstrations. The first in this series is Configuring the W2K3 machine. The second is configuring the XPclient, third is configuring the Linktropy Wan simulator, and fourth is monitoring the Wanscaler

Configuring the W2K3 server for FTP transfer. This is the first video in the four part series of configuring a WanScaler environment for FTP demonstrations. The first in this series is Configuring the W2K3 machine. The second is configuring the XPclient, third is configuring the Linktropy Wan simulator, and fourth is monitoring the Wanscaler.

This is the second video in a two part series showing CIFS acceleration over a WAN link using Wanscaler. This video will demonstrate the amount of CIFS optimization that occurs in a Wanscaler environment. 

 Here is a video demonstration of Microsoft CIFS acceleration over WanScaler. Equipment used for this demo were Microsoft W2K3 server, an XP client, and a Linktrophy Apposite WAN simulator.

Although, the demonstration seems very simplistic CIFS acceleration represents a milestone in WAN acceleration and data networking, in general. CIFS is the protocol that is used by Microsoft Servers and clients to exchange information. The protocol was originally designed to function over a LAN environment with a minimum of 10 Mbps throughput, half-duplex. As enterprises began expanding their data services to remote offices CIFS, designed for a LAN was being used over low bandwidth, high latency WAN's. Performance and end-user experience vary greatly in this enviornment, and the protocol provides a very high, inefficient overhead. With an accelerator between the remote and central office, TCP transmissions are optimized and thus the protocol is streamlined. Users can now experience LAN like performance while being thousand's of miles away from HQ.

h.1 Watch this videotip