Why you need (a lot) more Internet bandwidth on your Enterprise WAN

Last time we covered the reasons I believe the time is now ripe for a Next-generation Enterprise WAN (NEW) architecture. This time, I’d like to cover something more basic, even fundamental, which rarely seems to be considered and is almost never talked about: most enterprise networks need a lot more Internet bandwidth at their locations.

I’m referring here mostly to branch offices and smaller sites, as opposed to data centers and headquarters locations. Don’t get me wrong – no doubt some of these larger sites need more bandwidth, too. But data center pipes are usually sized appropriately – at least relative to the size of the rest of the WAN links in the network – and headquarters, being where both execs and IT staff are located, more often that not will have “reasonable” sized Internet connections, whether or not they are ideal/optimal.

It’s not simply that most smaller locations have less average bandwidth per user than most of us have at home. And it’s not just that most smaller locations have less average bandwidth per simultaneous user than most of us have at home. It’s that in many cases, there is actually less bandwidth, period, at a remote site than the average user has at their home, or on the 4G/LTE link on their smartphone!

A few years ago, this wasn’t that big a deal. The 1.5 Mbps or 2 Mbps provided by the T1/E1 Multiprotocol Label Switching (MPLS), or maybe Frame Relay, connection at the remote location was at least close to adequate for the tasks at hand. Users at remote sites dealt with applications at those sites, or accessed one or two corporate data centers. Perhaps WAN Optimization appliances were used in cases of data center consolidation to deliver better application performance and more bandwidth on average over that thin MPLS link. Internet access for the typical branch office is typically backhauled over the same MPLS pipes to headquarters or a data center before going out to the Internet (we’ll come back to this issue in our next column). What Internet access that was occurring was mostly web surfing, much of it not business-related, and large amounts of bandwidth weren’t necessarily required.

But, of course, a lot has changed in the last few years. Computing power and file sizes continue to grow roughly with Moore’s law, doubling every 18 months or so. With the advent of smartphones, ubiquitous Wi-Fi and BYOD, there is much greater Internet access than ever before. While much of it still is not business related, there’s not a lot you can do to reduce the bandwidth consumed.

With technologies like DropBox, podcasts, and consumer synching to the cloud (Apple’s iCloud being just one example of many), bandwidth usage has probably grown by a couple of orders of magnitude. If you ban, filter or hugely throttle this “consumer” usage, you might lose key workers of the current generation who take this access for granted. While having appropriate corporate polices and guidelines is all well and good, from the network point of view, it’s hard even to know in many cases what is business use and what is not. [Now, you will want to prioritize the most important traffic on your network, and we’ll certainly address this point as we look forward.]

Beyond this, odds are good one or more SaaS applications are important to the business. If public cloud computing is not yet a part of your IT environment, odds are good in the next couple of years that it will be. Videoconferencing may be here, or coming soon. And streaming video probably already is.

With all this, the size of that WAN link has probably stayed the same, or perhaps doubled. And that link needs to address the “ordinary” intranet bandwidth demands of existing enterprise application use, which no doubt have been increasing as well. Given how expensive MPLS is, addressing the problem by purchasing a lot more MPLS bandwidth usually isn’t an option. Even if budget weren’t an issue (and it always is…) at most locations with copper T1/E1 MPLS connections, there’s a limit to how much can be added anyway.

And if in fact WAN Optimization was deployed more than 18 months ago, while a great one-shot solution to bandwidth woes and may have enabled you to avoid one bandwidth upgrade, it’s not a long-term solution to that issue. 

So the answer in most cases is clearly going to come from adding Internet bandwidth, which is only about 1% – 3% of the cost/Mbps of MPLS bandwidth. (Yes, Metro Ethernet can solve some of this problem for some locations for some customers, but it’s nowhere near ubiquitous, and while less expensive than MPLS on a cost/bit basis, it’s usually still far more expensive than Internet connections).

How to best add this additional bandwidth, and design the enterprise WAN to accommodate it, you say? A great topic for our next column…

A twenty-five year data networking veteran, Andy founded Talari Networks, a pioneer in WAN Virtualization technology, and served as its first CEO, and is now vice president of product management at Aryaka Networks. Andy is the author of an upcoming book on Next-generation Enterprise WANs.