* Re: [Bloat] Strategy for consumers
2011-05-14 0:07 [Bloat] Strategy for consumers jeff sacksteder
@ 2011-05-14 14:05 ` Jim Gettys
0 siblings, 0 replies; 2+ messages in thread
From: Jim Gettys @ 2011-05-14 14:05 UTC (permalink / raw)
To: bloat
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
^ permalink raw reply [flat|nested] 2+ messages in thread