Part of the premise behind secure access service edge (SASE) and global SD-WAN services is to replace the MPLS services that long anchored enterprise networks. But to do that, they first need ways to overcome the unpredictable and high latencies of the global Internet.
Enter global private backbones. Whether they’re independent backbones, like Azure Virtual WAN, or included in solutions, like Cato Networks, global private backbones are meant to deliver premium IP connectivity that providers claim come at a fraction of the cost of MPLS. Your SD-WAN tunnels designated traffic across an Internet connection to the backbone PoP. The traffic crosses the backbone and exits the PoP closest to the destination.
But can global private backbones match global MPLS performance? Recent testing by one of my customers suggests the affirmative — if you know what to look for. Let’s take a closer look.
The Argument Against Private Backbones
While private backbones might be a distinct improvement over the global Internet, it’s a different story when compared with MPLS services. After all, global MPLS services are tightly managed end-to-end. Private backbones are often just part of a larger solution that you need to piece together.
MPLS services come backed with carefully constructed SLAs guaranteeing latency and loss levels — and paying you if they fail to meet those SLA objectives. By contrast, most private backbones providers only offer SLAs around uptime. There are no SLAs for latency, loss and jitter.
Global private backbones are Layer-3 services. MPLS is a Layer-2-1/2 service. In theory, having to go up the stack adds more latency.
Finally, global private backbones are still accessed by establishing encrypted tunnels across the Internet last-mile. While traversing the last mile, your traffic is left exposed to the Internet’s unpredictable routing, not to mention the packet loss and latency in the last mile. MPLS services, of course, are accessed by dedicated circuits, free of the latency and unpredictability of the Internet last mile.
Customer Testing Shows Private Backbones Can Outperform MPLS
All of those are valid and good points, but here’s the thing: they matter very little in the field. In our experience here at SASE Experts, private backbones can certainly meet the needs of most enterprises.
Notice how I say that: most enterprises.
On some paths, and at times, they may not provide the same latency and loss levels of a global MPLS service. But the difference is so negligible that your applications likely won’t notice the difference. More importantly, many times, performance will far exceed that of what you’ll see on MPLS.
One of my customers, for example, as part of their SD-WAN Proof of Concept (PoC), recently compared the performance of one private backbone with that of their legacy MPLS provider. They found that the time needed to transfer a folder of 1510 files of different types (Excel, JPG, and PDF) across 120 subfolders (322 MB) across the private backbone between South Korea and Atlanta was as much as 29% less than across MPLS (1628 seconds vs. 1154 seconds). Within South Korea (Yeosu to Seoul), transferring 2,129 general program files (626 MB) was as much as 44% less across a private backbone than across MPLS (599 seconds vs. 338 seconds).
Was that the case all of the time? No. Several tests showed file transfers across MPLS to be up to 3% faster, but that was the exception. With China, there was more unpredictability, but the private backbone performed better the majority of the time. For the most part, this customer and the others I’ve consulted with who’ve adopted private backbones have reported seeing as good if not better performance than MPLS.
Not All Private Backbones Are The Same
There are several reasons why performance across global private backbones can rival and even exceed that of MPLS. For one, there’s the amount of capacity. The use of IP capacity allows enterprises to increase bandwidth size 5x to 10x more than they could afford on MPLS. More bandwidth will do an awful lot to improve performance, particularly over short distances, like the above results across Korea.
Over long distances, file transfer throughput across TCP is determined by latency and packet loss. Increased bandwidth is less relevant. To those ends, the surplus of capacity lets them engineer their backbones for zero packet loss. As for latency, the bad reputation of Internet latency often gives private backbones a bad name. Yes, they’re IP networks like the public Internet. But Internet routing is free and hence optimized for the benefit of the ISP; private backbones are paid services, and the routing, for the most part, is optimized for the benefit of the user.
In short, latency times across private backbones compare well with MPLS. Factor in the additional capacity and the fact that some providers will include WAN optimization techniques, such a TCP proxying, in their backbones, and it’s easy to see why file transfer performance can be so much better in a private IP network than MPLS.
Of course, this says nothing about getting your traffic to the private backbone. You still need to traverse the Internet last-mile. The good news? As we pointed out in this report, last-mile latency is relatively small in a global network. The real question is packet loss in the last mile, and SD-WAN devices should have the technologies to overcome last-mile packet loss. There’s also the issue of PoP selection. As we discuss here, some backbones take in traffic at the PoP closest to the source. Others route traffic across the Internet to the PoP closest to the destination. You’ll want the former.
Outside the domain of performance, there’s the issue of availability. As you bring private backbones into your network architecture, you need to investigate how fault recovery works. How long does it take to bring up a PoP? What happens if there’s a failure on the backbone? There are many, many issues here, too many to cover in this blog.
If you want to learn more about private backbones for an upcoming RFP, book some of my time here. It’s one-hour consultation, no charge, and we’ll be able to talk through some of the challenges you
