Hi T.
> On Nov 16, 2022, at 12:46, Thibaut <ha...@slashdirt.org> wrote:
>
> Hi Sebastian,
>
> Thanks for your reply.
>
>> Le 16 nov. 2022 à 11:49, Sebastian Moeller <moell...@gmx.de> a écrit :
>>
>> HI T.
>>
>>
>>
>>> On Nov 16, 2022, at 11:22, Thibaut <ha...@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".
>
> 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.
>
>>> 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.
>
> I hear your argument, however the point here is that either we offer a «
> single click » 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’t 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?
> or we allow customizing this value and then it seems logical to offer precise
> guidance on how to do so, especially in the « detailed » 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.
>
>>> 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?
>
> It wasn’t to me. And I don’t think that « jokes » should be part of a
> technical explanation that may be read by non-native speakers (like myself):
> it’s likely to cause confusion (as it did for me).
Ah, indeed language barriers can be real issues.
> So I’ll try to edit this section to move the relevant information back where
> it belongs.
Yes, that is what a wiki is for.
>
>>> 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.
>
> 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?
>>
>> That is your choice...
>
> Well I don’t really care to choose (and I suspect a lot of users don’t
> 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 « it doesn’t matter ».
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.
>
>>> (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...
>
> Could you elaborate? I’ll 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.
>
>>> 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.
>
> OK, understood.
The same is true for HTB+fq_codel, BTW.
>
> Thanks again,
> Thibaut
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
