WAN Acceleration: Sweet Spots and Gory Details

I’m constantly striving to find ways to cope with limited bandwidth.

QoS in all its forms has its place, as do replication of data, managed telco services (e.g. MPLS), and dedicated hardware appliances (e.g. Juniper Peribit); but I’m ultimately looking for devices that one can use in given situations to automagically speed up TCP streams of 100+ GB files in various situations.

From what I can tell, some of these automagic solutions include some of the following techniques:

• break one TCP request stream into a gazillion smaller request streams (a good way to saturate your network)
• fake ACK packets (i.e. increasing the window size of the amount of traffic that needs to pass before an ACKnowledgement is required)
• convert TCP to UDP traffic (and thereby disregard TCP’s connetion-oriented ACK packets completely)
• compress the files before they are sent (a strategy that works differently with different types of files)
• cache files across the WAN (which doesn’t work so well with most DB files, such as PST, MDB, as anyone who uses MS’ “Offline File” options knows)
• accelerate certain protocols (which may or may not lend themselves to being accelerated for all sorts of reasons)

These solutions have consequences, increasing functionality in one area adversely impacts the functionality in a different area, and all you can do is hope that the others in that adversely affected area aren’t related to the CEO.

If you have a solution that hits a particular “sweet spot” in your organization, do share. I’m always on the hunt.