From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qw0-f43.google.com (mail-qw0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7B2C5201AD0 for ; Sat, 14 May 2011 06:56:55 -0700 (PDT) Received: by qwf6 with SMTP id 6so2549642qwf.16 for ; Sat, 14 May 2011 07:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:organization :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=jO8X9YLI+X9rmOmdO+80N1r8DVgMjv8NcgDEZ4C5+eQ=; b=xcfzCfXdvYzp/NZbfrXpaUe6d79dLcf/YHbRXx1oHDWhayKuok0Z/ljCEqfHkE52HT VsztIVZlT+y2gYKo2n78zdgQJpj54D26wtLNN+fFsIvpl0WRHO0KM3bXzukNmWjKVyRa WntrTsfAlDBAh3WN35TYd+qu1JqMZPW/u4l8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=p/PR8RKTO2Keux6gp9nxyZrE8nvB56EnhCMOdDlOPZ00JEekhQQ/5rWryxcN3/XHDt gkM1X8RPqXFhYRvC6E/qESdrx2mfPR6YxuaS1YIJyvj5MlkuhoIYRF/UcXRfWhT/T047 yymZkI9pJBSSAjqBGIjgJ51bK1f1Wi9eGJiXM= Received: by 10.229.1.106 with SMTP id 42mr1992791qce.184.1305381937445; Sat, 14 May 2011 07:05:37 -0700 (PDT) Received: from [192.168.1.119] (c-98-229-99-32.hsd1.ma.comcast.net [98.229.99.32]) by mx.google.com with ESMTPS id c27sm2008559qck.10.2011.05.14.07.05.35 (version=SSLv3 cipher=OTHER); Sat, 14 May 2011 07:05:36 -0700 (PDT) Sender: Jim Gettys Message-ID: <4DCE8C2E.1090902@freedesktop.org> Date: Sat, 14 May 2011 10:05:34 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] Strategy for consumers X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2011 13:56:56 -0000 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