From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 79F913B29E for ; Fri, 22 Nov 2019 06:46:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574423183; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oXTceKtCmwgvLcwWCYl6ebtanY6Gv96Fkg2/4szCo10=; b=MNAZO4HdIq7jC7PnKtGvAQ9yfsGU6kxLpsT/NEBPuVA9szTNChimKYWh4LbfhHSqrkDDQb Crj8HMTOFeewk+AEBy3SjwM/wlTxiyd1iGc0n84zhd20XOT4zMg2u7o8oDtgKJiByAlSyF sajzKnuUY0+HqAf8f/6lj2LNJ/wWlvY= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-346-DSpWp7B5PkmyLh-dqerVqw-1; Fri, 22 Nov 2019 06:46:22 -0500 Received: by mail-lj1-f197.google.com with SMTP id 70so1267208ljf.13 for ; Fri, 22 Nov 2019 03:46:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=eKJd0BLhuiGSUyn/SWkDuLjYIjyrW6N6AD6B9E8zfl4=; b=CyXokzcQ1FmTVb7bznc32VqaRL5ELFJIA4fM5bUfpRK9hoNiRT1dqfiQXciizRTlLL aqtxLi7uAeOU0m1NM89zpqvB130Uu03zaF0xlAb5Nb3fVLWrwZwR1reA/i8iPzIoSJPc O38I9mNOFQwyk93IaKLYcHDpX84fJH3HdDvmtjLKqdwbuyGWcXBdX4yzYXzmIOB0SEBM 7+KoK7/c0XXSXx5kWrfC+nJuegBkVLXxvvZAAn+EgwABJIWB3ma2b32GsSaNfPV2+ZBX 9xAbBel/q2TXs7JDWV1tBzK7BaD3w8xeI0OyhtxYM+E10+UxAshvwkK5RJRAz6Gn/5OX d/dA== X-Gm-Message-State: APjAAAXOF0J6+ly0pagrqkfbY2A5kriNyOozB9V6HkxPSEznDW2wuo7h qBe9D9C4Cf6bwAcTXNLvzEowLr8/s6OFlmVhzVikxg0YPX49rXks48x4Y/hPK8jzeXxYLXR/vSV f6f9TkbuNCO72LKc7pU4rIg== X-Received: by 2002:a2e:7013:: with SMTP id l19mr11915638ljc.201.1574423180616; Fri, 22 Nov 2019 03:46:20 -0800 (PST) X-Google-Smtp-Source: APXvYqyHRvbSe9/m6emtw2aPwdaUoCNyTy5PgzWAhad6u+emh30vIiaAoUmE7t0w77qlwq7NqELoXA== X-Received: by 2002:a2e:7013:: with SMTP id l19mr11915613ljc.201.1574423180359; Fri, 22 Nov 2019 03:46:20 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id z17sm2759885ljm.16.2019.11.22.03.46.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Nov 2019 03:46:19 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 9F06C1800B9; Fri, 22 Nov 2019 12:46:18 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Adam Moffett , cake@lists.bufferbloat.net Cc: Jesper Dangaard Brouer In-Reply-To: References: X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 22 Nov 2019 12:46:18 +0100 Message-ID: <878so85e2d.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: DSpWp7B5PkmyLh-dqerVqw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Cake implementations 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, 22 Nov 2019 11:46:24 -0000 "Adam Moffett" writes: >>> >>> Are there any commercial products already using Cake? >> >>Evenroute, eero, ubnt top that list. Evenroute's implementation is >>superb, the first one that used active line measurements to handle >>"sag". Anything derived from openwrt (somewhere between 10-30% of the >>home router market). I'm not sure if preseem is using it or not. >>dd-wrt. Most other things doing "SQM" are doing it via htb + fq_codel. >> >> > An idea which was floated was to experiment with routing ISP customer=20 > traffic through a Linux server using cake to improve customer=20 > experience. Basically like Preseem. My colleague has toyed with it a=20 > bit in small test cases and was impressed with the outcomes. > > He's looked closer than I have, but I'm trying to picture how his idea=20 > would scale. I believe I'm seeing a CLI tool for configuring policies. = =20 > It seems like we'd have to create a middle layer to create/update=20 > policies for customer's IP address based on information obtained from=20 > our AAA and CRM systems. I can picture some shapes that might take, but= =20 > I think it would ultimately have to revolve around scripting the tc=20 > command. There would be thousands of policies and a policy would be=20 > created/updated whenever a subscriber reconnects (e.g. when a DHCP lease= =20 > renews or a RADIUS auth event happens or similar). I know several ISPs that do this (route traffic through a Linux box and shape there). This deployment mode has not been the primary focus of CAKE, though; the "standard" way to do it is with HTB+FQ-CoDel, which allows you to set up arbitrarily complex configurations on a single interface. This can also be made to scale, but there's a central qdisc lock in Linux that you have to get around to scale to multiple cores. Fortunately, Jesper has already solved this particular issue: https://github.com/netoptimizer/xdp-cpumap-tc > Should we even pursue this idea? In my own totally non-biased opinion: Yes! :) > Although most staff who would touch this will have studied programming=20 > in college, I would not qualify any of us as "programmers" per se. My=20 > biggest concern would be hitting a service affecting problem that we=20 > can't solve. One way to go about this would be to open source the entire solution. There are already bits and pieces available as open source (such as Jesper's repository above, and sqm-scripts[0]) that you can build on, and this way you could enlist community help to solve any issues with the Linux side. You'd still need to get the data from your internal systems, of course, but you could define a simple configuration format that was part of the open source code; then you'll just need to write a script that grabs customer info from your CRM and outputs the config format... > Second concern is that many of our equipment vendors already use > Linux. Even Cisco now in some products. Maybe we'll waste our time > trying to roll our own solution and then find that a software update > from a vendor next year gives us everything we needed anyway. This would be great, of course, and do go and bug your vendors to solve this problem! Note, however, that just because a system is running Linux on the control plane, it may be using a hardware-offloaded data plane that does not have any of the bufferbloat mitigation features (unless the vendor specifically implemented them). I'm hoping that *eventually* these things will be ubiquitous across the industry, but thus far this has seemed to be an "any decade now" kind of proposition :/ -Toke