-->

Broadband vs. Internet Speed: Not So Fast

An email I received this afternoon contained a forwarded link to an article entitled “Conflating broadband speed with Internet speed is misleading“. The article makes a valid point that access capacity (“Broadband speed”) isn’t the same thing as end-to-end throughput (“Internet speed”). Clearly this difference is valuable for consumers to understand, and is a critically important distinction in the Network Neutrality debate.

Which is why I’m disappointed in the article; sadly, it oversimplifies the issue to the point of covering up critical details.  The comparison to fax technology is imperfect, maybe even flawed. It conjures an incorrect conclusion in the mind of a reader. And the material result of this is to avoid a discussion of provider responsibility for effective bandwidth.

To be clear, end-to-end throughput across a network is affected by everything in between the two hosts (computers) that are communicating. It is affected by the equipment, configurations, and interconnects. It is also affected by the capability of the transport protocols, round-trip latency, packet overhead, and more. In this regard, the article is correct to say that effective bandwidth shouldn’t be compared directly to broadband access capacity. But likewise, to compare the effective bandwidth to the coding rates of fax machines is a vast oversimplification.

Looking at the factors that might affect end-to-end performance, a number of those are directly in the hands of the network provider.  The access link (i.e. broadband connection) to the customer is just the first component.  It terminates in an edge / aggregation network that is probably oversubscribed.  The edge networks may be interconnected across a backbone, with its own bandwidth constraints and physical distance inefficiency.  And Internet connectivity, to the backbone or to the edge network directly, is enabled by a number of peering and/or transit connections that are not necessarily equal.  This isn’t even considering the possibility of NAT, security, or bandwidth management devices that might constrain effective throughput.

When all is accounted for, there may be a considerable oversubscription rate.  Not that oversubscription is inherently bad; most users aren’t using 100% of their bandwidth at the same moment in time, allowing the provider to time-multiplex their users without causing negative performance.  And this oversubscription allows the provider to make money in an otherwise low-margin business.  But because it’s hard to determine how oversubscribed a provider is, they’re often tempted to push costs lower by oversubscribing more.  (Which is evident when providers get irritated by increasing usage, such as P2P traffic, by their customers.)  Further, the Internet transit connections might be acquired on-the-cheap, offering lower quality network paths (read: more oversubscription, more latency).  And the effect of these choices directly accrues against end-to-end performance.

