From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 202CD3B2A4 for ; Wed, 3 Mar 2021 20:54:44 -0500 (EST) Received: by mail-lf1-x12c.google.com with SMTP id k9so20560679lfo.12 for ; Wed, 03 Mar 2021 17:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lostcreek-tech.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=NpKyHVmBCX2IW/CHvvN81KYsgc1+PF4kqB51XFhMXys=; b=olZNqJce7VZUo09VRSXFKaUTyOnxDuUtTEUpzUoJdVKr8dlbqf2GFTfsn2sjpKkLZc 4BwzvxjEkUPqCAbLpS9tog8iKoJO5JT2LmXljrTreS1ny+ARVAvGr92J4Vql6KCUxVx/ 7lQ/j8Kq5IMPcStI01AVV1+SjP2yf63YA4vnZzZHOoSfxj+VbdsO2Lk5fFhL2Hg9Juu4 6C0xqNI1WyfKFWJM8QjJ8BJxjIm6HQRrxt61/VikNZ3mvgdIFB4KKPFUxmhvkIbkuKoZ IbSwMiPF3i+W/ABlxzMm460B6vjcpsEV9xJ9787wXbF+hMpYGCWmtqq4IWUWpRcisXen cM8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NpKyHVmBCX2IW/CHvvN81KYsgc1+PF4kqB51XFhMXys=; b=YpZjkmOD7NCGvx+MssT3rWcazqwhJPa+0b4gq1HhXh7cpgnl1GiYpiJoU+j9Mc1MmS k+sCBKvrVAFqSgBJXVhGe0+R1DeU80zkLSunFlACNNpVlD4P2FN/2mbp4i19UKk32WEk BrwJTbQaznKlhc7G03ai+3rq/FX05TEzhdHqz6mB7VwQR6msKR2cHuX8S9vVIf22L+UA +XNnFl8+Id4zhE9kFugQgkYW1ojbRquEnnhNBLftNPDo9JsZsx3G6oeG7RAxd1f7BQuz wUXTYOUnNZgU5Nx+iivWXxp45iG3pbEcw76yjj/frqHOOC8nY2JFcxYGMFGEHyMiLPoM y+xw== X-Gm-Message-State: AOAM532rv22ESpxZTpxFfhHGcY0zVnNyuTFH09oqoDHGvRlSWTR1YJMF NWZdHMywtNJPcGtt4Kzhu+82Iacs8DmYzcE6Fwu+bZalsss= X-Google-Smtp-Source: ABdhPJwPJ2gKqqmJUA1HQgTfPUYJDYHVM7qP3wL/LgKcV/nWica/b3E4bKKNBsOy5yvt8Ouxs292bimteu44YAX4wxQ= X-Received: by 2002:a05:6512:34c3:: with SMTP id w3mr802246lfr.437.1614822882560; Wed, 03 Mar 2021 17:54:42 -0800 (PST) MIME-Version: 1.0 From: Thomas Croghan Date: Wed, 3 Mar 2021 18:54:30 -0700 Message-ID: To: Cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000004a600f05bcac409a" Subject: [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 01:54:44 -0000 --0000000000004a600f05bcac409a Content-Type: text/plain; charset="UTF-8" So, a beta of Mikrotik's RouterOS was released some time ago which finally has Cake built into it. In testing everything seems to be working, I just am coming up with some questions that I haven't been able to answer. Should there be any special considerations when Cake is being used in a setting where it's by far the most significant limiting factor to a connection? For example: --10 Gbps Fiber -- --10 Gbps Fiber -- [ISP Switch] -- 1 Gbps Fiber -- <500 Mbps Customer> In this situation very frequently the "" could be running Cake and do the bandwidth limiting of the customer down to 1/2 (or even less) of the physical connectivity. A lot of the conversations here revolve around Cake being set up just below the Bandwidth limits of the ISP, but that's not really going to be the case in a lot of the ISP world. Another question would be based on the above: How well does Cake do with stacking instances? In some cases our above example could look more like this: -- [Some sort of limitation to 100 Mbps] -- -- 1 Gbps connection- <25 Mbps Customer X 10> In this situation, would it be helpful to Cake to have a "Parent Queue" that limits the total throughput of all customer traffic to 99-100 Mbps then "Child Queues" that respectively limit customers to their 25 Mbps? Or would it be better to just setup each customer Queue at their limit and let Cake handle the times when the oversubscription has reared it's ugly head? To be honest I have a few more questions, but I don't think many people want to read pages and pages of my ignorance. If my question isn't too stupid, I would love to ask a few others. --0000000000004a600f05bcac409a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, a beta of Mikrotik&= #39;s RouterOS was released some time ago which finally has Cake built into= it.=C2=A0

In testing ever= ything seems to be working, I just am coming up with some questions that I = haven't been able to answer.=C2=A0

Should there be any special considerations when Cake is being = used in a setting where it's by far the most significant limiting facto= r to a connection? For example: <internet> --10 Gbps Fiber -- <ISP= Router> --10 Gbps Fiber -- [ISP Switch] -- 1 Gbps Fiber -- <500 Mbps= Customer>
In this situation very frequently the &= quot;<ISP Router>" could be running Cake and do the bandwidth li= miting of the customer down to 1/2 (or even less) of the physical connectiv= ity. A lot of the conversations here revolve around Cake being set up just = below the Bandwidth limits of the ISP, but that's not really going to b= e the case in a lot of the ISP world.

Another question would be based on the above:

How well does Cake do with stacking instanc= es? In some cases our above example could look more like this: <Internet= > -- [Some sort of limitation to 100 Mbps] -- <ISP Router> -- 1 Gb= ps connection- <25 Mbps Customer X 10>=C2=A0
In this situation, would it be helpful to Cake to = have a "Parent Queue" that limits the total throughput of all cus= tomer traffic to 99-100 Mbps then "Child Queues" that respectivel= y limit customers to their 25 Mbps? Or would it be better to just setup eac= h customer Queue at their limit and let Cake handle the times when the over= subscription has reared it's ugly head?


To be honest I have a few more= questions, but I don't think many people want to read pages and pages = of my ignorance. If my question isn't too stupid, I would love to ask a= few others.=C2=A0
--0000000000004a600f05bcac409a--