TCP acceleration over satellite or high latency networks
What viable companies, products or options are out there today for TCP Acceleration over satellite or high latency IP networks?
The average satellite RTT is upwards from 600ms (depends on the location)
TCP doesn't work too well as the window sizes are kept small due to the delay in receiving ACKs. An accelerator is required to spoof the ACKs to trick the device to start sending the next set of data while the original packet is still in transit.
I know Riverbed has their Steelhead product http://www.riverbed.com/products-solutions/products/wan-optimization-steelhead/
Delay at no way prevents TCP window to grow. It is exactly because of delay TCP window even exists! You may need to review your TCP settings if you're not getting sufficiently large TCP windows.
@ytti how would you optimize your TCP settings for a greater than 600ms RTT delay then? There's not packet loss on the satellite link.
I used to deploy WAN acceleration devices for a hardware vendor about 6 years ago. Not much has really changed since then except I won't make hardware recommendations because of consolidation and changing product lines.
All of these devices use some combination of compression and caching to reduce the overall traffic to be transmitted, TCP pre ack'ing to reduce the effects of bandwidth delay product (this is the TCP window effect that you alluded to above) and ganging of undersized packets to insure that packets traversing the links are as full as possible reducing the effect of overhead. The various vendors will throw in their own patented technologies as well, but they mostly boil down to different flavors of these.
While caching is a major help, just the pre-ack'ing of packets over a satellite link will go a long way to making them usable, so that even if your data isn't cacheable for whatever reason (encrypted, compressed, zipped, always changing drastically, etc) if you have a slow enough RTT the pre-ack'ing will partially eliminate the bandwidth delay product and help you get closer to your nominal bandwidth.
Since the whole goal is to drive up network efficiency and allow higher utilization of your bandwidth, it's very important that underlying network problems that may pop up with high utilization are fixed before deploying a solution. If you have duplex mismatches or are running on half-duplex connections you'll often find that performance is worse than before you deployed wan optimization devices. Often I would find that customers didn't realize that they had some links that had auto-negotiated down to the lowest common denominator of 10 Mbps half duplex.
Many of these devices also offer Forward Error Correction (which your modems probably offer as well) which you can use to overcome some of the effect of packet loss on your links. This is important since the packet stuffing means that more than one LAN packet could be lost for each WAN packet that gets lost and because of the pre-ack'ing those packets have already been acknowledged to the servers. Make sure that you know which devices in your path are performing FEC so that you don't create more overhead than necessary since this will of course reduce your effective throughput.
Speaking from experience, I saw customers without significant caching able to do 'acceptable' (mostly one way) video conferencing over a double satellite hope whose latency ranged from 900 ms to 2 seconds and might have 15-25% packet loss for extended periods. I wouldn't choose to use the resulting flow, but if that's what you have it'l work.
We use it for
- TCP acceleration
over satellite connections (VSAT) for cruise ships, with latency between 600 ms and 800 ms, depending on satellite and earth station (possible additional transatlantic latency). One central manager and a policy manage a network of a dozen appliances. RDP is much more responsive thanks to TCP optimizing, furthermore web applications and file replication save much bandwidth.
There's a virtual version vWAAS, which we plan to install soon.
I know iDirect satellite modems provide a very good TCP optimization, if you would be able to use them.
I am by no means authoritative on this subject, however, in our environment we use Riverbeds for WAN optimization, and although we're not over satellite, we see a 68% improvement in speed for TCP communication as a minimum, and the Steelheads we have report an almost 3x bandwidth increase based on data it serves from its datastore vs. actually transferring things over the WAN.
I did a look online for you as well and came up with some that looked angled in your direction, hope this helps or that others could give some real life feedback on them!
The ViaSat company looked like it had government grade solutions, and comtech ef data has a pretty good testimonial from an ISP utilizing their service that may be of use to you.
I would also recommend Cisco WAAS. It does perform well. My company did a decision paper and evaluated a few products. The WAAS came out on top. It was better able to handle variable speeds associated with different weather conditions. Form factor can be a problem also. WAAS can be accomplished using WAAS Express, modules, or full appliance. If power and space are a consideration like in an aircraft or other mobile plateform then not needing a full appliance can be very helpful.
Also many accelerators require that you enter an expected bandwidth. If your link varies too much (as can happen with satellite links) then you will get poor performance from the accelerator. The WAAS has no such requirement and will use all available bandwidth.
For one year now, I have been using Riverbed Steelhead to perform traffic optimization over regular WAN connections. So far I am satisfied with the results.
Despite I have no experience with satellite links, Riverbed's website looks like they have optimization solutions for satellite links too: http://www.riverbed.com/products-solutions/solutions/satellite/
Two satellite vendors that I worked with (10 years ago) were.
Both have VSAT options that involve a lot of "spoofing" similar to what Riverbed does on the WAN. They'll terminate the TCP connection at the earth-terminal on each end to make the client think things are faster than they are.
Acceleration is like lying. You are basically lying about the acknowledgement. The more lies you tell, the more you have to remember. This is why it typically takes an external box since it is memory and processor intensive.