Networking used to be so much simpler. When you pulled files from a server across the room, there wasn’t a lot that could undermine performance. But put that server across the globe and, well, that’s another matter.
Long distance coupled with congestion has brought TCP connections across even Gbits/s links to a crawl. But don’t lose heart. There’s still plenty you can do to overcome the problem.
Bandwidth Isn’t the Issue
To get started, first understand the nature of the problem. Network characteristics impact applications differently. Voice and other real-time applications are susceptible to packet loss; large data transfers are more susceptible to factors impacting throughput.
Fixing these problems has very little to do with the amount of bandwidth between a location and the ISP. This is particularly true for TCP connections across long distances. Latency and packet loss are far more significant — a fact long proven by the Mathis algorithm. As packet loss or latency increase, connection throughput decreases. Packet loss is impacted by the quality of the physical infrastructure and congestion on the network, both of which have improved over the years, in part due to the fiber rollouts.
While the physical distance to a server is a factor in determining a connection’s latency, it’s not the only factor. Internet routing contributes significantly to latency issues. Today’s routers blindly move packets along their path, the “data plane,” whereas routing decisions are made by a separate process, the “control plane.” The control plane calculates the optimum path determined by the fewest number of hops and populates the routing table. The data plane only looks up and follows the entries in the routing table. Communication between the two is largely limited to routing table updates; getting “feedback” from the data plane is simply out of the question.
As such, routers have no measurement for how long a packet is needed to reach its next hop, or whether it can be reached at all. Are neighbors congested? Maybe and maybe not. The router doesn’t even know if it is congested, itself. And to the extent the data plane does have information to share, the information will not be communicated back to the control plane.
To make matters worse, all applications get treated the same way. A single “best” route is calculated for all traffic between two points. Although voice sessions, for example, may be better served by a route with more hops and less packet loss, routers will still direct voice packets along the same route as any other application.
What You Can Do
Distance may never change, but Internet distance — the route packets take to a destination — is another matter. You may not be able to change BGP, the routing protocol stitching together the Internet overnight, but you can choose how to compensate for its limitations.
One approach is to avoid the Internet altogether using an MPLS service. While effective, MPLS services are more expensive than Internet connections. They’re also less agile, requiring as much as six months to deploy. Cloud and Internet performance often suffer. There’s a reason companies are looking to leave MPLS.
A second approach is to be smarter about how you pick your Internet paths. This is the tactic
taken by SD-WAN appliances. Offices are connected by at least two Internet lines, ideally diversely routed from different providers. The SD-WAN appliances bring up tunnels (called a “virtual overlay” or just “an overlay”) between one another. Then by monitoring the performance of each line, the SD-WAN appliance can steer traffic into the best performing tunnel for a given application. Should one line fail, traffic can be switched over to a tunnel on another line.
SD-WAN appliances provide some control over general Internet performance. There is still no inherent advanced security or the ability to support cloud implementations or mobile users. Once packets leave the customer premises, there’s also no guarantee as to how ISPs will route the packet.
This is particularly problematic in global configurations where latencies are already high and there are fewer unique routes in the core. With fewer routes, there’s greater likelihood that all ISPs will be equally affected by a failure in the peering point going into a country or congestion on a transpacific cable. SD-WAN appliances are unable to deliver predictable network characteristics for key applications, such as voice, in those scenarios because no path meets the necessary requirements. Companies can offload some traffic from MPLS onto SD-WAN, but can never eliminate their dependency on the MPLS service.
Best of Both Worlds
The Internet does not work flawlessly nor optimally, but packets generally reach their destination. We don’t need to a completely different network, as proposed by MPLS vendors. We also cannot ignore the Internet’s routing problems, as we do with Internet appliances.
We need a different approach, one that increases the communication between data and control planes and selects the best path based on the needs of each application while continuing to deliver low cost, high agility, and global reach of the Internet.
Cloud networking platforms provide a viable alternative. They build global backbones from capacity leased across multiple Internet backbones. Strategically placed PoPs connect these backbones, selecting the optimum path for packets based on application and business requirements. SD-WAN appliances at the edge use business-grade Internet access to connect to the closest PoP.
The result: a marriage of MPLS performance and Internet agility at low costs. With the PoPs selecting the best path from routes across leased capacity, backbone latency and loss rates are lower and more consistent than the general Internet. By leveraging the Internet in the core and access, costs are also reduced. Mobile users and cloud instances can connect to the WAN just as they could connect to any cloud service. And since it’s the cloud, advanced security functionality can be supported.
Fixing the Internet’s routing problems may not happen immediately, but that doesn’t mean you need to suffer from poor Internet performance. Alternatives exist to address your deployment and performance challenges — today.