From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 EC2193B29D for ; Thu, 17 Nov 2022 09:42:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1668696130; bh=lfxexSkCeOWTLEhuNSEx4L/zWalJeRAMngnK5r7gI/c=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=sZ5Tm7Bfg9DD6tMkHD/UHY2eDL0AcapwKrWrgBsMCzgpHZj5CG53gw237h/B5N6fu x3/+biAk0fmUfi90Zn12yAFgedlxVxESC7TwOIqctI382ZO3jN+/R8cYc10+xspxkq fkxR8BSSTLwVl+Agf8KGpgXiLC5QZI6t9Aux5dQIixXgyByaCr1HQSj4El7TUFRy8z Gut6+yLFW/D3LxNre7E7yIdaKnWEdSMnvo5s+N9YUmdc2cIoKBIWt+WaBuYMz4A73e VGuGMFPQLBomnnpCj96TUqt8tzejusZMq4fe8mjekqgH5nl0mXUsP9yGYSwUQ1mrE5 c+3qFIZB/y/ug== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MTAFh-1oW4L71ypj-00UYW1; Thu, 17 Nov 2022 15:42:10 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: <4D5AA477-1547-441F-900C-6DC70C824960@slashdirt.org> Date: Thu, 17 Nov 2022 15:42:09 +0100 Cc: openwrt-devel , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: References: <386F2ED9-3D39-4A42-8982-742B5D4B417F@slashdirt.org> <4CF53FE3-D26A-4E32-8378-3B27BBB70AEF@slashdirt.org> <4D5AA477-1547-441F-900C-6DC70C824960@slashdirt.org> To: Thibaut X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:o2K0wYTMv10QkRHOCTrtXaoUVx7Z3w806Os0nBDrX0q+HYiogUi ZCVxgX08EBfY7MxlgzhJDGdFP0k7JSYvCi4MD6nRkZq1X7SDzX8tZxcmcGjiwEKBjgFl490 CUZDFPIyZW6yhxOkXN11c9zonOnsv4q18JfIoesOnuF5tWNXIHHTRx5jnbZbNU+qAO0AxdG fQ0YY2ckn4Y/1nEV68U/w== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:ZUIKB0qtZqI=;bstK+CKukSfh8Cx7sA9lPBk1lGH bYNwgzjDquhvTL7upBLOlRP72wLDbBum13M4QnG8GOFL9Sfsu85hWoMxvYaxrcUvKVNRDWS1X Vc++0R7Rqy7L+AjJdCzrV8h8YNsWrqyPMH47y8E0kTjvpk5LEhVWuiP5UrX+TBHzAAo9gj9xU irkcPUsrzllUknTP7jJFHQfrd8ggHVIK+9nhC+84u7osBy84QJHHIt+iGj7Mvb+uBMWqYHlMM m3MAoP0TuHJzM0DmeywB2PXh4d8kMJDpQHShoUTcAahFPtzlxCkdhfj2zW+VRWZKfCxMX/Zzr e8R+LuRWHi3JEwvOfkwaL1udYEyuPDT4A0pYCFQSu05YT3Lts/j2oULJXAGSh6Ui8xXPaf/FE /F+BJJ4wu80+CqreZLPda8tSmbA636hiS8NImgYFjRh+VzuPLJe+aBDSSMyQHWyGudm7uNhX/ 0Z+nEUh0VVSluNZZPaFf2PZTx3aKBIzYWemTuHUZKXB5rTj/AZiAHdBZPZH9ZlvH3ucOxgY1U vF5iwnR+sBKb3j9GaTtlVsCzSCkiyhcApgawJkYhy5YGpZJ3DnRHUVBrswTVa6JsSrcfAINwV GmcvqGALBSXT1YpsA5s+wbDprWMQHNsabiCFkE20+12FQOzzqRgV7U4k4JjHma+ISMRkWxLNl vVBtRZMU4zd7v9vuV0btseFhHx8Oy2K+7W0QRjwF5EkJTGPj0jAvhHXByeDEy40/s33QdxRYb nrHXPP9ObLlk4VrOB/5GRXli3m1ceptzp/NlVXyA6ehSCnmruejCPX7hSDcKtTB0pvAZN8LBh HRXthO9JwyoylZK97X5nGTYbfCM/b19kNo4rwPfUmXz78cHAjY00ROc6RwJ2runUf5M/7TqUy HFvYych2i0eq8LMsSjc9/IcMTMtzM1YMqBvWWhahwLd+Mn5Qk9CERPio/P1cObHVmvKh64h6O t+hILQyMfP4NnlBICxDXxe86q7M= Subject: Re: [Cake] Help untangling CAKE settings for FTTH 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: Thu, 17 Nov 2022 14:42:12 -0000 Hi Thibaut, > On Nov 17, 2022, at 15:22, Thibaut wrote: >=20 > Hi Sebastian, >=20 >> Le 17 nov. 2022 =C3=A0 10:50, Sebastian Moeller a = =C3=A9crit : >>=20 >> Hi T. >>=20 >>=20 >> so taking your proposa under consideration I canged the section that = threw you off course to read: >>=20 >>=20 >> =E2=80=A2 Ethernet with Overhead: SQM can also account for the = overhead imposed by VDSL2 links - add 22 bytes of overhead (mpu 68). = Cable Modems (DOCSIS) set both up- and downstream overhead to 18 bytes = (6 bytes source MAC, 6 bytes destination MAC, 2 bytes ether-type, 4 = bytes FCS), to allow for a possible 4 byte VLAN tag it is recommended to = set the overhead to 18 + 4 =3D 22 (mpu 64). For FTTH the answer is less = clear cut, since different underlaying technologies have different = relevant per-packet-overheads; however underestimating the = per-packet-overhead is considerably worse for responsiveness than = (gently) overestimating it, so for FTTH set the overhead to 44 (mpu 84) = unless there is more detailed information about the true overhead on a = link available. >> =E2=80=A2 None: All shaping below the physical gross-rate of a = link requires correct per-packet overhead accounting to be precise, so = None is only useful if approximate shaping is sufficient, say if you = want to clamp a guest network to at best ~50% of the available capacity = or similar tasks, but even then configuring an approximate correct = per-packet-overhead is recommended (overhead 44 (mpu 84) is a decent = default to pick). >>=20 >>=20 >> I hope this is explicit enough. >=20 > Yes this looks a lot better, thank you. >=20 > Although I must confess that it certainly feels counter-intuitive that = for ethernet (and FTTH) we suggest a higher overhead than e.g. = VDSL2/cable (which themselves run off an ethernet interface). That is simply because for (ADSL) DOCSIS VDSL2 we have a much = clear picture about what we need to account for. And AON can be = essentially using true ethernet encapsulation so we can expect an = unspecified "FTTH" class to encompass a broad set of different = encapsulations, if we want to recommend a single number that should also = cover AON (the PONs are much less clear*). Why do you assume that FTTH = necessarily would have a smaller per-packet-overhead than other link = technologies?=20 Now, if you have reliable information for say GPON-overhead, by = all means add it (but to be useful this also should contain an easy = identifier for other users to figure out whether they use GPON in the = first place). The bigger point however is IMHO, from the perspective of = minimizing bufferbloat/latency-under-load-increase using a slightly too = large per-packet-overhead is fully benign, while specifying to small an = overhead can easily result in measurable bufferbloat increase. So IMHO = it is fine to err on the side of too large when estimating the = per-packet-overhead. *) The core problem is that we have no straight forward way to = empirically deduce the effective per-packet-overhead over an arbitrary = network path, so if a link technology defines/documents the overhead = well and conclusively (like docsis) we are in luck, but if the details a = vague or leave many options to the ISP we have to make an educated = guess. > I would also like to see some info about ppp vs ethernet interface in = there (matching your previous email): unless you beat me to it I will = add it. I will not beat you to it, because for users of cake it does not = matter and we do recommend to use cake in the first place... heck even = for folks wanting to use HTB+fq_codel I would recommend to start with = cake and then look at the output of `tc -s qdisc` to figure out the = overhead that is already accounted for on an interface. > I also think the =C2=AB details =C2=BB page needs to be reformatted a = bit, it=E2=80=99s very dense and relevant info is all over the place and = not very well organized. Might well be true (the page evolved over time and might need a = full editorial pass), but it covers quite some territory and hence = always will be a bit unwieldy. > I=E2=80=99ll try to get around improving that. Please try to keep all correct information around in the = document. Good luck >=20 > Thanks