From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 DC1C83B2A4 for ; Wed, 16 Nov 2022 05:58:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1668596314; bh=HgxNCahFX2v6FKrdGW1+bwuYPCNsfZBA6aMDyVJtqkc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=DoA4SqqZE123fwIT+t3VsSJjknGVi1gWlqa7WSO6KTK1quxoQvHeyd1pTAjYMwkzf CoRFz3hHFLHzJaRcRCkDbYXkCBPeKBIEm6zqt0rTJwUOVnBzwydJ5Y6eB51LJHM4p0 ncm59lsmoF5QGAGPSP4Nk1BS+3wUWiIeqDDLqhwZzzfvSJC9l/04sG8/H+N4rPr6Xy fep3Mtt3PYXZaUdsDsVc0vA4QTx0zwpdX81DPCcDWnmnRnU3B0t3CReoIzP6KbRBHo IMBYIKmuh1POw0jiRX2/tGvAmff/eTCnmC82VSb0bpoEvKCbuGGjrGekYG7R1O0Ktt 4HwXjLHDP2XXw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mnps0-1pJvdI0f4U-00pIQe; Wed, 16 Nov 2022 11:58:34 +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: <386F2ED9-3D39-4A42-8982-742B5D4B417F@slashdirt.org> Date: Wed, 16 Nov 2022 11:49:59 +0100 Cc: openwrt-devel , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: References: <386F2ED9-3D39-4A42-8982-742B5D4B417F@slashdirt.org> To: Thibaut X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:YvNft8dqk/sdJQiCemmBADQQOmazM1Nt79o+uLtvQ193N626pm1 03j+FiCJ6SkZOD+gVdmhJxxCCb941vLw8kVnMqN7kYRe1vuvFsrdQxEnu/TNx8EqRuvzX9v mPm4dFzuvj8qTX65cG7CO6hYTSYsdzUVsAYJoJ0l0854TE9g/yVPhUuL/TFVg/J6Pn+QVh6 PK89B7KZxExfX0YpG65yA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:k/2TWAuvkzo=;i7nB3fWJ3fqP3hBBdkoGEFZvh/b 0OlfCYsjVHFyMCBxO517WQAA2Ox0yerajCh4MhDrKfaTWgyxWsTUWptkjTVwpFLuuzv0ynXIp fN8vm+1ZX+Tc6tdcm3IqbEh4PiBuZ+Q0F+aVSLpPOam0asOYafd8SGdenHo5P4Dnsi751VdV/ XLB3NBthxwJuzHl4ilayVvkKVWcsmr0cFEC85dQLzBQIduddDsgmXDOtcqhT0hwjvY1VNFG2Q EeVb8CTAIygmMuX75UAXtjkaKOeUS1Rl9/SRbIhFxnctl10yiyAVUweL3Y6Mrqb+qB2yABgyG oKdJrnb3UGp8FcIgwp2IhasmrpyU1f2MMCz0a2eHLg+JYBe5yaqUcxo69yFATX06jtmd1FNpy n7oDfIExycQJ7H/qjZLrupJDPM3BarzI8VbthkElOgLsL0PmO5YCWnlre2Ad92fwdSdTJ4spP aYVhVmnWjNMt4H1mEcbZMI8K2Dq1Jmzfe+zzzwcbCHt04g/BuKebWRJetOC+4Uk7010zluq0q A3pqnMLkWL7L/V+zfeHBvD8QAgHZQ7mBaGprJiK8C7XJnvZyR12C1CjqoaWRN41p/iRiA1pg/ Zevy0ADXUCWMmSjtUKLe/aOe2Hh0Iyii3Q+Pc7/L26aRW7tB+GeSjVKmtqmsP0MD+5PHA6JuE Y6ziD0VI7K8gTY/tjO1tvHtSDS6pFqlekFWcdoyjqwSxfA+DzOgAK3bEEkSVyt6gj63tNWS0q 7LK//N5r9S77YrV3zqhVtjb7diOeMYDzC58urde+CuImwXUas2oRw11+tBIJ044DtdBJ3ei49 4mFZFvniKKS6DAv8MlVnXbztT4M4AmdHrHPs8JTI44zXOGUsBVKwvkxl8TOYFuQx6v7fVtkWd Oe8k5CmCAIA+p/kUPBAStoKxSBtKF0xY7haq2QE0/MPZM89hoLx7WGxNzclv3sRDWchcC4bAG b2C+vJLxC3OYk502mrY7u2yEeNU= 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 10:58:36 -0000 HI T. > On Nov 16, 2022, at 11:22, Thibaut wrote: >=20 > Hi, >=20 > A few questions for the CAKE experts here: 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 > 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), 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. > 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. Are you referring to: =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). I was under the impression that the "Well, I am kiddung" part was clear = enough, no? > 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) 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. > 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? That is your choice... > (and I assume that depending on the answer, the overhead settings will = have to be adjusted). 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... > Also in that case, what about ISPs that allow sending a full 1500 = frame over PPPoE (using 1508 MTU on the underlying ethernet interface)? 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 > Thanks for your input, > T > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel