From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 406D73B2A4 for ; Thu, 4 Mar 2021 01:32:10 -0500 (EST) Received: by mail-lj1-x235.google.com with SMTP id r25so30931431ljk.11 for ; Wed, 03 Mar 2021 22:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lostcreek-tech.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AM9GugWg0mUxPcCYSBbvD44m4/+M0z0BpaogdWIKxEg=; b=uwmmwGyfCdxflTAzbO23AC5Mn9PcAa6cabKW3O2ErRDT5CZoD9efREoOJlGgIyLLG9 yjN6o96nhZqmJSdlyyPdDMoDNxOn2sYyxA6+EVcHkng01Rm7vJm6AElj178gpu4TMVQu ZWh+ICX2xpyiLvUVV81dW/RCu+f5yGuU0MVIOYtbFVAyQd7hz4jWtV67BJoy9GHd7Blp NbEng90pmvPrIH1CZfIr/y9xQMUoy1MLgjA5q5lc/wqR04rtvDKC8kIhN/K+Rhd8kJgK 0fNisw8aP4mleNMcuGhO12Ehcmodkv1h+6eTBskA1/D23B7R1EeRwzdId+L6IzhG2VGm zJBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AM9GugWg0mUxPcCYSBbvD44m4/+M0z0BpaogdWIKxEg=; b=gcMSewqofiymL7ZRtK0RtMZ4T0ysiVmAVLyIHHUfkGS91xIDNjIzYmjonfe/qXVfEj aex3xyg6EuoLWBukWbjWjm2O37eETRv/YIz4t+G0hBCp7CimcJNXQmXUQaiPNwd2vgnA 7bi11VTAFkWDiWxHHj475kO+VjIkazo9528lIadr389PbF8yBEJSy537mzW48k25wzDV jJ0YVUdyOX42Gmjef/ULQr4k9rQcVljD6dULRw79EMgLNhpfSvnh1yWr3voBs/5Z9s+3 TmCLEiHmvnIrimv+QEVfTbbKEtiGoMcTDUYzBSjTIkYO7yLXpj/NRJm5evIiVqTTHAkk lvtA== X-Gm-Message-State: AOAM53102eaJXP8j4JfvwKpTbykqtosn0HoyTxtqCBkqjgAvna0gLQTB +2EazKz3ud8TX06CRoC6ZQlPpspIiVKROZ/kUxeLBFmjq4pu3g== X-Google-Smtp-Source: ABdhPJyQHf08UkZmvOFeB/0sc6W4YBQemWCq2zBu967vNo11SfxxK60EjYdF0V03+XbDiuAg/E/Kf9D/A2sSEB2MO/Y= X-Received: by 2002:a2e:8e27:: with SMTP id r7mr1431638ljk.365.1614839528764; Wed, 03 Mar 2021 22:32:08 -0800 (PST) MIME-Version: 1.0 References: <9C791D21-7FC9-425E-9167-EC7660BF38F9@gmail.com> In-Reply-To: From: Thomas Croghan Date: Wed, 3 Mar 2021 23:31:59 -0700 Message-ID: To: Cake List Content-Type: multipart/alternative; boundary="0000000000007b4f4d05bcb0204f" Subject: Re: [Cake] ISP Implementation 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: Thu, 04 Mar 2021 06:32:10 -0000 --0000000000007b4f4d05bcb0204f Content-Type: text/plain; charset="UTF-8" >Cake is *best* used as the bottleneck inducer with effectively unlimited inbound bandwidth, I kind of figured that Cake was designed to be the bottleneck, but I don't want to be telling people the wrong things. I'll have to take another look LibreQoS, maybe there's a way to duplicate their work, though I like the processor efficiency I have seen on Cake. (It could be a Mikrotik implementation or my poor configuration of FQ_Codel though...) The issue I had with the LibreQoS model is that you are distancing yourself from the customer with the bandwidth limiter. In theory you want a bandwidth limiter limiting the upload traffic from your customer and a bandwidth limiter right at your upstream connection to limit each customer's download bandwidth so that your internal network infrastructure get's efficiently used and prevents your equipment from being the source of bufferbloat. At least that's the running theory with HTB Bandwidth limiters that most people are running right now. So in my second question it's probably going to be best to have a Cake instance on either side of the limitation. So this would be preferable right? -- -- -- -- <10 x 25 Mbps Customers> On Wed, Mar 3, 2021 at 8:18 PM Jonathan Morton wrote: > > On 4 Mar, 2021, at 5:14 am, Dave Taht wrote: > > > > yes, that. can it be made to work with cake? > > The README says there is experimental support. I haven't looked at it > closely. > > - Jonathan Morton -- Tommy Croghan Lost Creek Tech --0000000000007b4f4d05bcb0204f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>Cake is *best* used as the bottleneck inducer wit= h effectively unlimited inbound bandwidth,
I kind of figured that= Cake was designed to be the bottleneck, but I don't want to be telling= people the wrong things.=C2=A0

I'll have to t= ake another look LibreQoS, maybe there's a way to duplicate their work,= though I like the processor efficiency I have seen on Cake. (It could be a= Mikrotik implementation or my poor configuration of FQ_Codel though...)

The issue I had with the LibreQoS model is that you = are distancing yourself from the customer with the bandwidth=C2=A0limiter. = In theory you want a bandwidth limiter limiting the upload traffic from you= r customer and a bandwidth=C2=A0limiter right at your upstream connection t= o limit each customer's download bandwidth so that your internal networ= k infrastructure get's efficiently=C2=A0used and prevents your equipmen= t from being the source of bufferbloat. At least that's the running the= ory with HTB Bandwidth limiters that most people are running right now. So = in my second question it's probably going to be best to have a Cake ins= tance on either side of the limitation.

So this wo= uld be preferable right? <Theoretically unlimited bandwidth> -- <C= ake Instance Limiting bandwidth going left to right> -- <Some sort of= limit to 100 Mbps> -- <Cake Instance Limiting bandwidth going right = to left> -- <10 x 25 Mbps Customers>


On Wed, Mar 3, 2021 at 8:18 PM Jonathan Morton <chromatix99@gmail.com> wrote:
<= /div>
> On 4 Mar, 2021,= at 5:14 am, Dave Taht <dave.taht@gmail.com> wrote:
>
> yes, that. can it be made to work with cake?

The README says there is experimental support.=C2=A0 I haven't looked a= t it closely.

=C2=A0- Jonathan Morton


= --
Tom= my Croghan
Lost Creek Tech
--0000000000007b4f4d05bcb0204f--