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 E4DCB3BA8E for ; Wed, 29 Nov 2017 13:28:18 -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 vATISHp7023889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Nov 2017 19:28:17 +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 vATISICM026836; Wed, 29 Nov 2017 19:28:18 +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 BC4F8EC873; Wed, 29 Nov 2017 19:28:17 +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 4rhAXGEoWVBW; Wed, 29 Nov 2017 19:28:16 +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 E144BEB215; Wed, 29 Nov 2017 19:28:16 +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 1eK75k-0005Bm-Kq; Wed, 29 Nov 2017 19:28:16 +0100 Date: Wed, 29 Nov 2017 19:28:16 +0100 Message-ID: <7izi75q6rj.wl-jch@irif.fr> From: Juliusz Chroboczek To: Dave Taht Cc: 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:28:17 +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:28:18 +0100 (CET) X-Miltered: at korolev with ID 5A1EFC41.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5A1EFC42.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5A1EFC41.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5A1EFC42.000 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 : 5A1EFC41.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5A1EFC42.000 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:40 -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:28:19 -0000 > Recently Ryan Mounce added ack filtering cabilities to the cake qdisc. > The benefits were pretty impressive at a 50x1 Down/Up ratio: If I read this posting right, you're only measuring bulk performance. What about interactive traffic, when there's only one or two data segments in flight at a given time > I'd rather like to have a compelling list of reasons why not to do > this! I haven't looked at Cake in detail, and I haven't put much thought into ACK filtering, but off the top of my head: - not risking breaking any of the TCP-related algorithms that depend on ACKs arriving in a timely manner (AIMD, Nagle, Eifel, etc.), especially in the case of just one segment in flight; - not contributing to the ossification of the Internet by giving an unfair advantage to TCP over other protocols; - limiting the amount of knowledge that middleboxes have of the transport-layer protocols, which leads to further ossification; - avoiding complexity in middleboxes, which leads to a more brittle Internet; - not encouraging ISPs to deploy highly asymmetric links. This is not my area of expertise, and therefore I don't feel competent to have an opinion, but I think that before you deploy ACK filtering, you really should consider the worries expressed above and whatever other worries more competent people might have. -- Juliusz