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 B56BD201A3B for ; Tue, 11 Oct 2011 05:17:04 -0700 (PDT) Received: by wyh13 with SMTP id 13so11197706wyh.16 for ; Tue, 11 Oct 2011 05:17:02 -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=2Xbf11KTmg4tX3Ti3r2C7m3jyVDj4B28tQt0zoEmQNw=; b=GwLTYd/pg1lVFwRp5KQpAVhJnOinTZPcXex+xr0+l6nryoCpJ9gXdAQHVW38I35Ajs 9lwOd3GLOcR7K9cNvaRbzVgeoe4Zd5tbWLdvnBsAKXVAXuEZuu8lewXsLIyTMGQWg26M EUcKk2FozP7D9q/CjISRcYCAPiqcQIZyQg8VQ= Received: by 10.216.24.21 with SMTP id w21mr724441wew.57.1318335422509; Tue, 11 Oct 2011 05:17:02 -0700 (PDT) Received: from [192.168.0.63] (lincs-gw.enst.fr. [137.194.164.55]) by mx.google.com with ESMTPS id a12sm30435871wbo.9.2011.10.11.05.17.01 (version=SSLv3 cipher=OTHER); Tue, 11 Oct 2011 05:17:01 -0700 (PDT) Message-ID: <4E9433BD.3000102@gmail.com> Date: Tue, 11 Oct 2011 14:17:01 +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, sgunderson@bigfoot.com References: <4E941A05.2050705@gmail.com> <20111011115816.GA24956@uio.no> In-Reply-To: <20111011115816.GA24956@uio.no> Content-Type: multipart/mixed; boundary="------------030407020708020401080001" 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:17:05 -0000 This is a multi-part message in MIME format. --------------030407020708020401080001 Content-Type: multipart/alternative; boundary="------------030904090008040807030509" --------------030904090008040807030509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. This was a typo on my part - 2.6.24-3.1, not 2.4 The specific commit that concerned me was this one. I had seen multiple cases of odd behavior (basically tcp sacking like crazy until the cwr collapses or a tcp reset) that I *think* this fix explains. commit f779b2d60ab95c17f1e025778ed0df3ec2f05d75 Author: Zheng Yan Date: Sun Sep 18 22:37:34 2011 -0400 tcp: fix validation of D-SACK D-SACK is allowed to reside below snd_una. But the corresponding check in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo. Signed-off-by: Zheng Yan Acked-by: Eric Dumazet Signed-off-by: David S. Miller -- Dave Täht --------------030904090008040807030509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 
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.
This was a typo on my part - 2.6.24-3.1, not 2.4


The specific commit that concerned me was this one. I had seen multiple cases of odd behavior (basically tcp sacking like crazy until the cwr collapses or a tcp reset) that I *think* this fix explains.



commit f779b2d60ab95c17f1e025778ed0df3ec2f05d75
Author: Zheng Yan <zheng.z.yan@intel.com>
Date:   Sun Sep 18 22:37:34 2011 -0400

    tcp: fix validation of D-SACK
   
    D-SACK is allowed to reside below snd_una. But the corresponding check
    in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo.
   
    Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
    Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>



-- 
Dave Täht
--------------030904090008040807030509-- --------------030407020708020401080001 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== --------------030407020708020401080001--