Vendors choose to tout disparate application-acceleration techniques

In the emerging market for application-acceleration devices, there’s inevitably going to be confusion about what constitutes a base feature set.

To help establish apples-to-apples features comparisons among products in our inaugural performance test (see test results), we circulated a survey to participating vendors (Array, Crescendo, Citrix, F5, Foundry and Juniper) asking them to pinpoint what each offered in terms of Layer-7 switching, URL inspection and rewriting, HTTP compression, caching, TCP offload and surge protection.

While most vendors already offer all these features, or have plans to do so in the near future, the priority they place on each varies widely. (See vendor priority chart). As we advised in our performance test, it’s wise to understand what kind of performance boost you expect from these devices, and go with the vendor that’s made the biggest investment in that particular area.

A complete summary of the survey results follows.

Layer-7 switching means a device uses application-layer criteria to determine where to send a request. This gives Web front-end devices more granular control over forwarding decisions than is possible with conventional Layer-4 load balancers. For example, if a given HTTP URL ends in “.html,” the request might be passed to a group of servers handling text content, while a URL ending in “.jpg” might instead go to a group of image servers. Layer-4 load balancers, in contrast, see only Web requests destined to TCP Port 80, so no further differentiation among server groups is possible.

F5 ranks Layer-7 switching as the top feature contributing to the success of its device at serving of Web content faster. Central to all content switching in F5’s BIG-IP Local Traffic Manager is its purpose-built network operating system – Traffic Management Operating System – and iRules, the vendor’s policy engine. This combination isolates clients from server-side flows with a proxy service, then inspects the packets to understand sessions in terms of application, browser, content and connection mode, and finally switches the packets based on rules defined in the iRules schema.

Foundry, Crescendo and Citrix all place Layer-7 switching at the top of the list of features, as well.

As part of the ServerIron’s HTTP Content Switching feature, the Foundry device can inspect both header and payload of all HTTP traffic. The ServerIron uses this information to filter, switch, redirect and load-balance packets and connections across back-end servers. A similar feature called Total Content Analysis provides the same capabilities for non-HTTP applications, including those based on DNS, Session Initiation Protocol, Financial Information Exchange protocol, Windows Terminal Services and RADIUS.

Crescendo’s Layer-7 switching – like all its feature components – is a hardware-based implementation using dedicated ASICs. While Layer-7 switching integrates and runs concurrently with other features the device offers, it runs its own module so as not to degrade performance of the other features. In Crescendo’s Layer-7 switching model, load-balancing decisions can be based on actual server load, such as the number of actual requests processed by the server, rather than estimation techniques that guess the server load based on other metrics, such as bandwidth or connection count.

Citrix says its device natively supports Layer-7 switching and does not push this function up the stack from legacy Layer-4 server load-balancing roots. The NetScaler Application Delivery system can direct client requests to back-end resources based on such Layer-7 attributes as language support, browser compatibility, device type, HTTP request method and URL domain and parameter values.

Array says its TMX5000 routes requests to the appropriate back-end resource based on anything from QoS information to cookie details to HTTP, TCP, SSL and DNS header and payload information. Moreover, the vendor says its device can do so at as many as 100,000 requests per second; Network World did not verify that claim in its test.

Juniper treats its Layer-7 switching as part and parcel of its AppRules adaptive content processing detailed below.

A logical step building on Layer-7 switching is URL inspection and rewriting to help secure networks and hosts. Because Web front-end devices must inspect URLs or other application-level content to make switching decisions as explained above, they also can take other actions, such as blocking malicious requests. F5 marketing officials argue that these two features are one in the same.

Most devices discussed here (other than Crescendo’s box which is supposed to pick up this capability by year-end) also can rewrite URLs. This is helpful in hiding information about the internal network. For example, sites built using Microsoft’s Active Server Page (ASP) technology can use Web front-end devices to rewrite all “.asp” filenames to “.html” instead. As a result, Web sites advertise less information to attackers as to what types of exploits they might try.

Foundry and Juniper both indicated in their survey results that content filtering/rewriting was a top feature contributing to the success of their devices.

As part of its HTTP Content Switching feature, the Foundry ServerIron does URL and header rewriting, insertion and deletion; tracks cookie persistence, insertion and deletion; performs HTTP client IP address insertion; and redirects HTTP requests for HTTP, XML, Simple Object Access Protocol and secure-HTTP connections. Likewise, its Total Content Analysis provides similar capabilities for non-HTTP applications. We did not test the latter.

Juniper’s content inspection and subsequent actions are grounded in the vendor’s AppRules adaptive content-processing feature. The AppRules language lets an administrator write rule sets that will dynamically change, delete or append any part of the HTTP stream, as well as make routing decisions based on any part of the HTTP stream. These rules can be very broad or very specific; further, the company contends there is no limit to the number of rules the DX platform can support. Anecdotally, Juniper says the DX platform has been deployed at high-traffic sites with as many as 1,500 rules applied, with no degradation in performance.

