The Myths Of Bandwidth
by April 19, 2011

Filed under: Networking Technology, Performance Monitoring

Santa Claus.  The Easter Bunny.  Good tasting, fat-free snack foods.  Myths?  Maybe so.

But one absolute myth that is 100% untrue, and that 99% of the vendors of network performance solutions have been perpetrating for years (and whose users have been gobbling up like zero calorie french fries…) is the myth of bandwidth; more specifically, the myths of utilized and available bandwidth.

Myths of BandwidthBefore I do my online version of “Myth Busters”, let’s take a minute to define a few key terms, bandwidth and throughput.

Although often used interchangeably (and used differently outside the world of networking…) when it comes to IP networking, these terms refer to two very different things.

  • Bandwidth speaks to the capacity of a given network and
  • Throughput speaks to how many bits per second actually traveled across the network.


Ok, think of your network as a water pipe.  At a given fixed water pressure, the diameter of the pipe will determine the maximum amount of water that can flow through the pipe. That is the bandwidth.  A bigger pipe, more capacity (bandwidth) – smaller diameter pipe less bandwidth (capacity).

If we stood at the far end of the pipe and measured how much water arrived, now we know the pipe’s actual throughput.  If the pipe had perfectly consistent diameter along its’ entire length and there are zero leaks, and if the water only had to travel in one direction at the same speed all of the time, then the throughput and the bandwidth of the pipe would be the same.

Of course, even in your homes, there are often small leaks; and changes in the size and back-pressure of the pipes happen all the time as different faucets open and close. Very seldom does any system of pipes (even a small system like in your house…) manage to have the throughput come close to 100% of bandwidth (capacity).  It gets worse with complexity. If we look at municipal water systems across the U.S., the average system loss is 16% (or more than 800 billion gallons a year …) and many larger cities are dealing with losses of 20 to 30% or more. Yikes!

How does this relate to IP networks?

Well, if the bandwidth (capacity) was the exactly the same along the entire length of the network service delivery path (source IP to destination IP), the packets only travel in direction all the time, the distance the packets travel remains constant (no route changes…), and there was no cross traffic to deal with, zero packet loss or other slow downs (including duplex mismatches, MTU misalignment, QoS bits being stripped or remapped, serialization or processing delays, etc), then network throughput and network bandwidth would be the same.

But we all know that on complex WANs (or even a moderately complex LANs or Wireless LANs (WLAN), there are many conditions that prevent throughput from equalling bandwidth (capacity).  Since the primary determining factor of throughput is the actual bandwidth (capacity), getting your arms around this figure is the first step to understanding your actual throughput – and this is where the myth of bandwidth is most often passed along by vendors today.  Solutions that measure the “what is” bits per second (bps) values – regardless of if they get the bps values by asking the network elements themselves via SNMP, WMI or NetFlow or if they perform packet sniffing and count actual packets “on the wire” –  all chart those values against the provisioned (or theoretical…) capacity of the network based on a value the user enters.  Have a GigE network interface on your server? BAM!  Your maximum bandwidth is 1000 Mbps.  Leasing a T3 from your carrier?  Whammo! Your maximum bandwidth is 45 Mbps.  Then the vendors chart the measured “what is” bps values against the user entered total bandwidth values and you in turn get a mythical utilization and available bandwidth result. Lions, tigers and bears – oh my!

There are other commercial and open source solutions that attempt to measure network throughput via packet flooding. However, many of these solutions propagate the reverse myth that throughput equals bandwidth (capacity).  Of course running a packet flooder can only give you an accurate throughput value when the nothing else is running on the network (when is that again?) and these kinds of solutions tend to really annoy the application owners because they completely fill up the network.  But from a pure performance measurement perspective, their throughput results really tell you nothing about bandwidth (capacity) – they tell you the throughput of your water pipes, but you have no idea if the diameter is in fact what you’re paying for.  The myth goes both ways unfortunately.

Yet the biggest danger of the bandwidth myth is that you don’t really have an accurate and timely understanding of the true capacity of your service delivery paths.  If you operate your network (and support the applications that in turn rely on the network…) based on the mythical figures produced by your SNMP tool, you may in fact be operating FAR closer to point of application failure than to you realize. Far worse, you may ALREADY be experiencing application failure or other application delivery quality issues and looked your bandwidth chart and said “Well, I’ve got plenty of available capacity, so that’s not it” when that was PRECISELY the problem which resulted in high loss, or irregular jitter patterns that made your application delivery suffer.   You were the victim of a false negative, which often are hardest things to deal with when troubleshooting.

The path-based technology in PathView Cloud is in fact a real-time myth buster.   Through a patented methodology that measures the true end-to-end service delivery path, we determine the layer 3 network’s true maximum achievable capacity (bandwidth) and the utilized capacity and can therefore paint the true picture of available capacity. This works over any IP-based network be LAN, WAN, Wifi or satellite and you can measure the true network capacity across third-party networks and even into end-points that you have no access to, cloud-based or otherwise.   The best part is that we do this every 60 seconds with such a low touch (around 20 packets per minute…), that your applications won’t even know we’re there standing guard.

On a complex network it’s pretty rare to have bandwidth (capacity) be equal to throughput, in fact I’m pretty sure if such a network does exist, you’ll find the Easter Bunny having a fully immersive video conference with Santa Claus, each watching the other enjoying their delicious zero calorie french fries.