In a recent blog my colleague, Phil Bull notes that there’s confusion over bandwidth and speed. This discussion started with an article on Network World’s website where Netforecast said “No Matter What the FCC Says, Bandwidth Is Not Speed”. Basically the FCC were bandying the term speed and bandwidth pretty interchangeably and NetForecast took umbrage to this saying that most users equate “speed” to their application’s performance i.e. Response time. They noted, as we have pointed out many times that other factors, such as loss, re-order and latency, were just as important as bandwidth in delivering this “speed”.
And, that’s totally correct, but it’s not complete! It’s worse than that Jim: Bandwidth is not equal to Link Speed either.
So, the ISPs and FCC probably really meant “link speed” when they used the term “speed” interchangeably with bandwidth. But when talking to customers we never do. In fact the distinction is so profound that some time ago we suggested to our developers that our Network Emulators be very specific on the terminology within their GUIs and documentation. I precisely define:
- Link Speed is the speed of the link
- Bandwidth is how much data you can actually transfer per second down the link
So, when the ISPs sell you a 20Mbps link they have sold you a link with a link speed of 20Mbps, but that doesn’t necessarily mean that you get 20Mbps of bandwidth.
Why?
Well we have little things like “contention”, Network QoS (Quality of Service) and Bandwidth Controls in place.
Contention: If the ISP sells links of 20Mbps to 20 people say, and these come together in a 100Mbps circuit further down the “road”. Then it’s clear that 20×20=400Mbps and so if everyone was to use their connection to download big files at the same time the 100Mbps would be overloaded. And that is exactly our experience. At certain times of day everything goes really slow. So to try make this “fair” to everybody the ISPs employ…
Network QoS: Prioritization (or de-prioritization) of certain traffic. e.g. gaming traffic or data downloads between certain hours. If they didn’t do this you might not be able to browse the web or read your email online at certain times. But sometimes even prioritization is not enough and they also use…
Bandwidth Control: Again at certain times certain network protocols (defined for this purpose “types of traffic”) may be given a specific restricted maximum bandwidth e.g. gaming, ftp, bittorrent so that it doesn’t overwhelm the network.
While all along your link speed remained at what they sold you, your available bandwidth did not. And it’s your available bandwidth that together with latency, jitter, loss, reordering, errors, and of course, your application’s design, that contribute to your Quality of Experience (QoE).
See more Network and Application Performance Blogs from iTrinegy