From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alpha.coverfire.com (alpha.coverfire.com [69.41.199.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 083753B29E for ; Fri, 27 Jul 2018 10:04:50 -0400 (EDT) Received: from neptune.home (pkt.206.174.packetworks.net [206.174.180.53] (may be forged)) (authenticated bits=0) by alpha.coverfire.com (8.15.2/8.15.2) with ESMTPSA id w6RE4mJF031870 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Jul 2018 10:04:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coverfire.com; s=alpha2011102501; t=1532700288; bh=KIArTAqZhwqAIEc1CNiaYlV9FpRmM+CZ3oOFhx8t/bA=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=kUT5giHaO8WWs1kngBx43zllO9hVMloXWqg69/RFsq/NJo6I60elOTkPQuOxrOQWK btuOLjOVYYfXSh9iVqHg2pxDWxWl2hks7KXbt2THBgqrao8RlXr3odc9KJeNpevJwq x3Jq85T4GT51O0yvm5qD3lJUxuB06YSw4fQFkeb4= Message-ID: From: Dan Siemon To: Jonathan Morton , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Dave Taht , Cake List Date: Fri, 27 Jul 2018 10:04:47 -0400 In-Reply-To: References: <1357421162.31089.1531812291583@webmail.strato.de> <1c323544b3076c0ab31b887d6113f25f572e41ae.camel@coverfire.com> <87woth28rw.fsf@toke.dk> <87tvol1z6h.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.4 (3.28.4-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 69.41.199.58 X-Spam-Status: No, score=-1.1 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,T_DATE_IN_FUTURE_96_Q autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on alpha.coverfire.com Subject: Re: [Cake] =?utf-8?q?Using_cake_to_shape_1000=E2=80=99s_of_users=2E?= 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: Fri, 27 Jul 2018 14:04:51 -0000 On Fri, 2018-07-27 at 00:38 +0300, Jonathan Morton wrote: > It would also be valuable to have a firmer handle on the actual > requirements in the field. For example, if it is feasible to focus > only on current Linux kernels, then a lot of backwards compatibility > cruft can be excised when importing existing code from Cake. If all > users will have the same link-layer technology (with the same > overhead parameters), then these can be set globally - or if not, > they can be set per-tier. Is the Diffserv support from Cake likely > to be useful, and if so how flexible should the configuration > be? And are there only a few discrete settings for bandwidth per > user, or do we have to be more flexible to handle a BRAS > environment? Is it also necessary to account per-user traffic > accurately, or will an external tool be used for that? Obviously I can't speak for other potential users but we follow the upstream kernel very aggressively and have no interest in porting something like this to older kernels. We have some deployments with multiple access technologies (eg DOCSIS, DSL and wireless) behind the same box so per customer overhead would be useful. I am interested in the diffserv class ideas in Cake but need to do some experimentation to see if that helps in this environment. It would be interesting to be able to target sub-classes (not sure what the proper Cake terminology is) based on a eBPF classifier. Re accounting, we currently count per-IP via eBPF not via qdisc counts. Each subscriber can have several IPs in which case the traffic for those IPs needs to go to a single class so that their entire traffic envelope is shaped to the desired plan rate. At present we do this via eBPF since it is essentially a map lookup operation. A few of the above points touch on something that may be somewhat unique service provider deployments vs homes, there are many situations where the classification logic has to be a map lookup and cannot be done just by looking at a given packet. > Many other low-level considerations can be adjusted on the fly during > the conversion, so they are not in themselves a problem. In this > category are questions like "how many simultaneous users and flows > can be supported". There are ways to design the code so that it > scales up much more nicely in these dimensions than Cake does, at the > expense of a few extra CPU cycles per packet. > > - Jonathan Morton > >