Disbelief is a common theme in our demo process with potential customers. When we use our AppNeta Performance Manager to show a customer their own data for a particular office, they almost immediately ask why the capacity metrics are low. If the customer is paying for 250 Mbps out of that office, why is AppNeta only showing them 46 Mbps? The answer? Bandwidth is not equal to capacity.
When monitoring performance in modern businesses, network capacity now offers more important information than bandwidth, which used to be a primary network metric. Path-based metrics like capacity are more indicative of actual user experience. That’s essential for organizations today in their near-universal quest to improve end-user experience.
Why Measuring Bandwidth Isn’t Enough
Enterprise IT teams purchase bandwidth in either single or redundant connections from an ISP. Every business needs sufficient bandwidth to get internal network traffic to the myriad SaaS apps and cloud platforms available and in use today. Measuring bandwidth is relatively easy: Flood the network for a short burst of time to fill it with traffic, and identify the maximum allowed bandwidth between source and destination.
However, networks aren’t static. Traffic traversing any meaningful distance will hit multiple routers and, more often than not, multiple ISPs. Flooding any of those networks won’t give accurate results if the provider rate-limits the traffic due to the spike. Additionally, ISP networks are often load-balanced, so the observed bandwidth from flooding will be one particular route of many routes that will likely change over time. The bandwidth also depends on the physical infrastructure, the cross-traffic within the ISP and the ISP peering relationships as your data is being transmitted.
How to Use Capacity Metrics Wisely
Capacity is an end-to-end metric, limited by the most congested hop along the application delivery path. There are two things to know about capacity: First, it’s dynamic. It’s affected by both what infrastructure the packets traverse and the other traffic in the pipe. Second, capacity is not going to be equal to bandwidth. With the increase in physical distance between employees and their apps (think Workday) there are more logical steps, and physical devices, in between the traffic source and traffic destination.
The bandwidth offered by ISPs is typically a theoretical maximum that you’ll never physically achieve on the network. You can come close, but there will always be a certain amount of bandwidth that can’t be used. Flooding techniques can tell you what that achievable maximum is, but only at a single point in time. However, capacity monitoring allows you to identify the achievable space on the network continuously.
Measuring capacity can reduce knee-jerk bandwidth purchases, since bandwidth sometimes gets blamed when it’s actually a capacity problem. Improving capacity can result in a reduced MTTR when troubleshooting user issues. And, historical capacity data can help uncover network issues that bandwidth can’t, and help IT identify future needs.
Understanding Capacity in Practice
Let’s look at an example of the capacity metric. The capacity charts below show our Boston office targeting an AppNeta target device in a colo data center. The purpose of the AppNeta public target is to allow customers to test to a stable and consistent point. That’s better than targeting something like google.com, where the cloud services will fast-track the traffic, potentially providing inconsistent capacity measurements.
The chart on the left indicates the upload capacity and has a provisioned capacity of 300 Mbps. The chart on the right shows the download capacity and has a provisioned capacity of 1 Gbps. With both up and down links shown, we can see that the total capacity (indicated by the highest blue line) is not equal to the provisioned capacity. There are only a few occasions where the traffic ever comes close.
When we target a SaaS app like Office 365, the story changes. It’s still have the same link, but we’re seeing capacity that is nowhere near the public target test. This is the difference between capacity and bandwidth. You might pay for 300 Mbps, but when your network is communicating with a SaaS provider over multiple peered ISPs, it’s likely that your utilized and total capacity metrics to that endpoint are limited. A metric like total capacity isn’t as reliable when targeting SaaS apps due to fast path routing, by Microsoft in this case.
These differences between capacity and bandwidth become a lot more important in this era of cloud and SaaS applications and networks. Getting the whole user experience story requires the combination of total, available and utilized capacity to varying targets. Having the right data will help you be well-informed when finding the root cause of issues, negotiating SLAs and understanding end-user experience.