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 E2A513B2A4 for ; Tue, 24 Apr 2018 04:47:51 -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=1524559670; bh=Ld8589Vd1QP4VCgqCNRii//WaD2wMLeH2X7U8q2f1Nc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=rxAlbi9Jdd89NA5+mWna66HWe2VSDU8+Wx3fStwD2Iq4RZdJ9SY40sidcVKTMEF4M RxNpJzT8CcW/bCAL68FEXfmKCOaeULGfg8DlFBony1080xjjiGAT5Cs/pJNcqkKuI2 HY9MXOsjirgBjqeChTjTKQFrOHU0U6zl2E2XZL1xpInnHoVyCxfMQ16ytuW3OVnx9O iSAv23hAy4WPfUgF77BK+1jVfd9vqAGFurtBL/BioUOcYHt7TDqmroS+nBwQLZdGSR UJsB2hAvWL/KTbX0KbsCVeLVKJ1n59RUGsYWyNS27ka3Lnr0Vf12KEmEuwmja9oWnx CtYm57WMLTPRQ== To: Sebastian Moeller , Pete Heist Cc: cake@lists.bufferbloat.net In-Reply-To: <0E96CBE1-B3B8-4E2A-BB09-1EEDD4E390BF@gmx.de> References: <871sf6xqne.fsf@toke.dk> <0E96CBE1-B3B8-4E2A-BB09-1EEDD4E390BF@gmx.de> Date: Tue, 24 Apr 2018 10:47:50 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87o9i97zyh.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 08:47:52 -0000 Sebastian Moeller writes: >> 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 att= ached is a marked up PDF with some feedback on grammar and wording. Click t= he vanilla squares to show the notes. >>=20 >> Content: >>=20 >> - I wish there were some reference on how widespread of a problem buffer= bloat actually is on the current Internet. That would bolster the initial a= ssertion in the introduction. >>=20 >> - Thank you, I finally =E2=80=9Cget" triple-isolate. :) But I find it ea= sier >> 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? > > 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)). I don't think we can make assumptions on ISP deployments. 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... -Toke