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 D716F3B2A4 for ; Tue, 24 Apr 2018 05:15:05 -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=1524561304; bh=T/4X19e/HJcUcwx2gpnyFn6/9gLNZUncHrfEaDj8f6A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=N4KRnWBDZQNEGdUS1XK+p7Q+yM8y9joPx5wDYbR85N2O9e7uCBBLXLiSZk0ibD/+m ZfIqjiDMiGMMbpGjv/AgyB6cviFRDGby+dpPBnScsymWuXM6leeVIKlwlyfSJRMFUc Nb4knRzFMe2qZBfXuc3duInnPXFR019WQp8coSmNrhUFtl09UWv2BDzrmddv303ly4 9N708gWkK3WK/s12NHgohlCBAlzydj/gFMNYP2anqKjJBBqQ3RX6ptZa6NSc4Fp9gN ALKyYTA7IhBoGxY5bZRMaEL6byov+SW6avMt5rndn6fyQAAoTbkIeBk9mWJmfIEoRa D1SgLMWMU9mlg== To: Pete Heist , Jonathan Morton Cc: Sebastian Moeller , cake@lists.bufferbloat.net In-Reply-To: References: <871sf6xqne.fsf@toke.dk> <0E96CBE1-B3B8-4E2A-BB09-1EEDD4E390BF@gmx.de> <87o9i97zyh.fsf@toke.dk> Date: Tue, 24 Apr 2018 11:15:03 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87fu3l7yp4.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:15:06 -0000 Pete Heist writes: >> On Apr 24, 2018, at 10:50 AM, Jonathan Morton wr= ote: >>=20 >>> I think, if we wanted to support the ISP case, that a per-customer *sha= per* is more useful. >>=20 >> Yes, I think the technology can be recoded to better suit a >> multi-subscriber environment; it would no longer be Cake, but would >> use some of the same key algorithms. > > Right, I was going to comment on the paper- where=E2=80=99s the ISP backh= aul > use case? (Because I might still try to use it that way.) But I was > sure that this was already considered, and am not surprised that it > might be a different but related project. Well, you could use it on an ISP backhaul by having a separate CAKE instance per customer, and having another mechanism to assign customer traffic to each. An HTB tree would be one way to do this; separate interfaces per customer would be another. The latter works well if customers are on separate VLANs, for instance... But yeah, having a single instance of CAKE solve all of your customer shaping problems is probably not in scope currently... ;) -Toke