From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail268c50.megamailservers.eu (mail1463c50.megamailservers.eu [91.136.14.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 191713B29E for ; Sat, 20 Feb 2021 10:09:54 -0500 (EST) X-Authenticated-User: sagermail@sager.me.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1613833793; bh=IQg49pgVttk0L0Vo5O5WUKDgaWak/HhrVdKwwgzB014=; h=Subject:Cc:References:From:Date:In-Reply-To:From; b=Vt8hjpZ4jwkghLoL6jnYjoiTwdwy5rF/AACtXfGgZfvRwF4JaCAr6NXeC7RXCtLUh oa78gInJ0AJbF50h4GFuQkr507PiLvG0LnqahBxP7+7DwBRBWm8wnig6t2g4YT/Aka W7wOvF2PMcOQNq0FTixK0t+AHKNkZUPYdRFdU7HA= Feedback-ID: john@sager.me.u Received: from mainserver.wc (97.83.2.81.in-addr.arpa [81.2.83.97]) (authenticated bits=0) by mail268c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 11KF9qmZ005017 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 20 Feb 2021 15:09:53 +0000 Received: from 1.4.7.2.4.7.8.0.a.e.2.c.c.0.5.d.0.0.0.0.3.e.b.c.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:cbe3:0:d50c:c2ea:874:2741]) by mainserver.wc with esmtp (Exim 4.93) (envelope-from ) id 1lDTtH-000kKJ-5b for cake@lists.bufferbloat.net; Sat, 20 Feb 2021 15:09:51 +0000 Cc: cake@lists.bufferbloat.net References: <87mtw1kx9c.fsf@toke.dk> <87im6pkweq.fsf@toke.dk> <9a889d98-0fae-d1af-6dea-c534f0df854a@sager.me.uk> <406344b9-49af-54f0-15fd-a17c5f3b604c@sager.me.uk> <87im6nhs52.fsf@toke.dk> From: John Sager Message-ID: <44401139-5a31-5129-f546-e598e202e6e3@sager.me.uk> Date: Sat, 20 Feb 2021 15:09:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <87im6nhs52.fsf@toke.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-CTCH-RefID: str=0001.0A742F19.60312641.001A:SCFSTAT79219218, ss=1, re=-4.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: -4.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=c//Vvi1l c=1 sm=1 tr=0 a=dws6IJh5fU+Ftmrx3Eq8JA==:117 a=dws6IJh5fU+Ftmrx3Eq8JA==:17 a=9cW_t1CCXrUA:10 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=qa6Q16uM49sA:10 a=GQ3UrkdYAAAA:8 a=4z6lSjSeexRwK0fjzOUA:9 a=QEXdDO2ut3YA:10 a=UrkXBYOGhgNlFfmH13Sb:22 X-Origin-Country: GB Subject: Re: [Cake] Enforcing video quality question 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: Sat, 20 Feb 2021 15:09:55 -0000 On 20/02/2021 11:53, Toke Høiland-Jørgensen wrote: > John Sager writes: > >> You will need to specify the hosts explicitly, unless you can live with them >> all sharing one bandwidth class. In that case if you have more than one >> using bandwidth they would share the bandwidth in that class equally. I >> assume from your original post that you want each host to be limited in >> bandwidth to a specific value, but to do that you need a class for each host >> in the ingress HTB. > > Just do enough classes that you can cover the whole IP space? At least > for IPv4 that's trivial; for IPv6 you'll probably need to hash and hope > that there are not too many collisions... Thinking about that, one could set up, say 16 classes for 16 marks and generate the marks using the HMARK target. That could hash on src,dst and include the ports if necessary. Then the connections would distribute across the HTB classes. However one video connection would generate multiple flows (DNS, metadata, etc before & perhaps during the video flow) so simultaneous video sessions from several users would likely interfere with each other. My current solution marks on source IP address or MAC address so all the traffic for one host goes into one class. John > >> What you probably need is a scheduler that has a limit per flow up to >> an overall ceiling beyond which it shares equally. I'm not aware that >> any of the schedulers do anything like that. > > If you use FQ-CoDel as the leaf qdisc in HTB you'll get flow scheduling > to each host. There won't be a per-flow *limit*, but you'll get nice > scheduling of all flows going towards each host. > > -Toke >