In the traditional approach to branch office networking, organizations backhauled their Internet traffic to one or more of their data centers. The advantage of backhauling is that it gives network organizations the ability to secure this traffic relatively easily. The disadvantages of this approach are that it adds delay and cost. These disadvantages are clearly acceptable if the amount of Internet traffic is small and if the Internet traffic isn’t business-critical. However, given that the volume of Internet traffic generated from branch offices keeps growing, and that this traffic is increasingly for business-critical applications, you have to ask: What price are companies paying for Internet backhaul?
How much traffic is being backhauled?
Earlier this year I published The 2015 State of the WAN Report which included the results of a survey of over 100 IT professionals. One of the questions asked respondents to indicate how much of the Internet traffic that originates in their branch offices is backhauled to one of their data centers before being handed off to the Internet. Their responses are shown in Figure 1:
The survey results show that there is a distinct bi-polar approach to how Internet traffic is handled. There are some organizations that do absolutely no backhaul. These are likely SMBs that have very few sites and are likely to use the Internet as their only WAN service. In addition, just over a quarter of the respondents indicated that they do limited backhauling. At the other end of the spectrum fully half of the respondents do significant backhauling, with 40% indicating that the backhaul more than 80% of their traffic.
The 2015 State of the WAN Report also contained the results of a survey question in which the respondents were asked to indicate which applications were driving the biggest increase in their use of both MPLS and the Internet. Unsurprisingly, the biggest driver of increased MPLS usage were enterprise applications like CRM, followed closely by voice and video. At first, however, I was surprised that the increased use of cloud applications and services was mentioned as a driver of MPLS only slightly less often than voice and video was mentioned. Then I realized that the reason for this is that in many cases the traffic that is destined for the cloud is backhauled over MPLS before being handed off to the Internet.
What’s the cost?
Given the current amount of Internet backhaul — combined with the fact that for at least some organizations the ongoing adoption of public cloud applications and services means backhaul will increase — it is reasonable to estimate the impact of Internet backhaul as a means of determining if it is still acceptable. As mentioned, Internet backhaul adds delay and cost. If the communications stay within the continental US, the added delay will most likely be in the range of 50 ms. to 60 ms. The impact of this added delay on application performance will vary by application.
In order to get insight into the added cost associated with Internet backhaul, consider a hypothetical company which has fifty branch offices, with each office having two T1s that connect to an MPLS service. Further assume that each T1 costs $450 per month. The annual cost for this branch office network is $540,000. Allocating cost based on a pro-rata usage of capacity, Table 1 shows how the cost of Internet backhaul varies based on the percentage of the overall traffic that is Internet traffic.
|Percentage of Internet Traffic||Annual Cost|
What should you do?
I certainly don’t want to imply that if a company stops backhauling Internet traffic then all of the costs highlighted in Table 1 go away. They don’t, but a sizeable percentage of them do go away. I also can’t issue the blanket statement that network organizations should stop backhauling Internet traffic as there may well be many instances in which Internet backhaul makes sense. What I can say is that given the high cost associated with Internet backhaul, network organizations should look closely at alternative approaches, such as those that are described in The 2015 Guide to WAN Architecture and Design.