From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 D878C3BA8E for ; Mon, 11 Jun 2018 13:44:38 -0400 (EDT) Received: by mail-qt0-x229.google.com with SMTP id a18-v6so3826371qtj.4 for ; Mon, 11 Jun 2018 10:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9lu4jL0RYZBYdIC3gCWXbLY4dhTPvzk4HE6ozAzbFDk=; b=AZSlan5naIEgfILBLbD6wVXarX0dNuiWCofmUc5/iDbeXajp8jDR+oAqYSD1fLBGx/ 6iAstwyL3qadh/KGlbNs287cbgd1PcqHsTBUEnixKEwXDTiz9GD2tsq+d3h0uUJU07MN wuJ7nr7rLjagSdUsAKixvToMgqHeWrkUYExHIdicnK8SOGtB9Q6PcuCXF1ak9mPEsM+9 JOyL0URHK4LN7U5/GECmkDd8yj/AjeW36F1rQwawBcw7JeC2tuMZ2LKojPoxdLp6eAhp kH1GKJpsmBLLC4RlRTXCH7JPLxI4yZTldG9jk0Tidtkr2EU0+1eYkvRaIZ9e/BGSPYO+ dxQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9lu4jL0RYZBYdIC3gCWXbLY4dhTPvzk4HE6ozAzbFDk=; b=O4vymkcD4APLfqvQVcjwZKLTy5gRp6m7YxG6fOL1C23jKqXaoNHAqKfoxuis0TOnYU FEGflnTD1OZ8YYnxhTc07t6MI18dDeMRjcibpBxaXDSmbPHCXjDP3c4iPsqNV610JK8Z hkNnnr/IVEfkBmiU8Hene+0no2I2dKPColZC2OOPV92pmFgoxMG84HOUa/GOzlGBtIL7 ebbcsbPMqzdFdvNEsqd1Bsss8yOnYErQfm0EYAr0U8Y1lFCfrvRsUAbrQhIPCpm9Oq0p txrEOqcHNa4F8MG2fe2h4h3u2UDYWBVjS9l1CtqnOQWbzECKyDFA9iqdbdDFPaVwrjaS qXpA== X-Gm-Message-State: APt69E1KH9otQShETaajrJvUTsOK0CGWv4/K28diyIM/ZXaJwcAPfrak KMGLh6nrAdGfTmdw80KzHhxLQep2au8TZkH/k5I= X-Google-Smtp-Source: ADUXVKL5LGbZrShuCQ8gaOZmDCpTdJETDkHtpek3JB24oggb82wIjJTaCj9yk74Jh//Eih5/cTo2dBExVLRGICeEXDA= X-Received: by 2002:ac8:683:: with SMTP id f3-v6mr188225qth.104.1528739078366; Mon, 11 Jun 2018 10:44:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 10:44:37 -0700 (PDT) In-Reply-To: References: From: Dave Taht Date: Mon, 11 Jun 2018 10:44:37 -0700 Message-ID: To: Michel Blais Cc: Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Bandwidith rate by host instead of global while using [dual-]srchost and [dual-]dsthost 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: Mon, 11 Jun 2018 17:44:39 -0000 On Mon, Jun 11, 2018 at 8:43 AM, Michel Blais wr= ote: > Hi all, > > Is it possible while using srchost, or dual-srchost, and dsthost, or > dual-dsthost, to do a bandwidth limitation by host instead of global ? Fr= om > what I read, seem like not. No. It's been one of those things where custom non-linux hardware is used on the head end (CMTSes, DSLAMs), where even trying seems futile. If there was a head-end maker that wanted to try (and sponsor the effort), that would be cool. One way to maybe get there without custom hw would be to insert a fat x86 or arm64 cake box in front of a CMTS or dslam as a transparent bridge (much like we see with certain dpi products) to do one veth per subscriber. We'd coalesce all the IPs a subscriber has into a cake instance # eth0 takes all traffic, eth1 outputs the reshaped traffic # bridge veth0,veth1 to eth1 # Route customer 1 ip route add 1.1.1.1 dev veth0 ip route add 2001::1:x:y:z/64 dev veth0 # Route customer 2 ip route add 1.1.1.2 dev veth1 ip route add 2001::2:x:y:z/64 dev veth1 tc qdisc add dev veth0 cake bandwidth 100mbit tc qdisc add dev veth1 cake bandwidth 20mbit Some comms from the head-end would be helpful to be monitoring the achieved rate (line noise issues) and global bandwidth available and tweaking each cake instance to suit every few seconds (tc qdisc change dev veth0 cake bandwidth 80mbit). Given that the latest cake is cracking 40gbit on a single interface, it might be interesting to see how hard we could push, say, 10,000 instances like the above through a big box to see what happens. But I tend to think the work should be layered onto a line card rather than a separate box. This is why we try so hard to make the code dual licensed and publish papers documenting the algoriths. 7 years after this effort started cable head-ends still use 2sec of FIFO buffering. I'd had high hopes we'd see *something* from arris by now that did more of the right thing. they tried sfq way back when https://pdfs.semanticscholar.org/c577/0612bfaa1dff4daf2b0cfe56b79627dddc9c.= pdf and sfq is in one of their fiber products. I keep hoping we'll make some onts and gpon hardware soon, with bql + fq_codel at least. > I saw several times on messages on mailling list that some option could b= e > usefull for ISP and dual-srchost and dual-dsthost would seem something > usefull for small ISP, an alternative to Mikrotik PCQ with all the advant= age > of cake like flow fairness and latency. Keep hoping that mikrotik will get on the ball. Many fq_codel requests on their forums. ubnt is all over this stuff. > Thanks > --- > Cordialement, / With regards, > > Michel Blais > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619