WAN speeds increased by compression edge systems?

Hey Guys,

do you think WAN compression devices at each branch site/office
would increase the speeds some ? as it gets LAN traffic, it could compress
and send and then decompress? is that something that is decent these days and if so what devices would you recommend?

versus using QOS on routers and switches which takes some time to configure and tweak? I dont know enough about QOS techniques to
know if they are fast enough to configure and easy enough to tweak/adjust?

what say you guys?

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

it_consultant

Depends really, if you want faster speed to youtube it is just easier and cheaper to buy more bandwidth. If you want to connect two offices in different states you should look into a Riberbed appliance.

SteveO86

Compression may improve link congestion but it may also put addition load on the CPU of the router/WAN device.

Technically your not increasing the speed of the WAN link you just sending smaller chunks of data. Depending on how over congested the link is compression may or may not be a viable solution.

It also would depend if certain traffic needs to be prioritized (VoIP/Video) in which case QoS would probably be the best bet, or if it's just everything you want to move quicker. (in which case maybe a larger pipe will work out better, but that brings up even more Q/A's)

shodown

"Before we design a solution, it's often useful to define the problem to be solved"

Radia Pearlman

Answer that question above then we can help you out.

itdaddy

shodown

very true.
okay. The problem is this: we have certain systems that suck the band dry every 30 hour for approx 30minutes straight. then waits another hour and then sucks the band up with another 30 minute stint!

I really need to talk to the UNIX guys to see if I can have this program take longer and use less band first maybe. But I was just wondering what you all thought and I do think more pipe and better prioritized packets is the best bet and just wondered what you guys have experienced. Thanks a lot for your help.

Forsaken_GA

itdaddy wrote: »

shodown

very true.
okay. The problem is this: we have certain systems that suck the band dry every 30 hour for approx 30minutes straight. then waits another hour and then sucks the band up with another 30 minute stint!

I really need to talk to the UNIX guys to see if I can have this program take longer and use less band first maybe. But I was just wondering what you all thought and I do think more pipe and better prioritized packets is the best bet and just wondered what you guys have experienced. Thanks a lot for your help.

If they're using rsync to do their data transfers, it has a bandwidth option.

And it really depends on what type of compression you're talking about. Payload compression? Header compression? They each have their pros and cons. I'm personally not a big fan of WAN compression, I'd rather buy more link.

If you are going to do any kind of WAN traffic optimization, do it right and use Riverbeds, but be prepared for the fact that those boxes will get blamed for EVERYTHING that goes wrong on the network.

If it's just one traffic stream that's hogging the bandwidth, I'd just setup shaping to make it go at a certain rate and be done with it. But your idea of checking with the app owners to see if they can limit bandwidth usage is a good one, no cost expenditure, no infrastructure changes necessary.

itdaddy

yeh going to buy more band for sure. thanks for your guys's opinions.
greatly appreciated

shodown

Forsaken_GA wrote: »

If they're using rsync to do their data transfers, it has a bandwidth option.

And it really depends on what type of compression you're talking about. Payload compression? Header compression? They each have their pros and cons. I'm personally not a big fan of WAN compression, I'd rather buy more link.

If you are going to do any kind of WAN traffic optimization, do it right and use Riverbeds, but be prepared for the fact that those boxes will get blamed for EVERYTHING that goes wrong on the network.

If it's just one traffic stream that's hogging the bandwidth, I'd just setup shaping to make it go at a certain rate and be done with it. But your idea of checking with the app owners to see if they can limit bandwidth usage is a good one, no cost expenditure, no infrastructure changes necessary.

They do break everything. We had one customer that was using them and some changes were made and they screwed up and caused us some crazy Database replication issues in call manager. It took us a while to track the culprits down.

Forsaken_GA

shodown wrote: »

They do break everything. We had one customer that was using them and some changes were made and they screwed up and caused us some crazy Database replication issues in call manager. It took us a while to track the culprits down.

They don't break everything, otherwise Riverbed wouldn't have a business! Yeah, they fudge with the rules, and some applications have issues with that, but otherwise they do work pretty well.

The problem is they're black boxes to most folks, and people are quick to blame what they don't understand.

Of course these also usually get forced on some poor admin who asked for more bandwidth to begin with, and some brilliant money guy got the idea to buy a wan optimizer instead, only to find out the wan optimizer makes proper operation of your core business applications impossible, and you now have to buy more bandwidth anyway....

but i digress

shodown

I actually think they are pretty cool, but the insane talk of 90 percent of WAN bandwidth savings is ridiculous. I worked on a global wan and we tested them out. We did see pretty good savings on chatty applications, but its best to check to see if those programs fall under whats consider. My companies biggest users of the wan were for voice/video, and so on which multicast turned out to be the better deal than river bed, but sometimes its hard to get upper management to get there head out there ass when they have no TECH background.

it_consultant

shodown wrote: »

I actually think they are pretty cool, but the insane talk of 90 percent of WAN bandwidth savings is ridiculous. I worked on a global wan and we tested them out. We did see pretty good savings on chatty applications, but its best to check to see if those programs fall under whats consider. My companies biggest users of the wan were for voice/video, and so on which multicast turned out to be the better deal than river bed, but sometimes its hard to get upper management to get there head out there ass when they have no TECH background.

It really depends on the protocol we are talking about when you gauge a Riverbed's performance. They compress the crap out of SMB but don't touch ICA connections. Quick file transfers but no improvement for citrix environments.