From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id ECEDC3BA8E for ; Mon, 11 Jun 2018 15:44:29 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1528746268; bh=zeNZHUtC0t0VUIOlZK0I9yL9PfHgWyyWevM5d4qD+k0=; h=From:To:Subject:In-Reply-To:References:Date:From; b=mikvLjK40IXkVZ0m2PAAJZz1m5olW8PyoHN0bMfkiMccHTMu0Q0L/yEa458t0weXU yFZidKlh2BI1j2zXXXB90P8YtiiDVEbP5izXhnRIxfKdP6alMY6D10NGm26rJ+w/kM LbcIgtQXSP2RmDhqQFcGAbAOTLYWk6bI1PLx+crRYUMImYiUZwDQcoLe+ABn99IxjI j5LbWTgE0adwcDuhOhBJueqGTp2A7dHeUxvD8buNWO/b4D0NYRDVEx3VLKgOkxErjR NW/ojMOq9/6jNAC9d1avAgjjtgLI6MGdeGkvc9pi+3XUbbTJeA3szVbQdO15remfXC QvhLpDYR78L9A== To: Michel Blais , cake@lists.bufferbloat.net In-Reply-To: References: Date: Mon, 11 Jun 2018 21:44:25 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wov5hzvq.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain 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 19:44:30 -0000 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