Today’s post is brought to you by the logical fallacy “False Dichotomy”

thoughtful_thumb[1]_thumb_thumb_thumbGenerally speaking we don't respond to competitive commentary that's purposefully antagonistic. The reasons for that vary from corporate culture to the annoying reality that responding confers upon the claims some measure of veracity that it generally does not deserve.

But even technical agitprop can raise points that need to be addressed with respect to the underlying premises upon which the arguments are made. Of late, certain claims coming from Citrix has brought these premises to the fore, and those premises deserve to be addressed.

Issue: Consolidation 

Consolidation is an interesting word, generally taken to mean “to unite into one system or whole; combine.” In the context of application delivery this means one of two things. First, it can mean to consolidate application delivery controllers, i.e. reduce the number by combining onto a single, higher capacity instance (device). Second, it can mean to consolidate application delivery services, which also effectively reduces the number of devices in a data center by migrating their services to a higher capacity, unified solution.

In the case of an argument made by Citrix, it refers only to the first definition – the combining of multiple ADCs into fewer, higher capacity ADC systems. This allows them to make some interesting claims with respect to having a higher density (of ADC instances on a single device) and a more functional architecture. It would be ill of me  too take Citrix too harshly to task for some of its claims, as such were made further in the past at a time when some claims may have had more veracity (BIG-IP WebAccelerator was only recently made available in a virtual edition, for example, so Citrix statement that it was not was, at the time, true) so we shall focus on those claims made that at the time were based on faulty logic and assumptions.

Citrix claims that because of incomplete features, F5 cannot consolidate ADCs as effectively as it can. This ignores completely the second of the types of consolidation we see in data centers every day, that of ADC service consolidation, and focuses solely on physical device consolidation. For example, ignoring that (yet again) Citrix has declared a feature “necessary” or “critical” and then based other arguments on that premise, it makes the claim that F5 vCMP has incomplete ADC isolation:

Although F5’s vCMP technology isolates CPU and memory resources between guests, it does not allow customers to dedicate SSL processing resources per guest. Consequently, a single vCMP guest can potentially starve adjacent tenants of SSL resources, resulting in much higher application latency or dropped sessions.  

Citrix should have stopped at the first statement, which is accurate. vCMP does not today allow per guest SSL processing, because its conclusion is made based on a False Dichotomy, the assumption that there are only two possibilities when there are, in fact, other means of ensuring that one vCMP guest does not starve adjacent tenants of SSL resources.

While BIG-IP does not provide the ability to allocate SSL resources to each instance, the methodology that we use for managing SSL and compression multiplexing ensures that no instance can starve another. Each instance using SSL is load balanced internally, against available SSL (and compression) resources. This means that if four instances are using SSL, each is allocated approximately 25% of the available resources. This allocation is dynamic, as well. If three guests aren’t leveraging SSL but a fourth guest is, it will be allowed to use the SSL resources not in use by other guests, subject to CPU limitations, of course. This ensures that no single instance can “starve” another, even without the ability to dedicate resources. It also allows sharing of the hardware across guests such that resources are not sitting idle when not in use by a guest instance. 

We also question the definition of “feature” parity with respect to Citrix’s own offerings. A virtual (software) edition cannot match 100% feature parity with any hardware version of the same when hardware acceleration for any function (SSL, compression, TCP offload, etc…) is in use. It is also nearly impossible for a virtual edition of any product – let alone an ADC – to tout compliance with strict security standards such as FIPS 140 at levels that require tamper-proof device security. Software alone can never be “tamper proof” while hardware devices can (and are). As Citrix own solutions do take advantage of SSL hardware acceleration (see March (Marketing) Madness: SSL TPS versus Bulk Encryption), we find claims of 100% feature parity to be questionable.

The reality is that F5 is moving steadily to ensure that all product modules can be deployed in a virtual form factor and can ultimately be deployed as a guest vCMP instance. BIG-IP WebAccelerator and WAN Optimization Controller were recently added, which rounds out support for the BIG-IP family of solutions. This enables the use of F5 technological innovations such as ScaleN and iApp to provide a more robust, flexible set of options in which organizations can architect solutions that meet their specific needs, including those involving consolidation efforts.


Citrix goes on to make much of isolation, but stops at CPU, memory, and SSL. What of the network? What of application fault isolation? With ScaleN and vCMP, a single application requiring fail over cannot force the entire device to fail over to a secondary. Instead, BIG-IP version 11 introduced the ability to fail-over (and conversely scale out) at the application layer, providing greater flexibility and providing greater assurance of availability of all applications. At the network layer, F5 BIG-IP supports route domains for both IPv4 and IPv6, offering network-layer isolation that supports even the most IP-sensitive of applications, those which even virtualization experts will suggest must be deployed “from scratch” when moving from network segment to network segment, destroying the value proposition of cloud and virtualization for many organizations. This feature enables unique solutions that address real issues with emerging models, such as cloud bursting and migration of enterprise applications to support business continuity efforts.

Citrix makes a lot of noise about supporting “advanced” ADC features, but fails to recognize that application delivery consolidation is as much if not more about consolidation of application delivery services into a unified strategic point of control at which key operational risks can be more efficiently and effectively mitigated. F5 has been, and will continue to be, as concerned about effectively managing applications to ensure performance, availability, and security in the most effective, operationally consistent manner possible to provide value across the data center.

quote-badgeIBD – F5 Cultivates Customers When Launching New Products

In 2011, F5 Networks released the 11th version of its BIG-IP family of software products. Customers have responded enthusiastically.

F5 began shipping its BIG-IP product in 1997. Jason Ader, a research analyst at William Blair & Co., praises F5 for maintaining the product's versatility over the years.

"They've morphed it to accomplish multiple functions and create a platform in which they layer new functions every year," Ader said. "This streamlines IT managers' job so they don't have to buy separate products."

Additional Consolidation Resources:

Additional Resources:

Connect with F5:
o_facebook[1] o_twitter[1] o_slideshare[1] o_youtube[1] rss[8]google

Latest F5 Information