I know it’s not anyone’s idea of fun to monitor gigantic specs; I certainly don’t do so. I think the following tidbit, while public information, has not been noticed by people.
The cable data spec (DOCSIS) has an engineering change in progress to allow the control of buffering in cable modems that was published early this year. This will allow operators to at least mitigate (reduce) bufferbloat by setting the buffering to something related to the provisioned bandwidth, rather than the current state of buffering, which is either a) whatever size RAM happened to be available in the device, or b) is sized to be the (invalid) BDP “rule of thumb” for the maximum possible bandwidth that hardware might ever be used in (resulting in greatly overbuffered devices when used by most people at the typical bandwidths (e.g. 10Mbps service with a DOCSIS 3 modem capable of 100Mbps). The feature is called “buffer control” for those who want to dig into the specs.
As a concrete example, this might allow the modem I happen to have to have its worse case latency reduced from the 1.2 seconds I observed at 20Mbps to of order 100ms. This isn’t perfect, but it’s a whole lot better indeed. To really solve the problem to get latencies under load where they could be, we’ll need real AQM that can work in this environment, which is more of a challenge as noted for reasons elsewhere in this blog. I have no information as to whether any deployed cable modems will ever see new firmware to support this addition to the DOCSIS specification.
I gather than new cable modems that support this change to the DOCSIS spec will be in the market by late this year; but note that deploying the support elsewhere in ISP’s networks to configure them will take more time, and probably won’t happen until next year.
I have no information of if there are similar changes underway to modify the other widespread broadband technologies (e.g. DSL and fiber).
It is a good start to getting things fixed :-). Hopefully the market will now help to spread such mitigation steps in the industry.
jg's Ramblings 
December 3, 2011 at 12:47 pm |
I’m excited that you’re bringing some attention to this problem. But it’s grating to see the repeated assertion that nobody’s noticed this problem for years. People have been complaining and working around it with traffic shaping and other hacks for at least 10 years, probably more. It’s almost as if there’s a secret cabal running the Internet who listen to names like Vint, Van, and, er, Jim.
December 7, 2011 at 9:24 pm |
Individuals had noted individual problems. The Netalyzr data pretty definitively shows all of the broadband gear is in bad shape. That our operating systems also have problems (in multiple locations) is also went pretty unappreciated.
But indeed, with the exception of some of the details about the fact that slow start and congestion avoidance were also badly damaged by the size of the buffers, someone, somewhere had noticed the different aspects of the elephant. It’s the size and shape of the overall beast that’s much more serious than I think most had realized.
As the article points out in the introduction:
“This article does not claim to be the first to identify the problems of excessive buffering, but is instead intended to create a wider understanding of the pervasive problem and to give a call to action.”