From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5DC923B29E for ; Wed, 29 Nov 2017 04:34:27 -0500 (EST) Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MQ2zr-1eFHfO0XEh-005IAA; Wed, 29 Nov 2017 10:34:25 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 29 Nov 2017 10:34:08 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <4D0E907C-E15D-437C-B6F7-FF348346D615@gmx.de> References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:PFbzxp1GSnlU1Fc4Wqs8rzNx7X6D5c3vpQhdR7CAN2rhdtuOrGa yqMM/xxxFBJmJzfImjSkGLg0vy0M+rhKezASbVaBSMmY7nd8dmgAPzGcNraAob66dOAlhDE ZsRKQYaGgQj85x8du5XnIshDWPNCXBC4W0Ij1arO1fBLVt/RyhQA8MTHFxtXDeC6qIowrEQ mRPUPbgyOtyzMONtLrxhw== X-UI-Out-Filterresults: notjunk:1;V01:K0:JQdDH6rkIYA=:suPturJe25FY8OMtOoSeQA n7Fvw5yWw9bcV3ioFYOL5TUj7Chv/H+K9d1JnCE20FBR77Ek3Xx6d6GV8hMor10wtBDHsn3pg 8yjDSvXsu429oaPM7MzDSTaV6rrvsbz2PBu56hu9RPAJ7hVWqwUUFL/t/A8dz9oRe5XbRAv27 Ao+yzlaUYRGjbE8gFu4Reqj0DvgqFq2WWJ9DPit4Ysy71dwTH0eP7qytZjhNxaA+yfae1kiq4 aF1vhptdEHO0c2VyWj/xt0VofJeW3wGr9cVIPy9/CqidIayOMj7Z8bMzJFZsfoeuwIB8w/uXR g/YVQac7MNpbY4lDp+3MllmBjjUnsY+YXocsDykIls0JzEqpRr0kZ1I5Yc+r3SdnSeig507ym 2AlI6RhLv6tMpmYFv8/YPESD9Ku2lu+PqKOcXD5V+lYYSWcJPSCg4b1Wfv/VN6f27aLI4RzMB A/+OHejyTjUjTUfuFz6Ps0fJMTFWl2fYxidZUjO0KVLkiQy0sV1CdcrEZ74utmaGCnOEj7I7E VYpvAE0e6jai+SNbSe2TtlkF76ezcRsXZvDv4rHU1ui2Q4GEOsSj8bGNrFC7RSRvQiE6y3NVC NnaQ3AGWCXzBTcG8MMKe6tG/p6KPdGy/eviQ9eJFQdfYIxptKO6Cjh3wg9aw7KUM6U6YtF3z0 rT5fVRYIxUcUjmoTCgX8yOBT5Nu7f35LlIcmoEjr4A9Vp4JZnrzvSw3R+vtz4ccpOfvxF368V 2k9UiifKY4VZG8rvtnQd7No/46BZZq7iu2gpJR7gmB9fJ+1y9oNrVQBE1hLLNVML4UD2QS1Xy fPpLI7P+AGjhqZX4HAuKoLf/25ijMobTvfvA4Kkjrc+2MyMlpDr9+LlUgNUQmU+4kriwauu 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 09:34:27 -0000 Well, ACK filtering/thinning is a simple trade-off: redundancy versus = bandwidth. Since the RFCs say a receiver should acknoledge every second = full MSS I think the decision whether to filter or not should be kept to = the enduser and not some misguided middle boxes; if a DOCSIS ISP wants = to secure precious upstream bandwidth they should at least re-synthesize = the filtered ACKs after passing their upstream bottleneck IMHO. This is = not reasonable network management in my irrelevant opinion unless = actively opted-in by the user. Or put differently the real fix for = DOCSIS ISPs is to simply not sell internet connections with asymmetries = that make it impossible to saturate the link with TCP traffic without = heroic measures like ack filtering.=20 So I am all for cake learning to do that, but I am 100% against = recommending using it unless one is "blessed" with a clue-less ISP that = has problems calculating the maximal permissible Up/Down asymmetry for = TCP... BTW, I believe older TCPs used the reception of an ACK and not the = acknowledged byte increment for widening their send/congestion windows, = ack filtering should make slow start behave more sluggish for such = hosts. As far as I can tell linux recently learned to deal with this = fact as GRO in essence will also make the receiver ACK more rarely (once = every 2 super-packets), so linux I think now evaluates the number of = acknoledged bytes. But I have no idea about windows or BSD tcp = implementations. Best Regards > On Nov 29, 2017, at 07:09, Mikael Abrahamsson = wrote: >=20 > On Tue, 28 Nov 2017, Dave Taht wrote: >=20 >> Recently Ryan Mounce added ack filtering cabilities to the cake = qdisc. >>=20 >> The benefits were pretty impressive at a 50x1 Down/Up ratio: >>=20 >> http://blog.cerowrt.org/post/ack_filtering/ >>=20 >> And quite noticeable at 16x1 ratios as well. >>=20 >> I'd rather like to have a compelling list of reasons why not to do >> this! And ways to do it better, if not. The relevant code is hovering >> at: >>=20 >> https://github.com/dtaht/sch_cake/blob/cobalt/sch_cake.c#L902 >=20 > Your post is already quite comprehensive when it comes to downsides. >=20 > The better solution would of course be to have the TCP peeps change = the way TCP works so that it sends fewer ACKs. I don't want middle boxes = making "smart" decisions when the proper solution is for both end TCP = speakers to do less work by sending fewer ACKs. In the TCP = implementations I tcpdump regularily, it seems they send one ACK per 2 = downstream packets. >=20 > At 1 gigabit/s that's in the order of 35k pps of ACKs (100 megabyte/s = divided by 1440 divided by 2). That's in my opinion completely ludicrous = rate of ACKs for no good reason. >=20 > I don't know what the formula should be, but it sounds like the ACK = sending ratio should be influenced by how many in-flight ACKs there = might be. Is there any reason to have more than 100 ACKs in flight at = any given time? 500? 1000? >=20 > My DOCSIS connection (inferred through observation) seems to run on = 1ms upstream time slots, and my modem will delete contigous ACKs at 16 = or 32 ACK intervals, ending up running at typically 1-2 ACKs per 1ms = time slot. This cuts down the ACK rate when I do 250 megabit/s downloads = from 5-8 megabit/s to 400 kilobit/s of used upstream bw. >=20 > 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? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat