From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail268c50.megamailservers.eu (mail1467c50.megamailservers.eu [91.136.14.67]) (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 1964D3B2A4 for ; Fri, 19 Feb 2021 14:04:52 -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=1613761487; bh=uZzM6FpjLNXpI8bP+c2ovYf826abkbaOBtKhhQ942Mc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=V45w1Eev+wCKzm+aH3siYdvUEKS3otvoXjITcIVlIwzTZSX9fyUtAAcuOz5bFv+ZA q+O9YehzvtDZDNwtCjkMsYI65KiFYq4zBK8U0YHCB7DZFROLh2pogt5FEPdtS5JO8m QKq8qWaaSQmOgmAhCZH6LfvnDf4//a7wUpCqepVg= 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 11JJ4iur025703 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Feb 2021 19:04:47 +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 1lDB51-000gwX-Pt; Fri, 19 Feb 2021 19:04:43 +0000 To: Peter Lepeska Cc: cake@lists.bufferbloat.net References: <87mtw1kx9c.fsf@toke.dk> <87im6pkweq.fsf@toke.dk> <9a889d98-0fae-d1af-6dea-c534f0df854a@sager.me.uk> From: John Sager Message-ID: Date: Fri, 19 Feb 2021 19:04:43 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-CTCH-RefID: str=0001.0A742F19.60300BCF.0041: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=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=qa6Q16uM49sA:10 a=GQ3UrkdYAAAA:8 a=pGLkceISAAAA:8 a=kurRqvosAAAA:8 a=V4N9VBXgGjcEZrKLXHEA:9 a=QEXdDO2ut3YA:10 a=UrkXBYOGhgNlFfmH13Sb:22 a=kbxRQ_lfPIoQnHsAj2-A: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: Fri, 19 Feb 2021 19:04:53 -0000 Yes. The marks are set on egress so you can select on inside IP address, port, protocol - in fact many characteristics that iptables rules can test for. I'll put together a toy iptables rules file and a toy script with the necessary tc commands. It'll take me a few days though as I'm busy with other stuff currently. PS does the cake list allow attachments? It will be a small zip file. John On 19/02/2021 15:02, Peter Lepeska wrote: > Hi John > > Does this result in the ability to set per internal host max ingress > bandwidth? If so, any chance you can share a snippet of a script? I will be > trying to reproduce your setup. > > Thank you! > > Peter > > On Fri, Feb 19, 2021 at 7:16 AM John Sager > wrote: > > That's basically what I do. I set marks on outgoing traffic in the mangle > table which are copied to connmark before egress. Then on ingress the > connmark is restored to the packet and punted to ifb0 using 'action > connmark > action mirred egress redirect dev $IFB' as an ingress filter on the > incoming > interface (ppp0 in my case). Then I have HTB classes on ifb0 which set rate > limits for different traffic classes indicated by the marks. I have only 6 > traffic classes (I bundle all video into one class), but as marks are 32 > bits wide there is lots of scope for classes for individual IP addresses. > > John > > On 18/02/2021 19:28, Toke Høiland-Jørgensen via Cake wrote: > > Peter Lepeska > > writes: > > > >> A user on the OpenWrt forum suggested hashlimit rules supported by > >> iptables. How does that idea sound to you? > > > > That will result in a cliff-edge policer (i.e., as soon as a device goes > > over its limits it will see every packet get dropped). This doesn't > > interact too well with the burstiness of TCP, so you'll likely get > > erratic behaviour of the traffic if you do that. Doing the same thing > > with HTB means the router will queue+shape each class (and with FQ-CoDel > > on the leaves, you'll get a nice AQM behaviour as well), so that will be > > smoother and less prone to bloat :) > > > > -Toke > > _______________________________________________ > > Cake mailing list > > Cake@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cake > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake >