Communications - February 2012

that’s separate from the cable modem—you can track delay increase. Once the delay increase gets above a threshold of, say, 100 milliseconds, you can start using the RED approach for queue management or whatever it is you need to do to get the traffic to back off. The problem with this, however, is that it provides only an 80% solution for the telephony crowd.

JacoBson: If I understand what is being proposed there, you’re putting in an appliance to measure delay, but if you’re looking at aggregated traffic, you don’t know how it de-aggregates.

WeaVeR: That’s partially why this proposal focused on the home gateway. Basically, there aren’t all that many large flows going through your NAT box at any point in time.

JacoBson: But if you’re on the gateway, you’ve already got the queue, so you don’t need any state at all. The queue is its own state.

GeTTys: One of the reasons queue management is even being considered for home networks is because so many of the broadband networks don’t provide any. I recently read a paper that indicated as much as 30% of residential broadband networks run without any queue management whatsoever. That leaves it to the home routers to handle the problem. Then we’ve got the additional complication of the huge dynamic range presented by wireless. Van has told me that classic RED cannot be used to address that particular problem.

ceRf: I’m trying to think about how we might start moving toward a solution. It seems there are at least three different pieces to consider. First, there’s the party who’s suffering the effects of bufferbloat in, say, a residential setting. Then there’s the service provider that, I believe, really wants to provide a better quality of service for its customers. Finally, there are all those equipment and software vendors that might be persuaded to address the problem if they thought it would make the ISPs and end users happier.

The question is: under what conditions might we get all those parties to cooperate? Or is this going to remain largely a research problem?

WeaVeR: Well, there have been a
couple of cases where the application
vendors concluded they were caus-
ing too much damage and therefore
started making changes. BitTorrent
is the classic example. It is shifting to
delay-based congestion control specifi-
cally to: (a) be friendlier to TCP because
most of the data carried by BitTorrent
really is lower-priority stuff; and (b)
mitigate the “you can’t run BitTorrent
and Warcraft at the same time” prob-
lem. So, there’s some hope.

The bufferbloat problem is likely to worsen as the demand grows for Inter-net-intensive activities such as streaming video and remote data backup and storage, with the online user experience bound to deteriorate as a consequence. The problem is most visible at the edge of the network, but evidence of it can also be found in the Internet core, in corporate networks, and in the boundaries between ISPs. Besides calling for simple tools that people can use to find and measure bufferbloat, active queue management for all devices is also in order. The best algorithm for the job remains to be determined, however.