From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 1E6A83B29E for ; Wed, 16 Nov 2022 07:10:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1668600642; bh=lq3hLaZckrTo8zokvjcfnh8y+KpNkO7+OCN+9OAm9e8=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=IxUG8m5ojUbMQ3UdyFqWbdfYWGvYWTn3IUt+nvXVWPbgNGlYWq4Al6WsmU7ZHfjrM 2ojC0ulYw6CO9XGczUnaUZokYQKCjU7w9CsWxpAdRIkkodjcZ3a1owoVYnB2GiK+er /vXDGMeyna4pl4yVIv7JdwUZJkZhzutB3XyTr4ZhC0TTrWBt34eIg1FgmUj8R7KRlR uIBDa06Xkt0bC8782QqCkSKGz+6u8iGEFKaiPxk7Ih+z+qs+ulxk2yPKuqyu70tcnq oNdt7YDFOzbNrzW7zhxEzd5xX8ji2+hneRVCKwfJRWYcGNutz77ezbpEB7iUj22jpu /6IvkROuy5LDw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTzfG-1oVONf3X3y-00QyPL; Wed, 16 Nov 2022 13:10:41 +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: Wed, 16 Nov 2022 13:10:37 +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:AwP9uI8ZNBwD6q25sWKafgwPe7+JMsWQqiuD2A5Z5TOj2sHt+G6 +Nt4sScsev+DUwPHEalHha+iE4jbHlFPGceS0BVzED7O9juiKMihrWqNjckEJAFu2vfmnFG ZuHitU6ZD/9JOirHX7NxDHfU5zrVqiU2WdE7KbDiy22sv59iw3SKl+eYpHz5Pi1C1dLgs2X BYAwcq+yk5uZysk1RukYg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:vvjHy28sFdE=;j9wkR8sZv2XqqB3mODHYmNCuNJH xz5aQAMabhVUtllRLRzQ68fKM/p7FRYK0RPE0NBnggik7ixL7utGvxvhbI6MP48vR6YbCqHNr TufzFvyCwqVkde0zL0DKuLiZB9nFGY70QT5betTMjbtCUxuBC9o4q+8tuIvQPPd2uC9PIikxQ CQDKJaZUK1XX187DeN36o/LjqbbDP3m+jGxzrc+W726DwRutqFmVpqwFIq/7h5vnnGGcd7Lug LBGvnKACHqj0VxG8LobgjLjsZVWtxJkuF7sC4qpPI2/UrfHYVj27UCyAbiiT14L/ew1eHjHay OvvmE7ymuNqfU90xfpR3q6LjH2wCPWfeJuQsXMrDRkkq8dDZem2/65JB0QKvHgrP0Nl0CcV5z 023+2j3cHPch9iOLjZxzZQ/SZ9Lqlop0CMVAh1ELTGoz+Cvauzqg5KjnYk691RLNCy3vr7ulU 8gGrUNLvK73Sr54QdkiPxw819EXNio84xy4Oidr5DGnraLvaAxr6o+G/GVg4EN91Hj/KOUkqE /pfwD2sHp8XqyHobf2fXonb+MZZfZMXAyXNcuCtSb9hEbQ7y3yRcp+ZzP8nrgMuPYFtCwXR+c GOgjiygiyyBo//YA2LzLorOZo11MN/bY9ob/lSpULsAFFMBIUf8M/3wxRNpy/60iqAr8p10Er nIGWebNAY8PKy/PHRDVStp/GX6mPF25/8/dF5eEqozQmLFJV3qDd1/n+pvbOQCcYUb4wbspTc NL5NQj4EryoMg459i1BU0T67KiFKhvY7v5zqBE028xptn+4oOoshVSqG6kX3v6sUm7aMobBj0 p31Pc1LZ4z58GDjWCUQwD8w9q6sl6j5vcRd8rKjsEhD31CJKohpwUGTI4hXJUcAc9+6p1MGCF SDnBNneapZFUO7b2a27y5/KeNFpecDj6VP9CL91vSnjNcFISEvxbtOPwF6s/IgX/yKpxJJn3J aa31A3qwUi3guPXU7pz9A+q71IM= 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: Wed, 16 Nov 2022 12:10:46 -0000 Hi T. > 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. Fair enough, however the OpenWrt wiki articles are often not = written by the core developers (that use the devel mailing list) but by = volunteer forum members. >=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, As I tried to explain, we can not really do this as the only = generally save configuration is too ugly. > and then we shouldn=E2=80=99t even bother allowing to tweak the 44 = setting by default, Erm, one idea behind SQM was/is to configure sensible defaults, = but allow users to override/change these. I take it you would like to see "overhead 44" as hard default? =20 > 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. Well, it is a wiki, if you have robust and reliable information = about a specific encapsulation feel free to add it to the respective = page. > Currently we achieve neither IMHO, hence my initial email :) Again I respectfully disagree, = https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm is = pretty clear in its recommendations. I expect that people following the = link to the details page will actually read that page before jumping to = conclusions ;) Then again the details page has seen many small additions = and changes and apparently is in need for a full editorial pass again. >=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). Ah, indeed language barriers can be real issues.=20 > So I=E2=80=99ll try to edit this section to move the relevant = information back where it belongs. Yes, that is what a wiki is for. >=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? :) There isn't a correct choice for all situations, it really = depends what you expect. > 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. Which would be wrong. For most users one is as good as the = other, but there are subtle differences that might matter depending on = the circumstances. E.g. PPPoE interfaces are often removed and = re-established which SQM deal with gracefully due to hooking into = OpenWrt's hotplug mechanisms, but say you want need persistent = statistics you should instantiate SQM on the L2-device instead, if you = want the statistics to be reset on a new connection to the ISP = instantiate SQM on pppoe-wan. >=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. Only cake is refined enough to figure out the total IP packet = size, tc's stab option will take the skb-size (IIRC) which typically for = IP over ethernet will contain 14 bytes of the ethernet header if we look = at an ethernet device, but on pppoe-wan it would not show these 14 bytes = (these do simply not exist for pppoe-wan, the kernel will add these once = the pppoe packet gets handled by the L2-interface) and I forgot what = happens on IFB interfaces. I would always recommend new users to simply use = cake/[ieve_of_cake.qos rather than trying to explain all these pointless = intricacies. >=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. The same is true for HTB+fq_codel, BTW.=20 >=20 > Thanks again, > Thibaut