Compression to increase wan performance

Hi Igor,

Unfortunately this type of question fits into one of those "it depends" type scenarios.....;-( The areas you need to consider if compression would help are -

- Can the other end of your WAN link also handle compression/de-compression (both ends need to do it). - The platform performance (is it currently lightly/heavily loaded). A 2600 would not have a lot of CPU spare if handling a T1 with a moderate amount of ACL's being processed. If the link is already queing a moderate amount of traffic then I would not consider it without some form of offload for compression, but then consider the cost of this. - Also take into account the type of traffic you are passing on the link. EG VPN traffic is encrypted and would not compress well (if at all), however plain text or HTML with buckets of embeded white space could provide great returns. Also consider that it takes time to comress/uncompress so there is an overhead for doing this.

Overall we abandoned using compression on our WAN around 2000, it was no longer viable, but then your situation could still benefit from it..

Cheers.....................pk.

The absolute best thing to do is to try it. Monitor CPU usage in the routers while testing.

I agree with all of Peter's points above.

One thing that is a pretty certain winner if you are using TCP is van Jacobsen TCP Header compression. You may need to turn on PPP but it looks like you will still be ahead.

Consider also the network end to end latency which may be causing your orformance problems.

If you add more detail someone may be able to comment further.

Yes, data compression will increase data throughput. Products available to compress data and then decompress data on both sides of the connection are the Cisco WAAS, Riverbed Steelhead, and Packeteer WAN accelerators. Some of the products brag a 90% compression on TCP connections with UDP being passed through uncompressed. Some of the products encapsulate all compressed data into a single tunneled connection between the end accelerator devices while others simply compress the payload and decompress the payload on the other side.

the other posters suggested / implied using s/w compression, but i would be wary of using it on a line at this speed.

the compression AIM (2600 XM only AFAIR) can do hardware compression and should be happy at T1 speeds.

even if the data isnt compressible (and some nearly always is), the headers will be.

typical office traffic often compresses around 2:1, but badly written apps can show much higher gains as their packets are full of empty padding.

with a hardware compressor on a serial link, you normally find that delay for compressed packets goes down - the reduction in bits needed and associated delay offsets the time taken for compress / decompress.

Thank you for all your input, it looks like I need to do a lot more reading on this subject.