Measuring Network Bandwidth Without Server Instrumentation

Posted by on January 14, 2014

Measuring network bandwidth is key to understanding network performance and performing capacity planning. Iperf, a traditional network testing tool, measures TCP throughput; but, this is not the same as available bandwidth (or capacity, for that matter). For instance, iperf results are highly dependent on the default TCP parameters of the kernel, among other caveats. But one of the main limitations of iperf is that it requires server instrumentation. Wouldn’t it be great to have a tool to measure available bandwidth just by instrumenting the client?

Well, that’s precisely what we developed here at ThousandEyes. Our bandwidth estimation technology uses specially crafted and sequenced TCP packet trains that are sent between our agent (the client) and a specified server. Using this technique we’re able to periodically measure the end-to-end available bandwidth between your branch office and, for example. This only requires an open TCP port at the server side. Here are two additional use cases for bandwidth estimation that we commonly see our customers perform.

Use Case #1: Provisioning Network Capacity

The example below (figure 1) shows the capacity (dark blue) and the available bandwidth (light blue) time series on a network path between one of our agents in Mexico and a Wikipedia server located in California ( Looking at the timeline, one can immediately see a daily pattern where there’s a decrease in available bandwidth starting at 8am Pacific, and an increase approximately 12 hours later at 8pm Pacific. This roughly aligns with the window when businesses are open in California. One can also see a local maximum of available bandwidth around 12pm which coincides with lunch time. This information is critical to understanding end-to-end network utilization and determining when to update the capacity of links inside your WAN.

Bandwidth usage of
Figure 1: Wikipedia HTTP Test with bandwidth measurement enabled

Use Case #2: Troubleshooting Poor Application Performance

The example below (figure 2a) shows an HTTP server test to that fetches the index page of the site periodically, as well as the time series of available bandwidth during the same time window (figure 2b). Note the correlation between the almost 20x increase in fetch time with a drastic decrease in available bandwidth.

Figure 2a
Figure 2a: HTTP server test to with a spike in fetch time
Figure 2b
Figure 2b: Available bandwidth is greatly decreased during the same time period

In addition to TCP-based tests, ThousandEyes also supports ICMP-based available bandwidth to a specified target. This is typically used when targeting network devices, such as routers and switches that don’t have open TCP ports. The above test is measuring bandwidth from the client to the server. If you are interested in measuring bandwidth from the server to the client, you can either place an agent at the server side and target the client, or alternatively you can setup an HTTP server test that fetches an object from the server (figure 3) in order to approximate available bandwidth by looking at TCP throughput (this is the curl/wget equivalent). Make sure you have a large enough object if you do this.

Figure 3: HTTP Test measuring available bandwidth of an object from a server
Figure 3: HTTP Test measuring available bandwidth of an object from a server

At ThousandEyes, we’ve spent considerable effort in developing a bandwidth estimation technique that works in black-box scenarios, such as when enterprise users access third-party SaaS applications. This extra visibility is important to understanding performance bottlenecks when using SaaS applications, especially when overlaid with our Path Visualization capability.

To see how bandwidth affects your application performance, without the hassles or constraints of server instrumentation, start your free trial of ThousandEyes today.