We were sitting around with our oldest son the other night when a trailer for the forthcoming Star Trek movie appeared on the television. Now I’m star_trek_04not living under a rock, but my free time is somewhat constrained by the fact that we have a toddler, so while I was “aware” of the movie I hadn’t seen the trailer yet. I’m a geek, and a Star Trek fan, so I watched with interest. Our oldest, of course, had seen the trailer before and it had barely begun playing when he suddenly erupted with Nerd Rage.

Nerd Rage, in case you aren’t familiar with the term, is the sudden (and very real) anger that comes from a geek upon seeing something that violates the laws of physics or, in some cases, established historical “facts” in science fiction/fantasy based on previous episodes and/or movies.

In the case of the latest Star Trek movie, the trailer clearly shows the construction of the Enterprise – on earth. This is the source of Nerd Rage for many who will not-so-calmly explain that a Constitution-class starship could not possibly be built on earth because it is too large to escape the  earth’s gravity. It violates the laws of physics which, even in science fiction, must be obeyed. For true Star Trek fans, the ones who can quote you stardates as well as they can Gregorian dates, this simple “mistake” may very well ruin the entire movie. It certainly resulted in a lot of angry gestures and frustrated words from my oldest son.

Nerd Rage exists outside the realm of movies and books and science fiction as well. It’s almost always associated with something science related – physics, mathematics, and of course computer science. If someone has a passion for something and you incorrectly describe it or associate it with something else – especially when it’s technically inaccurate - it can induce Nerd Rage.

Obviously I’m leading up to my own Nerd Rage over something related to application delivery. Ready? Here we go…


In the case of networking and application delivery, today’s Nerd Rage is being induced by the use of the term “application acceleration” when what is really meant is “network acceleration.” Why? Because there is a very real difference between the two. Chances are that when you’re delivering applications over the WAN that by focusing on network speed and utilization that you’re missing a wealth of opportunities for improving application performance and efficiency at higher layers of the stack. Because you aren’t actually optimizing the application and its protocols, you are optimizing the network and its protocols.

The focus on WAN optimization (which has very little to do with application performance and everything to do with network performance) results in a false sense of complacency and a misplaced trust in the ability of layer 3-focused solutions to address what are layer 4-7 problems. WAN optimization is not about application performance. It’s about network performance.

Network layer optimization provides only some improvement in application performance because it isn’t focusing on the application. Application performance improvements from network optimization tools is an artifact; a side-effect of improving network performance. Implementing higher-layer optimizations provide even more improvement in performance. And as a bonus it throws in efficiency improvements angry_womanthat can’t be achieved via simple, network optimization focused solutions.

Systems that can acceleration application performance through optimization can do so regardless of what kind of network the consumer is using. WAN, LAN. It’s all the same. They both end in network after all, and the only real difference is that a WAN link is typically bandwidth constrained and exhibits higher latency than a LAN. Oh, and distance. Can’t forget distance, can we, especially with that pesky little physics law about the speed of light and all.

The most interesting thing to me is that while the problems associated with a WAN link are only likely true – and then often dependent on time of day – the chattiness and inefficiencies in TCP and HTTP are always there, no matter what type of network is used. So it seems to make more sense to optimize THOSE than it does the WAN, as everyone benefits from application optimization but only a privileged few benefit from WAN optimization.


Don’t get me wrong; I’m not dismissing the benefits of network optimization or a reduction in bandwidth. WAN optimization is absolutely the right tool for site to site transfers of large data sets, like those associated with replication and backups or virtual images being pushed down to clients or secondary data centers (physical or cloud-based). And network optimization can result in real cost savings by reducing congestion on the WAN, which of course results in fewer retransmissions and what will be a somewhat better performing application.

I’m just saying that optimization and acceleration at layer 4-7 (at the application focused layers) yields even greater benefits for applications and its supporting infrastructure, such as the capex and opex savings that comes from a higher efficiency infrastructure achieved via technology like TCP multiplexing and connection management, offloading of compute intensive tasks, and application protocol optimizations (the operative word there being application) that result in much better performing applications. And for a reduction in bandwidth utilization, application acceleration can aid that too through the use of compression and ensuring proper use of client and server-side caching.

I agree with the sentiments expressed in David Strom’s recent Measuring End-to-End Applications Performance in which Jeremy Gill, vice president of IT for Michael Baker in Moon Township, Pa. says: “IT managers need to look beyond simple load balancing.”

Amen. I agree. I just don’t think that WAN optimization is the best place to look when trying to optimize and acceleration applications. Because network optimization is not application optimization, they’

Application delivery makes a heck of a lot more sense when you’re talking about improving application performance.


Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share