Citrix calls its URL inspection and rewriting feature Request Switching, and ties it very closely to its AppExpert policy engine. This combination allows the Citrix system to inspect URL information and direct valid client requests to the right server while blocking unauthorized requests to thwart application attacks.

F5 rolls up its URL inspection and rewriting capabilities into the above mentioned Layer-7 switching driving by TMOS, arguing that URLs are just another form of content it can inspect and handle appropriately.

HTTP compression, as its name suggests, allows these devices to put the squeeze on the application payload within each packet. Overall, it reduces network bandwidth consumption without degrading content quality and improves end users’ overall browser-based application experience. HTTP compression running on a Web front-end device offloads this processor-intensive task from back-end servers.

All devices tested except Foundry’s ServerIron support HTTP compression. (Foundry says it’s adding support this quarter with an upgrade to its operating system software.) Common across the HTTP compression implementations of these devices is support for the deflate (RFC 1951) and gzip (RFC 1952) compression algorithms. In addition, all of these products offer rules that allow users to define what should or should not be compressed to allow for browser incompatibilities.

However, according to our survey results, Citrix, Crescendo and Juniper, and to a lesser degree F5, have all placed a premium on their HTTP-compression implementations.

Citrix’s NetScaler Application Delivery Systems offers two levels: AppCompress, which is standard HTTP compression; and, AppCompress Extreme, which allows for differential HTTP compression. The latter, also referred to as “delta compression,” only transmits data changed since the user’s last request. Citrix says this technique accelerates performance as much as 44 times.

Crescendo’s compression engine is implemented in dedicated hardware, with no added latency. The company says the custom silicon allows the CN-5080E to compress traffic at as much as 1Gbps without affecting the performance of other features.

Array also offers hardware-based HTTP compression on its TMX5000, touting goodput rates of as much as 750Mbps. Array is beta testing a feature that will automatically disable compression for requests from clients on high-speed LANs.

Juniper says its DX 3600 not only compresses HTTP traffic but also handles browser idiosyncrasies that can interfere with optimal compression. The DX 3600 uses an auto-adaptive, content-aware heuristic engine that automatically decides whether to compress an object based on IP network or address, MIME type, directory or any part of the HTTP stream. It can further increase rendering speed by delivering the content through chunked encoding of HTTP traffic.

F5 says its Intelligent Compression feature dynamically works to apply compression where it will do the most good. For example, the BIG-IP understands which clients are on LANs and which come in over dial-up links, and compresses only HTTP traffic for the latter.

Some devices also serve as proxy caches, storing selected data from origin servers to speed delivery to clients. The combination of caching and compression can deliver a double benefit, because devices can return precompressed objects out of cache instead of retrieving them from origin servers. Caching can substantially boost transaction rates and reduce response times, while also freeing servers to do other work.

All devices tested except Crescendo’s provide some sort of support for caching, but only Citrix and Array placed a high priority on this feature in our survey. Crescendo says it plans to add caching support by year-end.

Citrix’s NetScaler AppCache caches both static and dynamically generated Web content, such as personalized Web pages or enterprise report data. Caching of dynamic content allows a Citrix box to accelerate performance for a more diverse set of applications. In addition, AppCache helps protect origin servers from sudden surges in client request. The feature also allows for automatic caching of precompressed data, and provides full Web logging of all cache hits.

Array offers an inline, memory-based reverse proxy cache called SpeedCache in the TMX5000 that is implemented in memory rather than on disk. The company contends this implementation offers three advantages: little latency is added because memory access is much faster than disk access; there is higher reliability, because there are no moving parts (such as disk subsystems); and there is a significant server offload gain.

F5’s Fast Cache also serves up both static and dynamic Web content. The company also points to the BIG-IP’s ability to set up multiple cache repositories as an advantage because administrators can carve out memory for specific groups of users or applications.

Juniper’s 3G Caching is built into the DX platform’s AppRules adaptive content processing, which also handles content inspection and switching. Juniper says integrated caching gives administrators greater flexibility in determining what content should be cached, and under which conditions.

Foundry says customers predominantly use external caching and Web proxy devices in conjunction with its ServerIron. Accordingly, the ServerIron offers a Transparent Cache Switching feature that redirects requests to external caches. Foundry says this eliminates the need for massive amounts of storage on the Web front-end device, which in turn boosts reliability and scalability.

All devices tested perform SSL offload and/or act as SSL VPN gateways. Either way, SSL support can boost server performance and increase content security by offloading compute-intensive encryption functions from servers. Common across most implementations are the abilities to terminate SSL sessions, to reencrypt sessions going to a back-end server if necessary, to manage client certificate and user authentication, and to handle bulk encryption tasks.

F5, Array and Crescendo all place high stock on SSL offload as a means of serving up content fast.

