From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 4E4393BA8E for ; Mon, 11 Jun 2018 16:17:20 -0400 (EDT) Received: by mail-qt0-x231.google.com with SMTP id h5-v6so21548758qtm.13 for ; Mon, 11 Jun 2018 13:17:20 -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=QISfAhABO2B3/W3o6qOJuYN6sbB2qJtbMYFrMxvDiR8=; b=b5p2FCVv7x9PbHUn3/SJt+sYWRl9eHpCOtQlNX624N2caCPE3S7YUs3VhTowpD7zI8 +Xj2T3Mlv+sCtLO+NeAZCFaUYjJJiOx6J5GiYAn1kMq/pQG/FMw50ZjXJYVzx1sXiwKl LbwlE8kQ6DfYZCS7QwfU6kWAAtZCGQHI1cvlJCr41X5gPxv0IYsH6a/D5N5KJpuHRk1h 3rkJ2gBMJbNm3Sj5WZxNPfBNo3xE1n9Wn9OaUw/xDmq2zdGeSXHIrPwCjEmU60doPCaG odxlJMERboaqxphSVsNl/b4MsL+7b7WTNSnwofjejJuzFsX3ohPiQB6TAvLIrC7RSBRk EKDw== 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=QISfAhABO2B3/W3o6qOJuYN6sbB2qJtbMYFrMxvDiR8=; b=tIEE8LFa0oQYDhNx7gWn5s12zVh4fOjvWuYWM5V0yA/CKUrOPNW0q1l95GTwTrFB3W 7XbMZ90Jr5A6aWxqgy3Lf/wffHPyQVgTTIhNJIm6n4nq2K7UdfcQBza1LhEo13Md25VS 7LrtAZjBrlV6FqFvFlxzVI7r6qjTh7t2YtYSOrsyDHepr9xeO/4137sjSq9+UKnVwXTN jGztljTH5yn4sMJffNLlxHaxzot4+bm/PvMnJfkfh3TzRT+zSLfBiRAlhMNHFa8Gcq+1 7M9/YhucEuVJmYnfnyGyCXe5JyVDjATeiFJ4b9BOTt9Wib0RbzjxOjt+zcQmG1AfxB2p 4XGA== X-Gm-Message-State: APt69E2GKfrPGoCVvT0gI2VbpShpLY/tw0IeWMMwXUafnemyNlcrBsmA +dht0Pb4xdXPTUKvCAeWRrT3duWN9uLBwgqjO+M= X-Google-Smtp-Source: ADUXVKJczsQj3RPQbQhn/bqDoHNnRkVP9ce7MgX29mouTe0mEbtVx/UGZ9eqW1qDz+wkwZ3DVXlym9kTLX9Nlsme1BQ= X-Received: by 2002:a0c:9e5d:: with SMTP id z29-v6mr664006qve.15.1528748239862; Mon, 11 Jun 2018 13:17:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 13:17:19 -0700 (PDT) In-Reply-To: <20180611125425.792d4dcc@xeon-e3> References: <87wov5hzvq.fsf@toke.dk> <20180611125425.792d4dcc@xeon-e3> From: Dave Taht Date: Mon, 11 Jun 2018 13:17:19 -0700 Message-ID: To: Stephen Hemminger Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , 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 20:17:20 -0000 On Mon, Jun 11, 2018 at 12:54 PM, Stephen Hemminger wrote: > On Mon, 11 Jun 2018 21:44:25 +0200 > Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> Michel Blais writes: >> >> > 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 ?= From >> > what I read, seem like not. >> >> No, not currently (as Dave said). I do believe it would be possible to >> extend the current architecture to support this, though. Basically, >> making the number of tins configurable to an arbitrary number and making >> it possible to set individual bandwidths on them should do the trick. A >> TC filter could then be used to assign traffic to the right tin based on >> whatever information is available. >> >> However, I don't think the current way of finding the next tin to >> service is going to scale to an arbitrary number of tins, so this >> probably needs to be changed before such a configuration is really >> feasible... >> >> -Toke > > Making cake into a version of HTB is not necessarily a good idea Not the plan. But arguably, we'd need a list of requirements from a major head-end vendor or DPI co (like sandvine) to even try to address the ISP side of the universe. I long ago ran out of motivation and money to continue working on bufferbloat. It's fixed enough, for those that care. It's on enough devices (more every day) now to give those that succeed some market advantage. Heaving cake over the transom is the "last" thing. And after 18 versions in the last round, toke's fried, I'm fried, everybody's fried. I'm very happy it started cracking 40gbits, stumped at the bug stopping us. I do long for the day where I could buy a cable modem, dsl device, can bus, ont, gpon, wireless router, enode-b, etc, etc off the shelf, clearly marketed with bufferbloat-related fixes - and ISPs will supply default gear that worked "right", etc, etc that all did the right thing... but I figure that's going to take explicit market demand, regulation, or a miracle - or all three. And a decade. Or more. I *am* going to washington DC week after next for the lanman2018 presentation of cake, and perhaps I'll find a way to raise some hell with the FCC, congress, or the FTC (suggestions wanted), but... --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619