Enterprise SD-WAN Trade-Offs Part 3: Cost vs. Performance

SD-WAN makes it easy to incorporate less-costly bandwidth options like Internet Broadband and LTE at remote locations. What are the performance-related SD-WAN trade-offs to consider? Here’s a question: What is the increase in capacity going to do to your app performance? In this third part of the Enterprise SD-WAN Trade-Offs blog series, we will examine the factors you should consider when incorporating inexpensive bandwidth options.

You might be thinking, “Wait! Doesn’t more capacity always equate to better app performance?” Well, like most things in life, it depends.

The reality is that more WAN capacity can lead to any range of possible effects concerning app performance:

1. More WAN capacity could yield NO DIFFERENCE to app performance, or…
2. More WAN capacity could make app performance BETTER, or…
3. More WAN capacity could even make performance WORSE!

It all depends on the underlying bottleneck which is limiting app performance in the first place. If you don’t know the situation you’re in, you may be surprised to find your app performance is no better—or is even worse—with higher capacity bandwidth circuits in place.

SD-WAN trade-offs: performance factors to consider

There are three key bottlenecks to be aware of as well as how they map to the results mentioned above:

• High Network Latency: more capacity will yield NO DIFFERENCE.
• Low WAN Capacity: more capacity will make app performance BETTER.
• Poor Link Quality: more capacity of lower quality can make performance WORSE.

Note that when it comes to maximizing your application performance, it’s an iterative process. You need to identify the current bottleneck, apply the appropriate remedy and then repeat the same process over again. As one bottleneck is alleviated, a different one may emerge. This means that you need to have a solution with a full complement of capabilities to overcome each bottleneck along the way.

Here’s a very common example: Let’s say that you’re dealing with the performance of large file transfers across your WAN using a file-sharing protocol like Microsoft CIFS/SMB. Each of the bottlenecks above can emerge, and increasing bandwidth only addresses one of the problems.

Network latency

The first factor in this SD-WAN trade-off is network latency that inhibits the performance and throughput of the network protocols (TCP) and application protocols (CIFS/SMB). One indicator of this situation is that available WAN capacity remains unused even while the file transfer occurs.

How is latency having this impact? In the case of network protocols, the TCP stacks residing in the client and/or server operating systems are configured by default to send a maximum amount of data (in IP packets) onto the network before receiving a response that the data has been received. Only after the data is transmitted across the WAN, and an acknowledgment of its receipt is transmitted back across the WAN, will the operating system send more data onto the network. Similarly, the file-sharing application protocol (CIFS) will only transmit a maximum number of data “blocks” and waits for an application-level acknowledgment before sending more.

To alleviate this bottleneck use WAN optimization that can accelerate the performance of BOTH network AND application protocols. If only one or the other, but not both is employed, latency will continue to limit the end-to-end throughput of the file transfer.

WAN capacity

Next, WAN capacity has become fully utilized and is thereby limiting end-to-end performance. To alleviate this bottleneck, use network data compression and/or deduplication to virtually expand circuit capacity. You could also upgrade to a higher capacity WAN circuit, however, be mindful of the following common result.

Link quality

Finally, poor link quality causes end-to-end throughput to suffer. You’ve upgraded your MPLS circuit to a higher capacity Internet Broadband circuit, but surprisingly you see end-to-end performance degrade. The percent of network packets dropped during transmission has increased. (This is often due to internal congestion of the WAN itself. Unlike MPLS circuits, which come with higher SLAs and guaranteed performance, lower cost Broadband or LTE bandwidth may be oversubscribed. Essentially, you get what you pay for.)  Such dropped packets slow down the whole machinery of your data transfer. Each dropped packet must first be detected as “lost”. It then must be resent. And finally, its acknowledgment must be received. This entire process takes time and multiple roundtrips across the WAN. And all the while, it keeps the contiguous data stream from being delivered, in order, to its recipient. 

The solution to this is to employ link conditioning, or forward-error correction (FEC) techniques, such as packet duplication or multi-packet parity encoding. When these techniques are used, a sender sends more information (alongside the data) onto the network that can be used by the recipient to reconstruct one or more packets that may have been lost along the way. The use of these techniques comes with one important warning: If the underlying cause of the dropped packets was network congestion in the first place, then such techniques can further exacerbate the problem, causing more congestion, more packet drops and further reducing the experienced “quality” of the circuit. (TIP: Look for solutions that automatically and dynamically turn on and off such techniques only when required, based on real-time network conditions.)

As this example illustrates, using SD-WAN to increase WAN capacity may do nothing to improve your app performance. And, if you adopt lower quality circuits, your performance can get worse.

In summary

To break through any SD-WAN trade-offs between cost and performance, make sure that your SD-WAN solution provides the following capabilities. Only then will you be able to overcome each and every bottleneck that will arise.

• Network Protocol Acceleration (Eg. TCP/UDP)
• Application Protocol Acceleration (Eg. CIFS/NFS/HTTP)
• Network Data Compression
• Network Data Deduplication
• Dynamic Circuit Conditioning (Eg. Packet Duplication, FEC)

For more information on how to go about correctly diagnosing your current bottlenecks to app performance, also refer to the following:

• Blog: SD-WAN or WAN Optimization?
• Blog: Top 4 Reasons to Optimization Your SD-WAN
• Product page: Riverbed Transaction Analyzer

And for more information about an SD-WAN solution that provides all of the necessary capabilities discussed in this blog entry, check out Riverbed SteelConnect EX.