From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 296FD3B2A4 for ; Tue, 24 Apr 2018 05:18:28 -0400 (EDT) Received: from [172.16.11.125] ([134.76.241.253]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M24ap-1eHQxW2fc3-00u19q; Tue, 24 Apr 2018 11:18:25 +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: <87o9i97zyh.fsf@toke.dk> Date: Tue, 24 Apr 2018 11:18:23 +0200 Cc: Pete Heist , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <2924DAE1-7967-4D57-A4C9-67FA0ABA33E2@gmx.de> References: <871sf6xqne.fsf@toke.dk> <0E96CBE1-B3B8-4E2A-BB09-1EEDD4E390BF@gmx.de> <87o9i97zyh.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.6.18) X-Provags-ID: V03:K1:s5ORl2ho4j025X91L7lXZzZVKTa/pCNp7BtvHY46Dj6yhPQzHVk JhT2vhKvFgFFcvkZ3VGC/2MzexvlCYw8NpeutUJFIAanYQaVSwClOq5JH5GTYMkQskL4Y9o 1QEw3EoCZjhg3sS3nnrHwxqJP9TDcHinysq7Zr9fehCCUtAL3baiVuW4gTmccnn9oGAsvMz avUNGmbCQTZDk11Wpnw3w== X-UI-Out-Filterresults: notjunk:1;V01:K0:1/tI0+oUOPY=:qKSYUFZYS8Fff4VZaI6XZv aWp5D7c3RFmh/qJbqZsyJrGLgmT9FRdK+LFAA7DuOIDUJu46aD9iYL5lN5HKgB3Jw+GETZwvp k0OSvZQl2COvbUQk/lhXuJK/nJL5TQmDChr3Zqr699y84XPKSy18qS/Cr6grbq3Hfxy8++3wl DU3iuGSQq7a23Gp7OfpQl/IwsJda6h994cPHQRNpZszDyMv6HdM/+EiCQRrK8U8n2DBizZP6V YJ2aMkFayUg66d6tDTskmDaGPYHZXQyLgGRBRjNg+jHtr20Wxcwwo1D8tGxUClLtlxHU8Ga44 ZtIa6VxzJNiY4PW3axdukUO15v15fDE9l0PxLtKEvOGpkb8wCkVHDh5CyanumF+ulgdTQQAQB dujt+gPE21HFo9wcC9RWaosTkUz3mRRQOz/YTcU16q00cQUX0pQAFHDR3uV7937O8Hp9xX49Y uNZFUMPh7a15v32QAQ5zyGw4IXao7wjtZYK7wplQ2MM8f+btirtlArefv1dDnQ8PJXOLj8Ku7 kpK4QYR4Q004ZX6RiJXf0qa1Ru4OpZP1aTSgm2XJ/k05b5xIwHQLGOKLIJ8dWJiimOuDDdNPd 9zQ8EcbsP1nUDY7R5S0R0fs1/v7jyEzVR3jpz2p2bJw95PUNcI5v9BG9SP3RcAIuzOTW1aXdA /4lv12tZjHa4iCLfSqO1hJ1Eb9x54xbv2UvzvUuuWe4yZySIV4lAbZmLxcWNeUFr+9YX9czfL WcK7CxUZ/GSSw1bmoUP3q9eP2tHvWT3VCvQhOOrT0+GFLxqTdeBr0GYftsOawwdwJYQD0XxkB 4/Pc/BuwCTbOHbMtYJQhDohKG0+TgXIddLWSTcmhNgBDGBtuBQ= Subject: Re: [Cake] Pre-print of Cake paper available 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: Tue, 24 Apr 2018 09:18:28 -0000 Hi Toke, > On Apr 24, 2018, at 10:47, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Sebastian Moeller writes: >=20 >>> On Apr 24, 2018, at 01:01, Pete Heist wrote: >>>=20 >>>=20 >>>> On Apr 23, 2018, at 10:39 AM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>>>=20 >>>> Last week we submitted an academic paper describing Cake. A = pre-print is >>>> now available on arXiv: https://arxiv.org/abs/1804.07617 >>>>=20 >>>> Comments welcome, of course :) >>>=20 >>>=20 >>> Nice work overall=E2=80=A6 :) Below is some feedback on content, and = attached is a marked up PDF with some feedback on grammar and wording. = Click the vanilla squares to show the notes. >>>=20 >>> Content: >>>=20 >>> - I wish there were some reference on how widespread of a problem = bufferbloat actually is on the current Internet. That would bolster the = initial assertion in the introduction. >>>=20 >>> - Thank you, I finally =E2=80=9Cget" triple-isolate. :) But I find = it easier >>> to understand the behavior of dual-srchost and dual-dsthost, and I >>> think most would prefer its behavior, despite the fact that it needs >>> to be configured manually. Just a thought, knowing that cake >>> currently targets home gateways, and that there are now the egress >>> and ingress keywords, could host isolation default to dual-srchost >>> for egress mode and dual-dsthost for ingress mode? Or since using = the >>> keywords would be fragile, is there a better way to know the proper >>> sense for dual-srchost and dual-dsthost? >>=20 >> The challenge is to find a heuristic that covers all reasonable >> use cases and does no harm in unexpected cases. I could envision >> setting up a cake instance on the upstream end of say a >> microwave link, there "ingress" seems like the appropriate >> keyword (as the goal would be to keep the link non-congested), >> but for customer fairness "dual-srchost" would be the >> appropriate keyword (or just srchost if all the ISP cares for is >> inter-customer fairness). Sure this will not work with IPv6 (for >> that we would either need to llok at the MACs or IMHO preferably >> the IPv6 prefix (or the partially masked IPv6 IP-address, I >> believe this to be better than MAC adresses as the ISP can >> easily control the prefix, but I digress)). >=20 > I don't think we can make assumptions on ISP deployments. Sure we do not really need to: = https://forum.lede-project.org/t/transparent-cake-box/2161/4?u=3Dmoeller0 = and = https://forum.lede-project.org/t/lede-as-a-dedicated-qos-bufferbloat-appli= ance/1861/14?u=3Dmoeller0 so it looks like one person already use cake in an small ISP context. = Now 1 is not a very convincing number, but certainly larger than zero...=20= > The shaper may > or may not be at the point of NAT, and per-customer prefix size can > vary. To properly support the ISP per-customer fairness use case, we'd > probably need to support arbitrary filtering (like what FQ-CoDel > supports with 'tc filter'). And I think, if we wanted to support the = ISP > case, that a per-customer *shaper* is more useful... Yes, I assume though that these would need to run on the boxes ISPs use = to terminate the customer lines; but cake might still make sense for = fair sharing of bottlenecks. Best Regards Sebastian >=20 > -Toke