From what I'm seeing, everyone is converging on IP as the way forward, from VoIP to storage to day-to-day production. So far so obvious. But how can the underlying network cope with that, plus a backup load (probably) when it's largely non-deterministic? Is anyone actually using technologies such as WAN optimisation?

Increased load isn't really an issue, as services providers generally bill clients based on utilization.

Therefore any increase in throughput, generally will have an increase in revenue which will pay for the required upgrades.

I have seen a few places use WAN optimization hardware, however this does cost time and money to setup, which can sometimes be more expensive than just committing to more bandwidth.

Generally I have only seen these at rural sites where bandwidth is really at a premium, also its normally only used on slow traffic like HTTP, too much latency for VoIP etc...

True that providers will bill you for utilisation. But it's interesting you should say that it's cheaper to add more bandwidth. From what I've heard sometimes problems can be persistent no matter how much bandwidth you add - so it's not just a bandwidth but a latency issue. And wouldn't it be better if you didn't have to add (and pay for) more bandwidth?

I don't think that latency is really your problem in a converged network as you're saying. If you have a converged network... http and voip on one line for example, and the line is at 10% utilization, and you're having latency problems with your voip, there is some other factor at play than just having the http traffic on the same line, if that makes sense, so I wouldn't blame "convergence" for that. Certainly there could be other issues causing performance problems, related to using VOIP rather than a dedicated line, but the fact that it's converged isn't the big deal there.

As to how the network "copes" with all these traffic requirements, I would say, most of the time, bandwidth follows a nice sine wave pattern. The more bandwidth you're using, typically, the smoother the curve, so it's easier than you think to provision for the actual b/w use you're likely to see, as it's not like some mystery how much b/w your lines are going to be pushing at any given time.

And yes, I would say adding more bandwidth is often your cheapest option. Part of this reason is that, for your service provider, the largest cost is reaching you in the first place. A fiber optic cable offering your business 10mbps is going to cost verizon the same amount of money to support as a 20mbps fiber optic service. Sure, they'll charge you more for 20mbps, but you do have negotiating room there, because the cost to them is basically identical. The same goes at the higher end of the bandwidth scale, as building out and supporting a PoP in the first place is more expensive than pushing a few more bits over an existing PoP. If the provider already has presence where you're at, you can tend to get lower pricing at higher volume for that reason, which means just adding bandwidth usually makes the most sense for everybody, vs any other method you might use to mitigate performance issues.

So at what point do you think that WAN Opt can become cost-effective?

So at what point do you think that WAN Opt can become cost-effective?

When it's free.

Uhh, yeah, Ok. So, under no circumstances?

What about if you've got a multi-terabyte system that you want to duplicate for DR reasons or just get snapshots offsite, would you consider it as a way of shortening backup windows? I'm just interested...

Uhh, yeah, Ok. So, under no circumstances?

What about if you've got a multi-terabyte system that you want to duplicate for DR reasons or just get snapshots offsite, would you consider it as a way of shortening backup windows? I'm just interested...

If you have to copy all the data, i.e. a full backup vs incremental, then you should probably use a protocol that's designed for something like that, using multiple threads and compression.

Wan optimization is usually there to mess with protocols that were never designed to work properly over a wan, such as windows file sharing, to improve their performance transparently. I.e. instead of using the right tool for the job, throw in an ugly hack to make the tool and the job kind of meet halfway. For many enterprises this is a reasonable solution, because just throwing more bandwidth at the problem won't solve these kinds of issues.

Now, for a situation where you're strictly bandwidth limited, and you're thinking "gee, wan optimization or more bandwidth", more bandwidth every time. At the most, wan optimization would give you tcp optimization, compression and file deltas, so just using a backup protocol that does multithreaded transfers, file deltas and compression in the first place, and you have no reason to use the wan accelerator.

If you have absolutely no way to make your application work efficiently over the network, and no way to switch to a different application, *and* your wan optimizer is specifically designed to improve that specific application, then that is what wan optimizers are designed for, and certainly, go ahead and use one. Other than that, I wouldn't even look at it.

I agree that WAN opt tweaks the likes of CIFS so it works better over the WAN - but that's not the whole story, surely?

For example, what about the traffic prioritization that some WAN opt implementations offer? They could help to ensure that eg VoIP still worked while you're doing a humongous transfer.

And as for file deltas, that's a huge piece of data just there. If you could cut your transfer size by a factor of - say - 10 or 20 because a lot of a backup set will already exist at the remote end, that's got to be better than trying to get more bandwidth - even assuming that more is available - which it often isn't.

I agree that WAN opt tweaks the likes of CIFS so it works better over the WAN - but that's not the whole story, surely?

For example, what about the traffic prioritization that some WAN opt implementations offer? They could help to ensure that eg VoIP still worked while you're doing a humongous transfer.

And as for file deltas, that's a huge piece of data just there. If you could cut your transfer size by a factor of - say - 10 or 20 because a lot of a backup set will already exist at the remote end, that's got to be better than trying to get more bandwidth - even assuming that more is available - which it often isn't.

As to CIFS, yeah, I'd use it for something like that. Sure, wan opt does other stuff, but it's the best example I can come up with as a good reason to use it.

Hopefully your backup solution supports deltas in the first place. If it doesn't, throwing money at a wan opt solution instead of just using a proper backup solution in the first place is optimizing for the wrong thing (no pun intended).

As to file transfers, I could see there being some limited place for that kind of thing. Generally speaking, single threaded TCP transfers like a big file transfer are going to have a tough time maxing out a decent sized port because of latency factors or TCP algorithms, or, even if they can, will tend to back off rather quickly at the first sign of packet loss. I guess it depends how much bandwidth is costing you and how much the device is costing you, but these devices tend to be pretty darn expensive, and the cost of bandwidth these days isn't that great.

As to hoggy protocols like bitorrent, those open up massive numbers of connections so will drown out any other single threaded connection on the network if you're not careful. A packet shaper can be useful here... but I wouldn't really call that a wan optimizer. You can get open source or cheap packet shapers easily enough, to put particular users into a "leaky bucket" bandwidth pool, or to shape off certain classes of traffic as lower priority. Of course, if you have something like, 1gbit to the internet, and you limit everyone's local connection to 100 megabit, then chances are good that a couple abusive people won't have much impact on the network regardless. These wan optimizers are considered "entrprise" hardware, which come at enterprise prices with enterprise support contracts. They're also not well known for being easy to use, so you need an employee around who knows how to configure it, and he's not cheap. Adding 1g of bandwidth would probably be cheaper than getting a wan optimizer, and 1g is a lot of bandwidth to work with.

heck instead of me spouting my opinion on this, if you're really interested, these guys have a lot more experience here than I do:

http://packetpushers.net/packet-pushers-podcast-8-something-on-the-light-side-part-2/

the packet pushers podcast:

"And then Greg explains why he doesn’t like WAN Acceleration"

I'm interested :) and thanks for the link.

But like the man said, you have to use WAN accelerator just to defeat latency - and more bandwidth isn't always available....

Generally speaking, single threaded TCP transfers like a big file transfer are going to have a tough time maxing out a decent sized port because of latency factors or TCP algorithms, or, even if they can, will tend to back off rather quickly at the first sign of packet loss.

Exactly. I think it is time to a new or updated "tcp" protocol. AFAIK Akamai is moving content between their servers using a new (proprietary?) protocol to endure the "middle mile" with better performance.

Is a new standard likely, do you think? Or will people -- OK, some people -- use existing technologies that work around current issues?

Perhaps more importantly, thinking on it, is why WAN optimization hasn't achieved greater penetration than it has. You've got companies such as Riverbed and Silver Peak, who have quite different approaches to the problem, continuing to make a healthy living out of it, yet most reactions seem to be that WANop is too complicated or too expensive.

What's the reality gap here?

Any thoughts on this?

Convergence hurts the network? I am sorry but i had to laugh at that.

A properly designed network is supposed to be convergent, if a network wasnt convergent, the routers would be sending updates all over the place (RIP or OSPF or whatever), which is a waste of bandwidth and increases latency.

A properly designed network is supposed to converge quickly (it saves bandwidth (which saves money!) and as a result of less data being presssed around less latency.

What your really should be saying as the thread topic is "How can I improve my wan" or "What mathods of WAN optimization can I use.

To qoute FUNKYWIZZARD, who said it perfectly:
"If you have absolutely no way to make your application work efficiently over the network, and no way to switch to a different application, *and* your wan optimizer is specifically designed to improve that specific application, then that is what wan optimizers are designed for, and certainly, go ahead and use one. Other than that, I wouldn't even look at it."


To get an honest answer you really need to state what you have, how you have it setup, and what you want to do. Otherwise your just going to get ideas and suggestions tha may or may not have any bearing on your issue(s).