From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail50c50.megamailservers.eu (mail152c50.megamailservers.eu [91.136.10.162]) (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 6DF133B2A4 for ; Fri, 19 Feb 2021 07:16:53 -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=1613737012; bh=kfvby+2Y+7cwOx9L4S+VAbYcVYmNekFeL8HwPSDFHcs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=iguITJ+k7iM/cy8XA9ttweAIvUH3Wkmx/vqbUWfxjk5wnIXr+hD+FHwndel7PjMts jLvK04EP+o5mOY6URd0CHScaEDFgCjUj/iqZtaEAKfQMzbC+MZ8gPMo/FBodie2drR UualKBr08M25KmgaxwxPOaWLP174c4S1ETxuN+GU= 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 mail50c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 11JCGoMl011469 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 19 Feb 2021 12:16:52 +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 1lD4iH-000fpV-QP for cake@lists.bufferbloat.net; Fri, 19 Feb 2021 12:16:49 +0000 To: cake@lists.bufferbloat.net References: <87mtw1kx9c.fsf@toke.dk> <87im6pkweq.fsf@toke.dk> From: John Sager Message-ID: <9a889d98-0fae-d1af-6dea-c534f0df854a@sager.me.uk> Date: Fri, 19 Feb 2021 12:16:48 +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: <87im6pkweq.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.0A742F21.602FAC34.000B: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=UMej4xXy 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=pGLkceISAAAA:8 a=kurRqvosAAAA:8 a=0Q0sQSjteLhxM33pYEsA:9 a=QEXdDO2ut3YA:10 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 12:16:53 -0000 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 >