From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8E91B3BA8E for ; Wed, 29 Nov 2017 13:21:42 -0500 (EST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vATILejs021560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Nov 2017 19:21:40 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vATILeLT024966; Wed, 29 Nov 2017 19:21:40 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 175C5EB217; Wed, 29 Nov 2017 19:21:40 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 4ApE4fg4-n2g; Wed, 29 Nov 2017 19:21:39 +0100 (CET) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 426B2EB215; Wed, 29 Nov 2017 19:21:38 +0100 (CET) Received: from localhost ([::1] helo=lanthane.irif.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.89) (envelope-from ) id 1eK6zK-000590-5W; Wed, 29 Nov 2017 19:21:38 +0100 Date: Wed, 29 Nov 2017 19:21:38 +0100 Message-ID: <7i1skhrln1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Mikael Abrahamsson Cc: Dave Taht , bloat In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 29 Nov 2017 19:21:40 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 29 Nov 2017 19:21:40 +0100 (CET) X-Miltered: at korolev with ID 5A1EFAB4.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5A1EFAB4.004 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5A1EFAB4.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5A1EFAB4.004 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5A1EFAB4.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5A1EFAB4.004 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham X-Mailman-Approved-At: Mon, 11 Dec 2017 11:17:03 -0500 Subject: Re: [Bloat] benefits of ack filtering X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 18:21:42 -0000 > The better solution would of course be to have the TCP peeps change the > way TCP works so that it sends fewer ACKs. Which tends to perturb the way the TCP self-clocking feedback loop works, and to break Nagle. > In the TCP implementations I tcpdump regularily, it seems they send one > ACK per 2 downstream packets. That's the delack algorithm. One of the stupidest algorithms I've had the displeasure of looking at (a fixed 500ms timeout, sheesh). And yes, it breaks Nagle. > I don't want middle boxes making "smart" decisions I agree, especially if they use transport-layer data to make their decisions. > Since this ACK reduction is done on probably hundreds of millions of > fixed-line subscriber lines today, what arguments do designers of TCP have > to keep sending one ACK per 2 received TCP packets? I think it's about growing the TCP congestion window fast enough. Recall that that AIMD counts received ACKs, not ACKed bytes. (And not breaking Nagle.) -- Juliusz