From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A85FE3B2A4 for ; Tue, 24 Apr 2018 05:30:58 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1524562257; bh=NLcHL3BS4qr7YiwiDTIVRFXxj0Sx493MLmRMDN/XdYw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CXkah4IzDXcAOrxo5dSDYLOjyQZZFujVAWpc9QNEkAA/Rsex8jSj3jM6I+Go/TIlb JFDsOnxA+Uruy01eO4r0wyNjNfQaYSMNCSeojH1FC+MuPvQ5U3DhFbTbI2nxjgw9I/ z+J785XwclYoCZRcoIuuZJwBA5tUpmq1wcqWAegR6gXebeWgE6ybL2EAGutrYXarhl iTQTpdML5rLOgoW16u9dWAg7iEb9ORCp0ZYwDUJGg+bZr0dYdPITBGTO+Q0HECqGQU Ia7F/o6RdJ1WLdtslIl0LzZqBi+vMEvq7QWRdSU+3mNxSZJf77c5NdjbAg/EPLMEXM 0M/HFt8XhQYTA== To: Sebastian Moeller Cc: Pete Heist , cake@lists.bufferbloat.net In-Reply-To: <2924DAE1-7967-4D57-A4C9-67FA0ABA33E2@gmx.de> References: <871sf6xqne.fsf@toke.dk> <0E96CBE1-B3B8-4E2A-BB09-1EEDD4E390BF@gmx.de> <87o9i97zyh.fsf@toke.dk> <2924DAE1-7967-4D57-A4C9-67FA0ABA33E2@gmx.de> Date: Tue, 24 Apr 2018 11:30:56 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d0yp7xyn.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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:30:59 -0000 Sebastian Moeller writes: > 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 a= ttached 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 buff= erbloat 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-appl= iance/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... Well I just meant that there are many ways to deploy a shaper in an ISP context (centrally in the network, at the next hop from the customer, etc). Looking at those threads, they seem to be increasing the number of queues. Not sure they need to, but, well, there's nothing in principle that says this couldn't be configurable (it is in FQ-CoDel). It would need a bit of a reorg of the current code, though, so that would be a thing for later I guess... -Toke