No Matter What the FCC Says, Bandwidth Is Not Speed

FCC erroneously uses ‘bandwidth' and ‘speed' interchangeably

In its recently published Measuring Broadband America report, the FCC erroneously uses the terms 'bandwidth' and 'speed' interchangeably. The FCC should know better. ISPs claim to deliver high speeds if you buy their higher bandwidth services. This misleads consumers into assuming that a higher bandwidth connection will automatically deliver a faster user experience. In fact, bandwidth is but one of a half dozen factors that affect user response time (a.k.a. speed). (This posting is part of a series about NetForecast's newly published report FCC's "Measuring Broadband America" Report Tells Only Half the Story.)

The correct way to refer to the bandwidth is as capacity, NOT speed. Yet the FCC has chosen to adopt the ISP marketing term for bandwidth. Here is a simple equation NetForecast developed to explain the difference between speed and bandwidth. The equation is annotated showing who/what is responsible for each factor in this "speed" equation. ISPs are primarily responsible for just one factor.

Where:

Task response time (R) is the most useful measure of the speed of a user's experience. A task is each user interaction with the application during a session or process. Task time is measured from the time the user enters an application query, command, function, etc. requiring a server response, to the moment the user receives the response and can proceed. Some call this "user wait time"-or in the case of the Web-"page load time" (PLT). The aggregation of these individual task completion times defines application "responsiveness" perceived by the user.

Payload is information content in bits (8xBytes) that must be delivered to/from the user's device. It is determined by the application or website developer.

Bandwidth is the minimum capacity (in bits per second) across all network links between the user and the application server. The slowest link is typically the user's access line to the Internet that is supplied by the user's ISP. Effectively useable link bandwidth may be reduced by congestion and protocol inefficiency (e.g., small TCP window size).

AppTurns are the application client-server software interactions (turn count) needed to generate a user-level system response or task. Turns are determined by those who program an application or website. They do not include two-way TCP interactions (e.g., ACKs). Newer browsers try to mitigate AppTurns by operating multiple parallel connections to the server(s). In practice this modestly improves overall response time.

Latency is the round-trip-time (in seconds) between the user and the application server. Latency is determined by the physical user-server distance which is limited by the speed of light and the number of switching hops that each packet must traverse. Latency due to distance is governed by the speed of light. Latency due to hops is determined by network topology. The distributed nature of the Internet creates the need for many hops between two points (all users cannot be one hop away from all sources). Latency measured between a user and server is actually the sum of two paths:

  • ISP - the distance and hops required to traverse the user's local ISP until the user's packets reach the public Internet. ISPs can make this path efficient.
  • Internet - the distance and hops over the Internet required to reach the server. Neither the ISP nor the user can have any effect on the round trip time (RTT) of this path.

Cc (Compute Client) is the total processing time (in seconds) required by the client device.

Cs (Compute Server) is the total processing time (seconds) required by the server(s).

Note that the AppTurn-Latency product is most often the largest factor affecting response time and broadband ISPs have essentially no control over it. Today's typical web pages often require more than 100 AppTurns to load.

It is unhelpful, confusing, and we suggest just plain wrong, to use bandwidth and speed interchangeably. We suggest that the FCC and ISPs begin referring to bandwidth as capacity, and to define it as one of many factors that can contribute to a faster user experience. For proper clarity, ISPs should tout 'high capacity' rather than 'high speed' Internet connections.

The formula presented above quantifies response time or 'speed' of transactional applications like the web, online games, email, etc. It does not apply to streaming applications such as video, music, online radio, etc. Higher bandwidth will improve the quality of these applications by permitting higher resolution video and better fidelity audio. More bandwidth will also enable a household to operate more video/audio streams at the same time (more users watching different programming). The important point is that in this application category bandwidth also does not translate to speed; it directly translates to capacity.

However you look at it, bandwidth is capacity that enables applications and devices to do more of what they do. Digital devices and applications consume bandwidth capacity just like a car consumes gasoline and a refrigerator consumes electricity. Putting more gas in the tank does not make the car go faster.

Click here to get the FCC report.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT