From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 3A3833B29E for ; Thu, 17 Nov 2022 04:50:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1668678622; bh=4kswmEsuOV8wFldEX690rpmPgmeVtPoyGoY1JXkuD10=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=IDGMQh1FcWzGor3Mhm0n1fmx8jpeleuExper2RcmYfP8TuVPH0psFOrGz6iWuZ09B c/g2bPLLH0Jnn/B3olsGN/756lNvcR6gxMfTbiz5dz8tk2ROMlOmi2jTYPxPgcCXhZ oQ9wlAo49Gexp2JyngZQ8Jeo+JeBURPreJ8vJc5fNq6BzUtvsKNuHzM5nTGGzf46TC XoB5I8zsCI2P+87eWjeCB+JNVbY+ctnvX0KcuRTz09KPLiIw6jmShwZGPRVD13C66y +uHJLOM6zQ+iJiok6pFdVUwmy8myA1D4mOCI4q+mLRJrWuXZ3MRs2kD2LCzGcKe422 6F5GsQF5KDWHQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3lcJ-1ovKHt1Zpb-000rRi; Thu, 17 Nov 2022 10:50:22 +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: <4CF53FE3-D26A-4E32-8378-3B27BBB70AEF@slashdirt.org> Date: Thu, 17 Nov 2022 10:50:19 +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> To: Thibaut X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:UbA1LFTq6f+ZZ9a3Hp/KZ2xh9kScx1UAk/J0awv6aNfQw9MZPDx pvz0kj4t9swOV/TRfjAAPZpIxGe5aCzITjj9G2GkEoDuNEbE4BefuiKa77UJrPZQNsVW7H/ QEnSMjNQmvtSdyLc1OvwXHaRMqCe9yjEM6pknaKHZA0/G5Xn+JZMeWRqn2EZCx4sInanxft VMuaLMiTBGNUKpGetZy2A== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:xw3lpyZE6U0=;jY99+cOAlJYfNlujEbSJ8ix9KkO cDlP+Vxvk5ZhvhitQ/kTd1y0bWmTgP1rLo9zFzZr9gWf85cmRgI19pg/5ns290atjf7iMEyg3 PZRd9F7IcagHvSyZ6GSMb3YgOt+8B5Bd0r2EKEa6emL1iWrv7ki/pEnPRPVVgfWDZve33O/R2 cQFSNwuogav201f15UUHB0oYGqRKN71du1zJky6wWa9wUft5uyp+/g4DJlVDMIixbx5IW55io v2pU3VoK9rvI6eGqvpUjWEcBWSLR0YB41X6BxvdaLz/cpzTLMUS7tsZ9imlwhAOnB5TQAsgCa k5daJAM0/PW+lCtf4LJM6j+vWL0DyeGiEelW/O0bf8tnsFuANPPGaRE4TI3Ve7jTw0sr2AAHs GivBalqco3cil+xswF15EeKYH0ziLR4mSg+09MLXQBvG0zmz888X+0E29Fp6/t79WkxgXF/M8 S7GeQjYqBVS6vb5UNX0ruryryNjb8AhJzbi5YJ0NnnKSqw6CM3Uu9ovjKaAoddT4RTQSP0M8d 6W0RMSufvxQsxSKxn8V2uZV7HYy+GnGylXEb8Xey9ok+sRClnUpnj1pXVCOmeQbTNDEYp0xzv RWyOjZZipGXX7IZ6uSF0jqrtktIlTvSX0bmujLq2FNSNFCSw/GzEUH5h5pWuIgJP7zeG66GKR WzK2rBTd/97+T4VRTLdCkoFIjAnrPbNzfuONTyr91okoiOvbkuXZhBkNDZKP/4CnOAVjSshSs UzqmM4lDfBee7lKfDryJDdixQWmJ/FUrTh94DWbAlzJjt0ocwCJ2Y7TzFSuUwQv9c/wrQWWNd MLI5bHZPLxxDcJCbE9uv4fTSQ3+RqXyloRcarrZm31Z74O0LZKIbMzW844vTSRk2MYoFvEi5P K8PYD1DFD01wkvSc8Jx9lfdkP4C87/DLuSXBGM/EjN0eBFGsXfvSf7QsWC/iD3jZo5pUXLsDY FVd8uuNU5Q1GadJO5zTbuqMhNJg= 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 09:50:24 -0000 Hi T. so taking your proposa under consideration I canged the section that = threw you off course to read: =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). I hope this is explicit enough. Regards Sebastian > On Nov 16, 2022, at 12:46, Thibaut wrote: >=20 > Hi Sebastian, >=20 > Thanks for your reply. >=20 >> Le 16 nov. 2022 =C3=A0 11:49, Sebastian Moeller a = =C3=A9crit : >>=20 >> HI T. >>=20 >>=20 >>=20 >>> On Nov 16, 2022, at 11:22, Thibaut wrote: >>>=20 >>> Hi, >>>=20 >>> A few questions for the CAKE experts here: >>=20 >> Quick note, this is not necessarily the best place to get advice = on cake, both the cake mailing list and the OpenWrt forum tend to be = directer paths to the "bakers". >=20 > Well since this looked to me like an openwrt-specific question (with = links to openwrt wiki), it felt more adequate to ask here, but thanks = for redirecting. >=20 >>> I=E2=80=99m trying to untangle the information available in the = openwrt wiki: >>> https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm >>> = https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details >>> and for the latter especially the part here: = https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details#sq= mlink_layer_adaptation_tab >>>=20 >>> For ADSL/VDSL, I believe the instructions are clear and the Luci = interface is too. However for ethernet/fiber, I=E2=80=99m confused: >>>=20 >>> In the first list of this paragraph it is first suggested to use =C2=AB= Ethernet with overhead =C2=BB and set the per-packet overhead to 44 for = FFTH (which seems like a large value for this use case), >>=20 >> That is the point here, 44 is a value that in all likelihood is >=3D = any realistic true overhead. Gently over-estimating the true overhead = has a relative small cost in potential throughput, underestimating the = overhead however can result in noticeable degradation of responsiveness = under working conditions, so the recommendation is to rather err on the = side of too large an overhead and not too small an overhead. >> Why not simply recommend the worst case scenario `overhead 44 atm` to = be on the safe side on all links? Because the ATM/AAL5 encapsulation is = only used on ADSL links (so is getting rarer and rarer and the ATM = encapsulation results in a >=3D9% throughput reduction on non-ATM links, = which is IMHO too steep a price... plus the ATM/AAL5 encapsulation size = in addition also depends on the packet size so not a reasonable default = in a world where ATM-usage is on the way out. >=20 > I hear your argument, however the point here is that either we offer a = =C2=AB single click =C2=BB solution, and then we shouldn=E2=80=99t even = bother allowing to tweak the 44 setting by default, or we allow = customizing this value and then it seems logical to offer precise = guidance on how to do so, especially in the =C2=AB detailed =C2=BB = section of the wiki. >=20 > Currently we achieve neither IMHO, hence my initial email :) >=20 >>> then later in the second list (=C2=AB the details =C2=BB), it is = suggested to use =C2=AB None =C2=BB, directly contradicting the above. >>=20 >> Are you referring to: >>=20 >> =E2=80=A2 None: Fiber, and direct Ethernet connections generally = do not need any kind of link layer adaptation. Well, I am kidding, all = shaping below the physical gross-rate requires correct per-packet = overhead accounting, but for fiber and ethernet it is much harder to = figure out the exact overhead to specify=E2=80=A6 (the question is = typically how is the ISP's upstream traffic shaper configured). For true = ethernet shaping without VLANs specify 38 bytes (mpu 84). >>=20 >> I was under the impression that the "Well, I am kiddung" part was = clear enough, no? >=20 > It wasn=E2=80=99t to me. And I don=E2=80=99t think that =C2=AB jokes = =C2=BB should be part of a technical explanation that may be read by = non-native speakers (like myself): it=E2=80=99s likely to cause = confusion (as it did for me). >=20 > So I=E2=80=99ll try to edit this section to move the relevant = information back where it belongs. >=20 >>> The 44 byte overhead for ethernet/FTTH is also mentioned here: = https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm >>>=20 >>> More specifically, there are two (increasingly common I think) use = cases I would like to document with your help: >>>=20 >>> - FTTH with plain DHCP, no VLAN >>> - FTTH with PPPoE, no VLAN >>> (And adding a footnote for the extra overhead to consider if the = above include a VLAN tag) >>=20 >> I am with you, I would like to have these settled as well, but = alas FTTH is not terribly well defined as a technology. For active = optical networks the encapsulation is likely ethernet framing, but for = PONs like GPON and XGS-PON it is far less clear what needs to be = accounted for. Yes with PON large parts of the ethernet framing overhead = are replaced by a smaller GEM header, but how to account for the = request-grant traffic and stuff... >> The good thing is that gently over-estimating the per-packet = overhead only leads to a relative small reduction in maximal theoretical = throughput, so `overhead 44` is still a decent recommendation even for = FTTH. >=20 > Hmm ok. >=20 >>> In the latter case (FTTH with PPPoE), another point that needs to be = clarified is: do we apply CAKE to the ethernet interface, or to the PPP = interface? >>=20 >> That is your choice... >=20 > Well I don=E2=80=99t really care to choose (and I suspect a lot of = users don=E2=80=99t either), except for the most relevant/efficient = choice if there is one: which would that be? :) > In any case I suspect this is a FAQ that should be addressed, even if = with a simple =C2=AB it doesn=E2=80=99t matter =C2=BB. >=20 >>> (and I assume that depending on the answer, the overhead settings = will have to be adjusted). >>=20 >> It used to yes, but cake is smart enough to get the size of the = IP packet and add the overhead on top of that, so the overhead will not = depend on whether you instantiate cake on say eth0 or on pppoe-wan = (assuming pppoe-wan uses eth0). HOWEVER for simple.qos and simplest.qos = it again matters... >=20 > Could you elaborate? I=E2=80=99ll try to integrate your comments in my = update to the wiki, with your permission. >=20 >>> Also in that case, what about ISPs that allow sending a full 1500 = frame over PPPoE (using 1508 MTU on the underlying ethernet interface)? >>=20 >> SQM with cake does not care about that, it sees the IP packet = size and adds the configured overhead. That wat cake also has no issue = with GRO/GSO meta packets which can be up to 64KB in size abd still get = accounted for correctly. Baby-jumbo frames from that perspective simply = result in IP packet sizes > 1492.=20 >=20 > OK, understood. >=20 > Thanks again, > Thibaut