Help untangling CAKE settings for FTTH

[Sebastian Moeller]

HI T.



> On Nov 16, 2022, at 11:22, Thibaut <hacks at slashdirt.org> wrote:
> 
> Hi,
> 
> 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".


> 
> I’m 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#sqmlink_layer_adaptation_tab
> 
> For ADSL/VDSL, I believe the instructions are clear and the Luci interface is too. However for ethernet/fiber, I’m confused:
> 
> In the first list of this paragraph it is first suggested to use « Ethernet with overhead » 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 >= 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 >=9% 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 (« the details »), it is suggested to use « None », directly contradicting the above.

Are you referring to:

	• 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… (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
> 
> More specifically, there are two (increasingly common I think) use cases I would like to document with your help:
> 
> - 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. 


> 
> Thanks for your input,
> T
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel