From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 619C23CB35 for ; Tue, 23 Nov 2021 04:03:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1637658219; bh=es/6weU6XaQd/Ux+osF/e+RPm692e7lGrrpIroTz+Jo=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=C3b1vlVFBsvW6Qvo0+sjQaGEysT4QkldkiQ1YZOONVPPdIdc1iTWMnK3fE7YbJ5nU jfw5zH/YSSfaCnxq6D30TFpbgpscnCsOM4pvdkFWpvXh6GK3qlKyc00Ite7hfjXAGV bZ/bsUIZTCcsrE4XZmkGj/AwT6w5GSbLJX2z4yxg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([80.187.108.241]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M1ps8-1mnEmp16jI-002Hfk; Tue, 23 Nov 2021 10:03:39 +0100 Date: Tue, 23 Nov 2021 10:03:40 +0100 From: Sebastian Moeller To: Dave Taht CC: Cake List User-Agent: K-9 Mail for Android In-Reply-To: References: <67BC6CC2-F088-4C0D-8433-A09F4AC452FE@gmx.de> Message-ID: <39F77F2A-3D91-4D3D-9D6B-F9F31FB24F4A@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:NBSWNOo0XS44lf9bb4sKYQUtPsDBK/bgiekk+9w2qF0I3Hfx6re tNwviBcGi8ZeD8+j+7ER5SmK4eGd78lnRH7QlVci/5slywiot9oKHXvyDQjfGdVpBkYbdAd r7Nn1LNfnxZOEbelNQjgVclhmguM7LVjvqvhO+qSiTCrrkqGQKlDfFEqiwRg1I5SMpG+dCw YYEy99I2J7H1xZOIAshxQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:PCUksdqL2rE=:tRc0AWUUVIDAeb582qA7gC yXIHLYaG9XfU6NDPp3Gly5Jr4JaBzVVmjBHQyjVnNzR03wOW4+DEZXHBzIdw9QzddqmF3+MZL Mc2/s+RyUX8fA5W3lUIeKmKAr3pO/Y8lwqWcYKFM1LYxwZ5p2RyI46bs0iTRQvSbreGxBfyqs cPA+q7cPe5bS/1Ugq10oqqoHymYB9Ll2bEZfwMx9/pcrdni/8lGtnw0wI/OWSnrNu+NUTt5oy aukYVpcZO3hARwEp3D3i6tW2y5TJOgY2yps3X44N/2SNFycnEx5eDc9l3OwZ8gJKvTGvbFs6a 02JVA34iiDijOB7TTuUdKQOrnncgR83dgU+4HzbtF/4o/0ouLWoyYLAwjv9610Q8SkpRB6B6S Fml++SNtvZ9Q8Zl7ygTKi06QIeE6fDEAh6SN3K5KZ5D/oPEEj5KozcECGUEfqxKdNqfaClEvv ZX6jdsM9glVV1Kb63MoGB/MRY7NKkfsTNxzICT4+cduUuEeqnfMLJ+G0dQ+vuh4WSO/lCHciq GOWUnvMgcWeCK2KThA5cvxRzlcREUOWkv8f5i6XVAkdaCU+2v4A8kHU28MFEt+TvMJJzgRFGD Rx1l1+lF4eG8GlMawKdSyeG5GYpC722y6NDd3iFFPAczoMtz6t3qvkaMzrb9stK8inLc3GnTh CkG2c4YEY70237tlA/GC6UtfS9ptLcU0KjUBtjHxd+2NkrsDWBrEfQ+6vSseRoU/p11Wro92X 4vOo+qslpV8G8QRp7KMfga+yPNedtTBjB+k0lcWK5k2W90Dmbb2cKRLX/q97PzLe6ONy1G4Hm TUqT5gtZJTx9YLjsr4PJzm6UMfB/c+XDIxGNbWcgH7PV4gf+nQMDF+sR7juBmsfAawxlyv0vI 0wrefIQaoxQJZN5pyz1qVyAGdLJXNDFhB+3mbQ1SjAXmVI2xXaXP1amlMZdxADXWcUEyFCv7Q KTmnwP9Fe8/byxi5Y1AGld8Muk05RdzoXtWp32+kXyvb7/zlIV1E8ovLILe4g+QLqLLFwXgDk oRkC7oxHjoI4jE+gL46mE5hqZN4zQ5V30TNtdKEx+0hHbhj3iEEDEbV/AhOKmJtDwG4xBAMTP InfIOcyk6ebavQ= Subject: Re: [Cake] tossing acks into the background queue 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: Tue, 23 Nov 2021 09:03:41 -0000 Hi Dave, On 23 November 2021 09:27:42 CET, Dave Taht wrot= e: >On Tue, Nov 23, 2021 at 12:06 AM Sebastian Moeller wr= ote: >> >> Hi Dave, >> >> On 23 November 2021 08:32:06 CET, Dave Taht w= rote: >> >The context of my question is basically this: >> > >> >Is cake baked? Is it done? >> >> How about per MAC address fairness (useful for ISPs and to treat IPv4/6= equally)? >> >> How about configurable number of queues (again helpful for ISPs)? > >How about MPLS? Not sure that cake will be relevant on MPLS links, but if it should be, I = guess peeking into the payload seems required (MPLS headers do not seem to = represent flow id), other than that I hear the latest is IPv6 segment routi= ng ;) Now as far as I can tell, both MPLS or SR will not live at those places wh= ere putting in competent AQM promises highest bang for the buck anyways=2E = IMHO as long as the backbone is overprovisioned putting AQM on the entry an= d exit routers seems the first logical step, so at access and peering links= =2E Sure upping the ante for backbone AQM seems also a good idea, but will = not help much if entry/exit are not yet AQMd, no? Regards Sebastian > >https://www=2Etechtarget=2Ecom/searchnetworking/definition/Multiprotocol-= Label-Switching-MPLS > >> >> IMHO cake works pretty well, with the biggest issue being its CPU deman= ds=2E As far as I understand however, that is caused by the shaper componen= t and there low latency and throughput are in direct competition, if we wan= t to lower the CPU latency demands we need to allow for bigger buffers that= keep the link busy even if cake itself is not scheduled as precisely as we= would desire or as e=2Eg=2E BQL requires=2E >> >> Regards >> Sebastian >> >> > >> >Is there anything from libreQos that would be better in C? >> > >> >On Mon, Nov 22, 2021 at 11:17 PM Dave Taht w= rote: >> >> >> >> On Mon, Nov 22, 2021 at 11:07 PM Sebastian Moeller wrote: >> >> > >> >> > Hi Dave, >> >> > >> >> > >> >> > On 23 November 2021 06:03:03 CET, Dave Taht wrote: >> >> > >ages ago I'd (we'd? I really don't remember - forgive me if I've >> >> > >forgotten who actually leaned in on it) written a basic ack-filte= r in >> >> > >ebpf=2E this was before cake gained tc actions and my primary use= for >> >> > >the tech was for asymmetric connections, and before the good >> >> > >ack-filter arrived, and I was (and remain) unfriendly to this lev= el of >> >> > >dpi=2E >> >> > > >> >> > >That said, on a symmetric connection, deprioritizing pure acks to= the >> >> > >5% background queue nd then turning the cake ack-filter loose on = it >> >> > >might actually work=2E >> >> > > >> >> > >Am I on drugs/is there any point? >> >> > >> >> > I think at leat when using multiple priority tins forward and reve= rse traffic should by default use the same tin (I can see non-standard situ= ations that want differential treatment)=2E The argument is that unlike ear= lier attempts at ingress shaping that tried to throttle reverse ACKs? cake/= codel do proper 'hit the brakes' signalling via marking/dropping and we wan= t that signal to reach the other end as quickly as possible, no? >> >> >> >> My thought was basically an optional filter that steered all pure ac= ks >> >> (no matter the classification) into the background queue=2E >> >> Non-pure-acks (sacks) essentially jump the background queue and sign= al >> >> that loss earlier=2E The backlog of other acks in background get >> >> delivered out of order, but purely out of order and discarded by the >> >> reciever=2E >> >> >> >> > Regards >> >> > Sebastian >> >> > >> >> > >> >> > > >> >> > > >> >> > > >> >> > >-- >> >> > >I tried to build a better future, a few times: >> >> > >https://wayforward=2Earchive=2Eorg/?site=3Dhttps%3A%2F%2Fwww=2Eic= ei=2Eorg >> >> > > >> >> > >Dave T=C3=A4ht CEO, TekLibre, LLC >> >> > >_______________________________________________ >> >> > >Cake mailing list >> >> > >Cake@lists=2Ebufferbloat=2Enet >> >> > >https://lists=2Ebufferbloat=2Enet/listinfo/cake >> >> > >> >> > -- >> >> > Sent from my Android device with K-9 Mail=2E Please excuse my brev= ity=2E >> >> >> >> >> >> >> >> -- >> >> I tried to build a better future, a few times: >> >> https://wayforward=2Earchive=2Eorg/?site=3Dhttps%3A%2F%2Fwww=2Eicei= =2Eorg >> >> >> >> Dave T=C3=A4ht CEO, TekLibre, LLC >> > >> > >> > >> >> -- >> Sent from my Android device with K-9 Mail=2E Please excuse my brevity= =2E > > > --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E