Broadband Bandwidth Hogs: Myth or Reality?

 |  Includes: S, T, VZ
by: Yankee Group

By Carl Howe

Ace Yankee Group colleague Benoit Felton and co-author Herman Wagter have written a stunning article challenging the premise that bandwidth hogs force broadband operators to impose bandwidth caps (he has since written a clarifying update too). Technical analysis site Ars Technica has written its own article in praise of the analysis captioned, “Hunting the mythical bandwidth hog”, along with similar articles on sites such as Slashdot, Gizmodo, and Techdirt. Herman authored an article discussing the technical details of how heavy net use affects network chokepoints. I’m sure other articles pro and con will follow. But I’m following this discussion avidly because I think that Benoit is right: in my admittedly ancient experience, bandwidth hogs shouldn’t cause disproportionate harm to TCP/IP networks.

Now I admit to having a fairly geeky perspective on this. For 18 years of my career, I was a computer scientist at Bolt Beranek and Newman (BBN). That was a time in which TCP/IP and the Internet grew from an interesting research project to a system used around the globe. As well as being a TCP/IP researcher and developer itself, BBN actually ran network operations centers (NOCs) for several TCP/IP networks, including ARPANET, MILNET, SATNET, Internet, NSFNet, and others. I saw software engineers and DARPA principal investigators build the most reliable TCP/IP implementations they could think of, while other engineers took adversarial glee in trying to break those implementations. Thanks to government subsidies, the networks on which those implementations ran appeared free to university students, and they would happily try to “hog” the networks 24 hours a day, 7 days a week. Yet through it all, the Internet was was by far the most reliable way to move bits, even when everyone else was trying to do the same thing.

Yet as you can see from the image from the 1990s at the top to this post, when people would walk into the BBN Network Operations Center that managed our pieces of the world-wide Internet, the most common reaction was, “This is it?” It would usually have 3-5 people working on terminals or talking on the phone; on weekends or holidays, that might be only two. Unlike at some telcos at the time, people didn’t directly manage the network and deal with problems and failures; the network—or more precisely, the TCP/IP and router algorithms— managed the network.

When I read the comments associated with Benoit’s article, though, I sense that many readers can’t believe that automated network protocols can properly deal with bandwidth hogs and not drive the network to go into some sort of congestive collapse. Most people don’t have experience with network congestion policies and design, so I thought a simple analogy might help.

Think about a gym membership. You sign up right after New Years with the idea that you’d like to get fit and trim. Most gym contracts promise you unlimited use of the equipment, so you sign up for the special deal that commits you to a full year of $50 monthly payments.

Now imagine that you decide that you want to train to qualify for the Olympics at your gym. That means you’re at the gym every day, and you’re there for 4 to 8 hours at a stretch. Do you think that you’d be labeled a “gym hog”?

I don’t know about your gym, but I don’t know any that turn away people training for the Olympics, even though gyms make their money on people who sign up and don’t exercise. Your gym hogging activities, despite being pretty intense for you, don’t break the machines or otherwise destroy the gym’s business, largely because gyms are sized to handle a reasonable population of users. In fact, those that find themselves with a surplus of athletes training for the Olympics will probably start putting their posters in the lobby, in hopes of signing up more of us for the gym.

Now I can imagine someone complaining at this point saying, “But what if I design a gym that only has one machine?” Won’t the Olympic-training gym hogs ruin that experience for everyone by taking up all the machine time? The answer is yes, but that’s because unlike a TCP/IP network, the gym has no flow-control mechanism. If it did, any time another person asked for a machine, the Olympic athlete’s time would be throttled back to a fair share (probably by a gym attendant, which is how it happens in the real world). Again, no congestion collapse occurs. In fact, the gym can sign up as many subscribers as it wants, and they’ll all get roughly an equal share. It’s the design of the gym that determines whether an equal share provides a good user experience (the machines are available when I want them) at the same time as a good business experience (lots of income).

I encourage everyone to read Benoit’s article, because in it, he issues a challenge. He’s asked operators to submit data that proves that individual bandwidth hogs can cause unfair degradation of the network (i.e., causes the network to degrade more than a fair share bandwidth allocation). Benoit has offered to analyze submitted data for free and report the results. If bandwidth hogs really do exist, he’ll document the data and retract his statements. But if no one is able to disprove his assertion with hard data, he’ll note that as well.

No matter what you think the results will be, Benoit has opened up an great topic for discussion in this era where everyone is debating topics such as the prioritization of traffic and network neutrality. But what’s even better is that he’s asked for hard data, both pro and con. And in case anyone thinks Benoit or Herman are in the thrall of the FCC, please note: they both live in Europe.