From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) (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 EA59C20061F for ; Tue, 11 Oct 2011 05:40:21 -0700 (PDT) Received: by wyh13 with SMTP id 13so11236498wyh.16 for ; Tue, 11 Oct 2011 05:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=rvi8LO51CZTV40cSTEjlBwgjsyRD+kt0mjC/WBiFwgk=; b=Hq6oLB3DkXWzoGULgsWP2sqWFEd3qsyum8HrsF545+jjNOuy5bY2Fd+aQkW6ZaXzt2 7ywO9lsKl6gLou0al5OfpsbXOesLwboU3pT91tlm08bGCEdmRKAwB0H965kUa406pQtx GrzJ4RFgpIZBFdcyshYcpK95x+HqMhdeHVUYU= Received: by 10.216.139.5 with SMTP id b5mr1822773wej.19.1318336819956; Tue, 11 Oct 2011 05:40:19 -0700 (PDT) Received: from [192.168.0.63] (lincs-gw.enst.fr. [137.194.164.55]) by mx.google.com with ESMTPS id j18sm38342649wbo.6.2011.10.11.05.40.18 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 05:40:19 -0700 (PDT) Message-ID: <4E943931.5050508@gmail.com> Date: Tue, 11 Oct 2011 14:40:17 +0200 From: =?UTF-8?B?RGF2aWQgVMOkaHQ=?= Organization: Bufferbloat.net User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net, eric.dumazet@gmail.com References: <4E941A05.2050705@gmail.com> <20111011115816.GA24956@uio.no> <1318335234.2538.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> In-Reply-To: <1318335234.2538.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Content-Type: multipart/mixed; boundary="------------020300030501030105020503" Subject: Re: [Bloat] a flood of Bufferbloat-related papers 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: Tue, 11 Oct 2011 12:40:22 -0000 This is a multi-part message in MIME format. --------------020300030501030105020503 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10/11/2011 02:13 PM, Eric Dumazet wrote: > Le mardi 11 octobre 2011 à 13:58 +0200, Steinar H. Gunderson a écrit : >> On Tue, Oct 11, 2011 at 12:27:17PM +0200, David Täht wrote: >>> On my list already would be "an analysis of the effects of broken sack >>> processing on linux 2.4.24-3.1", of which I *think* I've captured >>> multiple examples of in the raw traces I've been collecting for >>> months... (so if anyone is interested in the raw data, I can provide) >> Do you have any more information? The only thing I could find online was that >> there were SACK issues that were supposed to be fixed by 2.6.16; nothing >> about a fix in 3.1 or post-3.1. >> > Of course, instead of discussing all linux stuff privately, it would be > good to discuss with linux network maintainers. > > Or is the goal is to provide nice papers only ? hmm? 0) I know there are enough linux network maintainers on the bloat list for me to not consider anything typed here private! If you would prefer that the previous message had been sent more broadly (netdev?) please feel free to forward. 1) Lord, no, I'm far more interested in Linux working well, and having a short diagnose, fix, test cycle, than having nice papers. Staying within 2 kernel release cycles is fastly superior to dozens. Having nice papers helps, however, particularly on problems that have existed a long time, and can be analyzed - in particular - as to the effect on what other datasets that occurred during this period. On my bad days I think we're going to have to re-run the last decade's worth of experiments on ECN, congestion control, AQMs, and wireless across every protocol that has ever been experimented with until the bufferbloat problem is thoroughly licked. on my good days... well, I don't have a lot of good days 2) My problem with publishing data collected from various tcp traces I've been collecting is that of preserving privacy and anonymity to the end user from where I collected the traces. For example, I got a very interesting trace today showing very interesting ipv6 sack-related behavior from a friend of mine's home over free.fr - but I'd be very reluctant to make that widely available without permission. Now, I don't have that restriction on data collected from more public places, or in my own tests of cerowrt - but I have to say that I have mostly only seen lots of sacks over the LFN, where my data sets are more limited, at present. If you are interested in collecting your own data set, jupiter.lab.bufferbloat.net is a cerowrt router located in bloatlab 1 at ISC.org in san francisco. http://www.bufferbloat.net/projects/cerowrt/wiki/BloatLab_1 and is running linux 3.04, with netperf 2.5 enabled for both IPv6 and ipv4, with all the cerowrt related configuration changes to date. High on my list is measuring lfn performance with the vastly decreased amount of buffering presently in that system both for single and multiple streams - and then move on to analyzing the newer AQMs now in Linux. io.lab.bufferbloat.net is an x86 netsonar box, running 2.6.16 - netperf 2.5 as well - configured as per the shipping linux defaults. I hope fairly soon, to update another router (europa) to the latest and greatest tcp/sack code now that the kernel.org problems are settling down. It is my hope that this is the last tcp-related issue that can skew the results - and for all I know, without analysis, may not skew the results... We are still playing with nuttcp and iperf, and there are several bufferbloat related changes in the next version of netperf's svn tree that need to settle down some. If there is more I can do in providing test facilities and valuable feedback to the networking maintainers, please let me know. 4) I personally find sack very interesting in the case of wireless as it could be used very effectively (or so I think) in reducing the amount of needed packet aggregation in wireless-n - and thus retries and buffering, and I'm glad to see people working on improving it. -- Dave Täht --------------020300030501030105020503 Content-Type: text/x-vcard; charset=utf-8; name="dave_taht.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dave_taht.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6RGF2ZSBUPUMzPUE0aHQNCm47cXVv dGVkLXByaW50YWJsZTpUPUMzPUE0aHQ7RGF2ZQ0KZW1haWw7aW50ZXJuZXQ6ZGF2ZS50YWh0 QGdtYWlsLmNvbQ0KdGVsO2hvbWU6MS0yMzktODI5LTU2MDgNCnRlbDtjZWxsOjA2Mzg2NDUz NzQNCngtbW96aWxsYS1odG1sOkZBTFNFDQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------020300030501030105020503--