From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9A02D3B29E; Fri, 1 Dec 2017 12:42:17 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 94F2B21367; Fri, 1 Dec 2017 17:42:15 +0000 (UTC) From: Dave Taht To: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= Cc: Luca Muscariello , make-wifi-fast@lists.bufferbloat.net, bloat References: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> <7B92DF4D-B6B5-4A64-9E10-119DCA2D4A6F@ifi.uio.no> <1512037480.19682.10.camel@gmail.com> <6b494910-1373-afb0-5b93-99b725391fb3@gmail.com> <87wp2638yo.fsf@toke.dk> <87tvxa36sn.fsf@toke.dk> Date: Fri, 01 Dec 2017 09:42:13 -0800 In-Reply-To: <87tvxa36sn.fsf@toke.dk> ("Toke \=\?utf-8\?Q\?H\=C3\=B8iland-J\?\= \=\?utf-8\?Q\?\=C3\=B8rgensen\=22's\?\= message of "Fri, 01 Dec 2017 14:40:40 +0100") Message-ID: <87po7ygxai.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Bloat] benefits of ack filtering X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 17:42:17 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > Luca Muscariello writes: > >> If I understand the text right, FastACK runs in the AP and generates an = ACK >> on behalf (or despite) of the TCP client end. >> Then, it decimates dupACKs. >> >> This means that there is a stateful connection tracker in the AP. Not so >> simple. >> It's almost, not entirely though, a TCP proxy doing Split TCP. > > Yeah, it's very much stateful, and tied closely to both TCP and the MAC > layer. So it has all the usual middlebox issues as far as that is > concerned... Also, APs need to transfer state between each other when > the client roams. > > It does increase single-flow TCP throughput by up to a factor of two, > though... Which everyone knows is the most important benchmark number ;) Were you always as cynical as I am? I'd like to compare (eventually) what we are trying with cake's new ack filter here, which at least doesn't lie to the endpoint. my guess, however, would be that the media access negotiation will dominate the cost, and savings from (say) reducing 10 acks to 1 would only be somewhere in the 5-20% range, for simple benchmarks. I think we might get a better rrul result, however, as we'd be able to pack more big flows into a given aggregate, with less acks there. > > -Toke > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat