As we started to address a couple columns back, until recently, for a serious enterprise WAN, you probably needed MPLS. Thanks to the Next-generation Enterprise WAN (NEW) architecture, this is no longer the case.
Many myths persist as to why MPLS is "necessary" for the enterprise WAN. Given how expensive MPLS is relative to Internet-based connectivity, the telecom service providers need people to believe these things in order to maintain their market share and extremely high margins. Today, we tackle another one of these myths: that an enterprise WAN "needs" symmetric bandwidth, and so can't use asymmetric broadband connectivity. (And using this logic, without being able to use such asymmetric broadband, the price difference between Internet and MPLS is low enough that I should just use MPLS for my enterprise WAN.)
The "logic" of this myth goes roughly as follows: "web surfing might be asymmetric, but business locations and users create data and files, rather than just consuming data, and so need symmetric bandwidth."
The reality: headquarters/data center sites do typically have roughly symmetric bandwidth needs, and certainly need a lot of upstream bandwidth. Of course, a colocation facility is the ideal place to put your data center, even for private cloud, and public cloud services are generally based out of such places. Data center consolidation means there are fewer such sites than ever hosting applications accessed by remote users.
And while users who create content (large PowerPoint files, for example) certainly benefit from additional upstream bandwidth when they create those files, that doesn't change the reality that 90%+ of the time, those files are being downloaded somewhere rather than uploaded. So it's important not to confuse the desirability of relatively high upstream bandwidth with the need for symmetric bandwidth. In addition, WAN Optimization can minimize the time/bandwidth needed for "uploads" for those very frequent occasions when only parts of a large file are changed.
The second part of reality: most applications have asymmetric bandwidth needs, with far more bandwidth needed from server to client than from client to server. In fact, the data center consolidation trend of the last decade and the elimination of "fat" clients and the predominance of web-based applications means that the old 80-20 rule is probably more like 90-10 now in terms of WAN traffic going from the server – at data centers or on the public Internet – towards the client. The move to cloud computing will only reinforce this rule, not reduce it in any way.
In fact, for the most part there have been only three broad application types that have roughly symmetric bandwidth flows: backup, VoIP, and videoconferencing.
Remote backup over the WAN is more and more often being replaced by distributed, replicated file service – one of the key technologies of the NEW architecture – which completely eliminates the upstream bandwidth symmetry issue by constantly synchronizing remote files with those at a centralized location. Even where that is not implemented, the use of differential backup most of the time, and/or leveraging WAN Optimization, drastically reduces the upstream bandwidth requirements of doing backups across the WAN. And, of course, having the far larger downstream pipe is a huge boon for those times that one needs to restore files from the backup!
VoIP/UC flows are indeed symmetric, but since they are not high-bandwidth, they are certainly not the reason asymmetric broadband is inappropriate. That leaves videoconferencing. High-def videoconferencing is the one moderate bandwidth, almost fully symmetrical, application that there is. But most folks don't run HD videoconferencing at most locations today, in large part because the bandwidth is too expensive, and so it cannot be used as the primary justification for MPLS over asymmetric broadband links. At best, videoconferencing might be a reason to keep some MPLS around together with less expensive, asymmetric Internet bandwidth.
Another big reason cited for avoiding asymmetric broadband is that there is "not enough upstream bandwidth on broadband." While there is a grain of truth in this idea, let's examine the facts. First, cable, technologies like ADSL2/ADSL2+/VDSL, and fiber-based broadband like FIOS all typically have more upstream bandwidth than T1/E1-based MPLS has – sometimes a lot more.
Ethernet-based Internet services, usually symmetric, are more and more widely available, with plenty of upstream bandwidth, and these, while more expensive in terms of cost/bit than broadband, are very appropriate for data centers, headquarters or other sites hosting applications or planning to do large file transfers. Again, of course, headquarters/data center sites need lots of bi-directional bandwidth, and pretty much should generally have fiber running to them – allowing plenty of MPLS or Internet-based bandwidth – to be viable for hosting applications going forward. (If you don't have fiber at a headquarters/data center site, you should strongly consider moving most applications which will be accessed by users across the WAN to a nearby colo facility).
That leaves single ADSL, which often does not offer the same 1.5Mbps of upstream bandwidth that a T1-based MPLS connection does, with some offering less than 1 Mbps upstream. This is the one case where I will agree with the historical wisdom: a single ADSL connection probably has insufficient upstream bandwidth for most branch offices.
But that's not the end of the story. For those locations where the only broadband available is ADSL, you can use yet another NEW architecture technology, WAN Virtualization, to aggregate multiple ADSL connections to deliver at least as much upstream bandwidth as a T1 offers, along with much more downstream bandwidth.
Alternatively, if you have only a few such sites, you can use T1-based Internet connectivity for those locations. While it is true that the savings there compared to MPLS are relatively small, and by definition there is not a bandwidth advantage, leveraging broadband to get substantially more bandwidth at far lower cost at 80% - 95% of your locations, while having a solution optimized for leveraging cloud computing, is a lot better than having limited bandwidth and no good cloud access solution at 100% of your locations. Said another way, you shouldn't let the bandwidth availability limitations of the small minority (5% - 20%) of your locations dictate and limit enterprise WAN design for your total enterprise, since acceptable and even superior alternatives now do exist to support those locations.
"But what about the reliability and performance predictability of broadband." Ah... but that's a different subject altogether than bandwidth asymmetry! We've covered the issues of reliability and performance predictability around using Internet connectivity many times in the history of this column, and we'll do so again in the near future as we continue this series on knocking down MPLS myths. It is no doubt the most legitimate, serious issue for an enterprise WAN manager considering moving some or all of their connectivity away from "safe" MPLS, and it is one directly addressed by the NEW architecture.
But as you've seen here, the asymmetry of broadband Internet connectivity not only fails the test of being an impediment to moving away from MPLS, it is actually quite an advantage, even beyond the economics, given the nature of traffic flows today, newer file synchronization technology and the reality of cloud computing data flows going forward.
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.