Now, to be clear, I’m not advocating regulation of how service providers build their networks.  It should be up to each business to determine for themselves what is an effective network topology, interconnect strategy, oversubscription rates, etc.  But to focus the entire network debate on the access connections while ignoring the complex network that interconnects those to the Internet is misleading.

  • http://www.queuefull.net/~bensons/ Benson Schliesser

    Since I published this yesterday, the original article “Conflating broadband speed with Internet speed is misleading“ was updated with some more information about the effect of latency on TCP. It also now includes a recommendation to use multiple streams to measure effective throughput. This is a good addition to the article, and gets closer to the truth. Still no discussion of provider oversubscription, but a step in the right direction.

  • georgeou

    “The fax analogy is not very strong. In fact, it misleads the reader to conclude that broadband access speeds on each end are all that matter.”

    The fax analogy was admittedly an oversimplification, but it made a very good point about the problem with the recent FCC report and sensational media headlines. Your criticism would carry some weight if the fax analogy was all I offered, but I went into great detail as to what can cause single-download Internet performance to drop and most of those factors were not due to the ISP in any way.

    I discussed the following factors.

    1. Broadband service peaks substantially lower than advertised e.g, sync rates don’t even meet advertised speeds. This rarely occurs in the US (though it could be improved) but it is common in the UK. This should be blamed on the broadband provider.
    2. Actual payload performance is generally 85% to 90% of sync rate performance on DSL services advertised at sync rates. While the issue is more minor, it deserves to be fixed. This issue doesn’t affect newer services like AT&T U-verse, Verizon FiOS, and cable broadband services because they advertise actual data rates.
    3. Server performance is generally the most common issue. This could be due to server congestion, network congestion, or the TCP speed limit and performance penalties of latency even when the server/client/network can support much higher multi-flow TCP or UDP speeds.

    I offered a much more thorough debate to broadband transparency here.
    http://www.digitalsociety.org/2009/09/the-need-...

  • http://www.queuefull.net/~bensons/ Benson Schliesser

    Thanks for the link to your post “The need for a broadband transparency standard” (http://www.digitalsociety.org/2009/09/the-need-...). It does a better job outlining the issues, including a reference to oversubscription which is missing in your more recent article.

    If you confine your view of the service provider's performance to sync rates and frame overhead, then it's a logical conclusion that the server is to blame. That's the direction in which the fax machine analogy misleads the reader. To your credit the article was updated to talk about transmission protocol (i.e. TCP) performance, which is another important factor. But it's a factor that can't fairly be assigned to anybody (user, server, OS vendor, broadband provider, etc) which I suspect is why you're happy to include it.

    My frank suggestion is that you also consider more of the “middle” of the network path, specifically focusing on the part that is managed by the broadband service provider. Since oversubscription rates (on aggregation and core routers, as well as transit and peering links) within a broadband provider's network are critical to performance, I don't understand why you're hesitant to address them. Your comments on the New America OTI proposal (http://www.digitalsociety.org/2009/09/problems-...) also express a desire to avoid looking at oversubscription.

    If you think oversubscription shouldn't be regulated, I agree with you. Oversubscription may not even need to be documented, per se, since it will be misunderstood and can be easily gamed. But it should be examined in the conversation. Perhaps the result of such a discussion is to agree on a proxy or set of proxies for network performance (such as packet loss, latency, and jitter) as it might be impacted by oversubscription. Commercial ISPs do this already in Service Level Agreements; might it be a good method for broadband providers to represent their network quality?

  • georgeou

    I'm not sure why you keep saying that I don't want to talk about oversubscription when I specifically address the issue in my transparency article. Nothing could be further from the truth. The latest article is specifically talking about the problem with the FCC report that completely misrepresents the issue and I'm under no obligation to repeat every point I've ever made in the past when I'm trying to focus on a specific issue in a specific blog post.

    My transparency article does in fact talk about all the ISP issues that slow the end-user down including oversubscription and dynamic video bandwidth sharing e.g., U-verse TV. What I tried to do is come up with a simple way to measure and report oversubscription. Read the section on “Computing the average achievable performance of broadband”. As far as I'm concerned, the ISP is responsible for any contention that touches their own network. However, the transit bandwidth issue can only be solved through more in-premise or same-IXP (Internet Exchange Point) caching over more peering connections paid or unpaid. There's simply no feasible way or even technical way to make the core of the Internet support every gigabit end point on the planet concurrently.

    My problem with the OTI proposal is that they're calling for no more than 2:1 oversubscription which would be pure fantasy. Topolski's demand that ISPs have to write a check to the end user for not ensuring 50% minimum performance is silly because that would simply mean that the ISP would have to charge higher rates to begin with. As you even pointed in your article above, the low margin characteristic of broadband makes higher oversubscription ratios a requirement. This is especially true when consumers are so price sensitive.

  • georgeou

    “Oversubscription may not even need to be documented, per se, since it will be misunderstood and can be easily gamed.”

    If you understand that, I'm not sure why you keep hammering me about it when I go out of my way to talk about all ISP issues. As I said in my previous response, core contention can't be solved on a technical basis simply because the amount of aggregate traffic coming from the end points can always exceed the fastest fiber connection on the planet. The long-haul transit links will likely run the quickest fiber transceivers possible anyways since it's the cable plant that's the most expensive part of the game. Furthermore, caching is the fundamental solution for video on demand.

    Caching can't be applied to real-time communications e.g., video conferencing. But that's a lot less traffic that the Tube sites because it's just a lot less popular. So the long haul connections should be used for things that can't be cached and that's pretty much what's happening already. The TCP speed penalty turns out to be a good limitation as it offers a great incentive to build things near the end users.

    The type of contention that really needs to be solved is the last few miles. Once you have a network of 10,000 plus broadband users, it becomes economical to cache things for them. The cable industry faces a deeper problem of contention on the last mile as well as the backhauls near the end users. The Telcos don't really have to worry about the last mile, but they do have to worry about the backhauls that connect those miniature DSLAMs.

  • Dave

    You can ignore George, he's a known troll whose organization lobbys on behalf of the likes of AT&T and Comcast.

blog comments powered by Disqus