F5 says the BIG-IP’s SSL acceleration not only offloads encryption and certificate management from servers but also forwards SSL traffic at sustained rates of as much as 2Gbps. F5 says the BIG-IP uses custom ASICs for SSL key exchange and data encryption. Additionally, administrators can selectively encrypt only certain types of header or payload content after inspection.

Array also hangs its SSL hat on the fact that the TMX5000 SSL offloads both key exchange and bulk encryption tasks. Because this processing is handled in the Array OS kernel, Array says its TMX5000 can handle 20,000 SSL transaction/sec with a 128KB file.

As with other features, Crescendo points to dedicated hardware as an advantage for SSL offload. With custom ASICs handling both SSL handshakes and bulk encryption, Crescendo claims there is no degradation in the performance or functionality of other features.

Foundry offers customers multiple SSL offload modules. These modules come in four price/performance levels, and all can slide into the ServerIron chassis as SSL offload requirements increase.

Juniper says the integration of its SSL offload functions with its AppRules features is a major plus. For example, the AutoSSL capability allows the DX 3600 platform to terminate SSL connections for a complex application such as Microsoft Outlook Web Access, while simultaneously handling the content rewriting necessary for HTTP and secure HTTP headers.

Citrix, which also uses dedicated ASICs for SSL connection setup and bulk encryption tasks, points to policy integration as a competitive advantage. Through integration with its NetScaler AppExpert policy engine, the Citrix SSL Accelerator can be configured for optionally encrypt data to any back-end server, for example.

TCP multiplexing, supported by all devices tested, refers to the ability of a Web front-end device to offload TCP connections from servers by mapping a large number of client-side connections onto a smaller number of server-side connections.

Because TCP connection management imposes substantial processing overhead on servers, TCP multiplexing frees up servers to do other work, such as delivering more Web content. Properly implemented, TCP multiplexing can allow enterprises to use fewer servers to provide the same quantity of content at equal or higher performance levels.

Juniper ranks TCP multiplexing, which has been available with the DX platform for four years, as its most important feature in our survey. To speed client-side connections, the DX platform uses keep-alive messages to help ensure clients need to go through set up and slow start processes only once.

Crescendo says its Short Life Transaction (SLT) technology shields servers from TCP’s WAN-imposed complications (such as dropped packets and retransmissions) and instead provides servers with a LAN-like client environment. SLT buffers requests and responses, allowing servers to operate at their full potential and avoiding head-of-line blocking by dedicating different server-side connections to different kinds of content.

F5 takes a three-pronged approach to TCP offloading. Its OneConnect connection pooling mechanism offloads TCP session setup and tear down, extends HTTP 1.0 and 1.1 translations for connection pooling to clients that don’t natively support it and maintains full client connection logs. F5 also buffers requests and responses, optimizing connections to the back-end servers. F5’s TCP Express then optimizes TCP windows for WAN connections. Crescendo offers a similar client-side optimization technology called Fast TCP.

Foundry offers its Connection Offload feature as a software configurable option for customers who want to target Web services. In addition to TCP multiplexing, Foundry says the ServerIron can perform hitless failover of TCP connection state should one of a pair of ServerIron boxes fail. This ensures clients won’t have to reconnect even when the connection-multiplexing feature is in use.

Citrix says its TCP multiplexing works together with its Request Switching engine, tracking the precise moment when transactions complete so that connections can immediately be reused.

Array’s TMX 5000 offers a Connection Multiplexing facility, but the vendor did not provide technical details.

Under this category, we found many names for the mechanisms that protect servers against the kinds of surges enterprises like (a rush of new customers) as well as those they don’t like (a distributed denial-of-service [DDoS] attack).

Juniper’s Transaction Assurance capability handles the effects of “flash crowds” (sudden surges in the client population) by dynamically increasing the number of static connections from the DX platform to origin servers. The DX platform also can limit the maximum number of connections to an origin server to protect it from traffic spikes. The DX platform also uses SYN cookies and SYN caching to help thwart distributed DoS attacks.

Array points to its Webwall application firewall in its TMX5000. Citrix referred to its Request Switching feature for surge protection, arguing that this feature can see when a server becomes overloaded by a surge of requests and switches future requests away from it.

Crescendo refers to a similar server health-monitoring feature called “Application Assurance” to help fend off attacks. Crescendo says Application Assurance can distinguish between what’s normal and predictable for servers, and an attack. The feature recognizes when any one server application becomes overwhelmed and buffers overload requests until the application becomes available again.

F5 says its SYN Check algorithm searches and blocks distributed DoS attacks as they reach the BIG-IP device. F5 also points to its Application Security Module application firewall as another mechanism that protects against other HTTP- and secure HTTP-based threats. Additionally, a rate-shaping feature lets BIG-IP customers define per-application, per-protocol and per-user traffic and application limits.

Foundry’s SYN-Guard is hardware-assisted protection against SYN/ACK floods and 30 other DoS attack signatures. It too offers rate limiting to further thwart attacks.