From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id DC6D33B29D for ; Fri, 22 Nov 2019 07:59:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574427574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XC0beJ814laU1MCAIT4dtHcaLap8hTfZ8MMjhFtrOZw=; b=h9sIupCA4rSz0MfkKYgo7uIP0DF6RPGVUG/x6L27UPzQZDlX3oLuIOSQhcF3YoWO0mAooC 9hiR3LTnn2KS05hvhadrHKsYz2zqZyyqQgRBkWKil54AgKNp1VMJ/5hNby5gaTY58mYoaz 1Xxn4xgTmcZI1Dn+dghJEfBw2yQeyG4= Received: from mail-lf1-f71.google.com (mail-lf1-f71.google.com [209.85.167.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-409-5j942JSVOPqdj8x5DiFgpg-1; Fri, 22 Nov 2019 07:59:32 -0500 Received: by mail-lf1-f71.google.com with SMTP id x16so1757339lfe.19 for ; Fri, 22 Nov 2019 04:59:32 -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:subject:in-reply-to:references:date :message-id:mime-version; bh=5Oz6O+Gl/LEmSPJQMQwaJzh1bmRAWUQt0SVKezSuR9Y=; b=uA4P3TZ6vE844uT47M9pp8dtXI6jdb9b5+1mFHds1njaqNk9W9LN2M+52+/71aWePp JC7nZSKZiQr8DcOQ+26DKTiPucsaax1YJn6Tz4P+0YarPt+GaFk1VmvycgkDqwzppHqE 5AjuWGyBK58WWxtAOtCDxDWlGARBDLhpQD9BbYPav9DnqSDkKNlx19wBEoUHxDfAazTa kGLnJCA5b6NGp+8NP6fvbQDGea0L0h0J5yke+bidTc5INZK/1AVSE6qUmn+BC4Bsw6TF wF0YZIfVYB147Z2ChjMhnY/Mzmo8A1DZ9KS16zgg5xrrhvTIkYqXaMdWdX9TkLXfzYnL gTtA== X-Gm-Message-State: APjAAAX7YqfD2Q14lkWQVy1+hC/+UCNu0+Qyho7q2pwpsJxf9NPREe29 NKirxDHnxF0/KoRcGPdW+K5XkCDoCiRVIuE3pA3WXDbilN1tC+GbvDIx30nMIPHhRpWpTptcOz+ c8njUDhVJ17NciQqzVCvElw== X-Received: by 2002:a2e:760d:: with SMTP id r13mr11868416ljc.15.1574427570882; Fri, 22 Nov 2019 04:59:30 -0800 (PST) X-Google-Smtp-Source: APXvYqxbxhzIpJEEhRACMCImLJEX8eHsYv/w+MVw1e5xlKmewKr91fPUeWKeIAt5MFXW+rcQu6b3lQ== X-Received: by 2002:a2e:760d:: with SMTP id r13mr11868402ljc.15.1574427570658; Fri, 22 Nov 2019 04:59:30 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id g23sm3143593ljn.63.2019.11.22.04.59.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Nov 2019 04:59:29 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 1F0B51800B9; Fri, 22 Nov 2019 13:59:29 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Justin Kilpatrick , cake@lists.bufferbloat.net In-Reply-To: References: <878so85e2d.fsf@toke.dk> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 22 Nov 2019 13:59:29 +0100 Message-ID: <87o8x43w3y.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: 5j942JSVOPqdj8x5DiFgpg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 22 Nov 2019 08:03:49 -0500 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 12:59:34 -0000 "Justin Kilpatrick" writes: >> 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. > > Althea.net runs Cake at every hop. Since we use Babel to dynamically > generate the network topology we rely on it's neighbor RTT extension > and bandwidth counters to reduce the bandwidth over a link when an > intermediate device has decided to become bloaty. > > It's been a very effective system that results in happier customers > even when we have weak leaks or crazy failover situations. Usually > wireless links have to be over provisioned by a factor of 2ish to keep > latency under control in the face of dynamic interference and other > external factors. Instead Althea networks have more smaller links then > back links between each pop. That's interesting. So you're running CAKE as a (dynamically configured?) shaper on top of the wireless link? What radio chipsets are you using and have you benchmarked this against just relying on the mac80211 FQ implementation (if that is available with your chipset)? -Toke