Home / Blogs

What’s the Right Definition of Upload Speed?

I read a blog on the WISPA website written by Mark Radabaugh that suggests that the best policy for broadband speeds would be met by asymmetrical architecture (meaning that upload speeds don’t need to be as fast as download speeds). I can buy that argument to some extent because there is no doubt that most homes download far more data than we upload.

But then the blog loses me when Mr. Radabaugh suggests that an adequate definition of speed might be 50/5 Mbps or 100/10 Mbps. I have seen enough evidence during the pandemic to know that 5 Mbps or 10 Mbps are not adequate upload speeds today. My consulting firm conducts speed tests and surveys for communities, and during the pandemic, we’ve learned a lot about upload demand.

We’ve seen consistently in surveys that between 30% and 40% of the families that worked or schooled from home during the pandemic said that the upload connections were not adequate. Many of the respondents making this claim have lived in cities using cable company broadband with upload speeds between 10 Mbps and 20 Mbps. While those speeds may be adequate for one person working from home, they were clearly not adequate for multiple people trying to use the upload connection at the same time.

But it’s not quite that simple, and we need to stop fixating on speed as the way to measure if a broadband connection is adequate. Many of the people who find home upload speeds to be inadequate complain about inconsistent speeds. They’ll connect easily enough to a work or school server or a Zoom call but eventually get dumped out of the connection. Speeds on most technologies are not constant and bounce up and down as demand changes in the neighborhood. A 10 Mbps upload connection is not adequate if there are times when the speed drops below that speed, and connections are dropped. Inconsistent broadband connections can also be related to poor latency and heavy jitter.

The latest grant requirements from the NTIA for using ARPA funding describe the issue succinctly. The NTIA says that the ARPA grants can be used in places where an ISP is not “reliably” delivering speeds of 25/3 Mbps. Reliability is a long overdue concept in our discussion of broadband because, unfortunately, many of our broadband technologies deliver different speeds from minute to minute and hour to hour. We cannot keep pretending that a WISP, DSL, or cable modem service that delivers 15 Mbps upload sometimes but a 5 Mbps connection at other times is reliable. Such a connection ought to more appropriately be labeled as a 5 Mbps connection that sometimes bursts to faster speeds.

The WISPA blog also fails to mention the context of discussing a speed requirement. There is a big difference in setting a definition of speed for today’s broadband market versus setting an expected speed for a project that’s being funded by a federal grant. We should never use federal grant funding to build broadband that just barely meets today’s definition of broadband. It’s an undisputed fact that households, on average, use a lot more broadband every year. We know that the amount of bandwidth used by households is likely to double every three years. If we build to meet today’s broadband demand, a network will be obsolete within a decade. Grant funding should be used to build networks that meet expected future needs.

I often tell stories about network engineers who undersize new transport electronics. While they know that broadband demand and traffic have been doubling on their networks every three years, they just can’t bring themselves to recommend new electronics that have ten times today’s capacity. Even experienced engineers have a mental block against truly believing the impact of growth. But anybody designing a network needs to be looking to make sure the new network is still going to be robust a decade from now.

It’s just as essential for policymakers to understand the incessant growth in broadband demand. When talking about awarding grants, we shouldn’t be discussing the current definition of broadband but instead the likely definition of broadband in a decade. That’s the big point that the WISPA blog misses. I think it’s easy to demonstrate that 5 Mbps or 10 Mbps is inadequate broadband speeds today—we have too much evidence that upload speeds need to probably be at least 25 Mbps. But we can’t accept today’s upload needs when funding new networks. Grant-funded networks should be forward-looking—and I think the NTIA’s suggestion of 100 Mbps upload for future networks is reasonable.

By Doug Dawson, President at CCG Consulting

Dawson has worked in the telecom industry since 1978 and has both a consulting and operational background. He and CCG specialize in helping clients launch new broadband markets, develop new products, and finance new ventures.

Visit Page

Filed Under


Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign

Brand Protection

Sponsored byCSC

Domain Names

Sponsored byVerisign


Sponsored byDNIB.com

New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global