From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vps.slashdirt.org (vps.slashdirt.org [144.91.108.218]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7BF483B29E for ; Wed, 16 Nov 2022 06:46:59 -0500 (EST) Received: from smtpclient.apple (tardis.herebedragons.eu [171.22.3.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by vps.slashdirt.org (Postfix) with ESMTPSA id 73B6A6014B; Wed, 16 Nov 2022 12:46:57 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 vps.slashdirt.org 73B6A6014B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=slashdirt.org; s=mail; t=1668599218; bh=Zp6Gv7GVQZW7m97lYvMNOye7zQQ9Ji4VRM0AW8nvxvY=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=TEAykFUeDpdIRJPWJO2LvHiTC42hFqlN7xFzMcQHYL9joqb4emQwpr/fy3z2edghV pXUYH8KzxKI+upATOL8Jj6yrO6LwmcZ2/C524QSxVUkqIR2yVOFzzs9I6oklnofhzz 0AYVC6fV2qoedx5lu7jEIkquW9MbtBOtIYjK+onE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Thibaut In-Reply-To: Date: Wed, 16 Nov 2022 12:46:56 +0100 Cc: openwrt-devel , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <4CF53FE3-D26A-4E32-8378-3B27BBB70AEF@slashdirt.org> References: <386F2ED9-3D39-4A42-8982-742B5D4B417F@slashdirt.org> To: Sebastian Moeller X-Mailer: Apple Mail (2.3696.120.41.1.1) 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 11:46:59 -0000 Hi Sebastian, Thanks for your reply. > 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". 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. >> 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. 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. Currently we achieve neither IMHO, hence my initial email :) >> 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? 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). So I=E2=80=99ll try to edit this section to move the relevant = information back where it belongs. >> 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. Hmm ok. >> 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... 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. >> (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... Could you elaborate? I=E2=80=99ll try to integrate your comments in my = update to the wiki, with your permission. >> 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 OK, understood. Thanks again, Thibaut=