A Graphical View of My Idea of WAN Acceleration and More Bandwidth

A Picture(s) Speaks a Thousand Words

I wrote in a blog two weeks about that I was dissolusioned by WAN Acceleration. It just hadn't made the incredible difference I was expecting, given our current bandwidth sizes. However, at the end of the blog, I mentioned a situation where I felt WAN acceleration would be prudent:

Despite all this negativity, I do feel there is a good role for WAN acceleration (at least in our network). That is at sites that do have plenty of WAN bandwidth. Currently, without WAN acceleration, because of WAN delay, users at sites with big bandwidth links can't utilize them. For example, a single TCP session from Amsterdam to California can max out at around 5.4 Mbps. But, we have nearly 90 Mbps of WAN bandwidth in Amsterdam into our MPLS cloud. So, we have the bandwidth, but not the ability to utilize it. But now bring in WAN Acceleration. Then we have the capability (the big bandwidth) to exploit all the benefits of WAN Acceleration (WARM and COLD transfers). If it's WARM, great. But, if it's COLD and still needs to be transferred over the WAN, we have the bandwidth to do it. Then you get all the other benefits of WAN acceleration, particularly TCP acceleration which can enhance application response time. Instead of 5.4 Mbps per TCP session, WAN Acceleration takes that COLD TCP session to maybe 20 Mbps. That's a big difference that users will notice.

I started drawing this situation up for our own internal purposes and felt it made a lot of sense. To review, let's say we take today's situation, a small WAN pipe: Four years ago, this was a good allocation of bandwidth since we didn't have any VoIP or IP Video and applications used less per session: But, flash forward to today. Now we have VoIP, Video, along with Critical Applications. Oh, and each "Other Corporate Application" takes more bandwidth per session: That's not leaving any room for anything else. The next session that comes along causes QoS to kick in and drops ensue. Users then get frustrated since a lot of work is done in the "Other Corporate Application" queue.


So, our thinking was to just bring in WAN Acceleration and it would make a big difference. But, since not everything was a WARM transfer in our situation, it made the COLD transfers bigger bandwidth hogs: This caused QoS to kick in even faster, pissing off even more people.


Well, it's clear we need more bandwidth, so let's just add that and skip the investment on WAN acceleration hardware. Too bad that's a problem too. In this case you are paying for more bandwidth, but given the affects of delay on TCP, the full bandwidth can't be utilized. Furthermore, individual user sessions are still the same as before, so they don't notice much difference (other than the QoS drops going away): This is a waste of money.


So, the real solution is both (I can hear the CFO screaming now). If you really want to get the benefits of WAN Acceleration, you need to combine it with more bandwidth. Then you have the capability (WAN Acceleration) + the opportunity (large bandwidth) to make a difference for users' performance and productivity:

More >From the Field blog entries:

I Have Been Disillusioned by WAN Acceleration

WAN Carriers Need Better Bandwidth Pricing Models for Enterprises

I Got an iPad

Is Enterprise IT Here to Provide Great Internet Access?

Latency in the Data Center Matters

Net Neutrality for Dummies

  Go to Cisco Subnet for more Cisco news, blogs, discussion forums, security alerts, book giveaways, and more.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Related:

Copyright © 2010 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)