[Bloat] Strategy for consumers

[Jim Gettys]

On 05/13/2011 08:07 PM, jeff sacksteder wrote:
> I've recent moved to an area(Frontier Communications) with a serious
> bufferbloat problem on it's consumer DSL products.
>
> Maybe I'm not looking in the correct places, but has there been any
> discussion of contacting the NOC operators or network engineers at
> various ISPs to make whatever remediation is possible through
> configuration changes? It might also be useful to have a database of
> configuration changes on specific equipment to point to in the event
> that you are actually able to speak to a qualified network engineer.
I've been invited to present at the Denver NANOG meeting next month.

I will certainly highlight the classes of mitigations ISP's should start 
doing, but as I'm not intimately familiar with all their equipment or 
the technologies they use, most of it is by its nature left to them.

We'd be very happy for network operators to use the bufferbloat.net wiki 
to start organising configuration information and sharing information 
(and if there is need for a mailing list, happy to host that too).

There is a couple year old paper ("Characterizing Residential Broadband 
Networks", by Dischinger, et al. 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.65.6825&rep=rep1&type=pdf) 
that indicates a good chunk (> 30%) of network operators are failing to 
run queue management (e.g. RED) on the broadband head end equipment 
where it is likely they can (and should) do so and where RED can be 
effective.
Making sure your ISP understands the importance of AQM in their network 
where it's needed is also you can work on: please, please be polite and 
gentle as the mistakes we've made are all over and we're all in this 
bloat together.  There are good reasons as I blogged why some network 
operators have been somewhat shy of using AQM. 
http://gettys.wordpress.com/2010/12/17/red-in-a-different-light/

As to the broadband technologies themselves, I'm not intimately familiar 
with them to know how much, if any mitigation to bufferbloat in the CPE 
and head end equipment is possible.  In the cable case, I do know they 
have already added a feature to the DOCSIS protocol spec to enable the 
CMTS to control the buffering in the cable modem and are testing that 
addition now.  Whether existing cable modems will be able to or actually 
will be updated with fresh firmware loads to support it, I have no clue, 
but don't hold your breath, if that industry is anything like home 
routers (where seldom is seen a firmware update after the hardware is 
shipping and is stable). I suspect only the most recent equipment is 
going to ever see an update to support it, and I don't know when new 
equipment will ship to stores you can buy, nor when support for it will 
be deployed to the CMTS's

By bandwidth shaping (as I showed in my blog) you can do alot to reduce 
your personal suffering due to bufferbloat, so you have no reason to 
wait before taking personal action.  You can't personally get your 
DSLAM's AQM enabled, nor deal with under-provisioned DSLAM's (which can 
cause your bandwidth shaping attempts to not always work because they 
can only presume your ISP gives you what you pay for), but you can do a 
lot immediately, and we'd love it if people come help the home router 
work that is underway (see the bismark mailing list hosted here) and 
just getting to the point of needing testing.  On our list is to 
resurrect Wondershaper, etc, as well.

The additional advice to you and others personally, beyond the above, is 
to arrange that your wireless bandwidth is *always* higher than your 
broadband bandwidth.  To solve bufferbloat in the hosts and home routers 
is a challenge: we have test Linux kernels for testing debloating 
pateches of various sorts, but no way to do anything for Mac and 
Windows.  So while we plan to start testing AQM in the home router (both 
for the uplink and for the local routing), unless you are a Linux guy 
and want to test debloated Linux kernels, your best bet is to arrange 
the bottleneck to always be in the broadband hop where you may be able 
to successfully control it (as I have) with bandwidth shaping (I now get 
really nice behaviour, at some cost to my bandwidth).

Otherwise your host uplink bufferbloat and home router bufferbloat will 
likely bite you at times and can be even worse than the broadband link.  
You may want/need to have more than one access point in your house to be 
able to make this guarantee.

Also note that the wireless bitrate has little to do with actual data 
transfer rate, which is what matters for keeping buffers safely empty.  
For example, 802.11g seldom achieves much more than 20Mbps of actual 
data transferred despite being nominally 54Mbps; you have to also 
include all the wireless framing and TCP/IP packet overhead.  So it is 
much easier than most people think for their wireless bandwidth to drop 
below their broadband link, and wireless is designed to drop its 
bandwidth to be able to reach further.  So long as we have static 
buffering (and often grossly bloated static buffering), under load, 
you'll get burned badly this way with dismaying regularity, as those 
buffers fill.

Again, the WNDR3700v2's were starting on our home router work with are 
able to run 802.11n, so they are a good candidate just to ensure the 
802.11 hop is not the bottleneck (but you may need 802.11n in your 
laptop too to ensure you really always have higher bandwidth in the 
wireless link than in your connection.  Your mileage WILL vary, for all 
the reasons wireless varies (e.g. where your AP is, walls, chimneys, 
phase of moon, how much bandwidth you get from your ISP, how much you 
pay for, etc.).

If this had all been easy to see and understand, bufferbloat would have 
been long since uncovered and fixed.  But by it's nature, it is a 
whll-o-the-wisp that moves around, and laboratories have not been the 
best place to test for it.
                             Best