From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 AD5933BA8E for ; Fri, 18 May 2018 07:23:12 -0400 (EDT) Received: from [172.16.11.169] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ldttv-1ebBio002d-00iyzS; Fri, 18 May 2018 13:23:09 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sebastian Moeller In-Reply-To: <05E1D675-B73B-4409-8991-EB89D5538EAB@darbyshire-bryant.me.uk> Date: Fri, 18 May 2018 13:23:07 +0200 Cc: Cong Wang , Cake List , Linux Kernel Network Developers , Eric Dumazet Content-Transfer-Encoding: quoted-printable Message-Id: References: <152650253056.25701.10138252969621361651.stgit@alrua-kau> <152650254614.25701.1377066681230937234.stgit@alrua-kau> <87in7my196.fsf@toke.dk> <05E1D675-B73B-4409-8991-EB89D5538EAB@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3445.6.18) X-Provags-ID: V03:K1:47M2nM10XAx6Sco8zRGtlRr4oY9bCSoVyoEhkXJQXeMuIkZz2m8 Ol3gFs3Dzlrk0JC/NyjOtGZbZy60dKlpqK+dJP0sHgBayVxw2XZjq8kdB4GCycse8qlNmCx POlWowBiE7PSefU09ZXTLRpjY+F4qmFHy2p5CISKix8RfSGB51mvOZ/WSNpUJnQNoi6E3cH zWb2094RfxZLcN6e9P0hg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3xLJj64JvcE=:bqVR0IzcgD3PqjKZtLDxnY XLmcsL+67lU2ouw57dUqZHcT/YBwkbPGmqgBjZo6A2FNsc4trEry4b5K709LZ7T0GxOOxLqw+ eVxJBEpdCu9EEn8ede1x8Zu8hYTbYix0xXqylyP+56LJPwKnBn5ivW4JHZe+MZ9dRFr1dArA/ C5odF1284FxCRg1Cz7o9OgDf60DtBHu+DQTDMpUdY4lrv0MJcbct0eANOgAxkr/CAJCwM6czJ uUGv0WA5YdqNIk655yF3LzjNMCJbcOyDlUp9RVVwTxJjE1Zn9ksXHlLnY2g49kTYNH1MjLCpu pL5BeNhyVxN4W4RCpSLWqY3YD08I4Ay8GQ/amNOMP2FyV8Jn/Aw/TRYsJBPhPtTJeIY+pQNvQ W5Y0KUURSwrZqYT0QJEgsyzupcmCnLDuu9Xe/GiCCga+jqM5n3qbAUxKbMVMabsuqAq2DdW5Y YFqmIyl6uxW0sa78DtYIIoDb+hl/vKXaPv/0A3Y+P68wqcU1WWybM88tbrBr8ofNsvl8utAJz JSdDbEId1HS9lvhyP0HKX6hDodZb29NvhWZbC7VdXgaC1b5tkHO/LFxByGOu4AIYCEHd1iRUm kJ41klZekeRvwXY3uXmFPpWsir+H4kpLuT7liwiQrC06NWX47AQ5F7tcz9XjMvdR0jQzU5CWI iuQL8I219OgmIfnCaze0wmlPxsg1wQDBL6JsOpeVEPSpcUSbB805BaWWEwH/C+9L9V1jyzqHh zOh/tdVA989ndb6iHPcBEC+XAyoXiAIJ2mD3P8FnDKE71V6rPhHd2O0+GyFz3zege9WQi/Fbx 4ZgZ5vO Subject: Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 11:23:13 -0000 Hi Kevin, > On May 18, 2018, at 13:18, Kevin Darbyshire-Bryant = wrote: >=20 >=20 >=20 >> On 18 May 2018, at 05:27, Cong Wang wrote: >>=20 >> On Thu, May 17, 2018 at 4:23 AM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>> Eric Dumazet writes: >>>=20 >>>> On 05/16/2018 01:29 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>>>> The ACK filter is an optional feature of CAKE which is designed to = improve >>>>> performance on links with very asymmetrical rate limits. On such = links >>>>> (which are unfortunately quite prevalent, especially for DSL and = cable >>>>> subscribers), the downstream throughput can be limited by the = number of >>>>> ACKs capable of being transmitted in the *upstream* direction. >>>>>=20 >>>>=20 >>>> ... >>>>=20 >>>>>=20 >>>>> Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen >>>>> --- >>>>> net/sched/sch_cake.c | 260 = ++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> 1 file changed, 258 insertions(+), 2 deletions(-) >>>>>=20 >>>>>=20 >>>>=20 >>>> I have decided to implement ACK compression in TCP stack itself. >>>=20 >>> Awesome! Will look forward to seeing that! >>=20 >> +1 >>=20 >> It is really odd to put into a TC qdisc, TCP stack is a much better >> place. >=20 > Speaking as a user of cake=E2=80=99s ack filtering, although it may be = an odd place, it is incredibly useful in my linux based home router = middle box that usefully extracts extra usable bandwidth from my = asymmetric link. And whilst ack compression/reduction/filtering call it = what you will, will come to the linux TCP stack, as yet other OS stacks = are less enlightened and benefit from the router=E2=80=99s = tweaking/meddling/interference. I believe this is a good point, it is really the asymmetry of = the link that makes ACK suppression more or less desirable, and it is = quite helpful if the adaptation to that link only needs to be configured = on one device. I think this is similar to applying MSS clamping on a = router to account for say PPPoE overhead as compared to relaying on path = MTU discovery or having to configure the MTU on all end-points. Best Regards >=20 >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake