Hi Thibaut,On Nov 17, 2022, at 15:22, Thibaut <hacks@slashdirt.org> wrote:
Hi Sebastian,
Le 17 nov. 2022 à 10:50, Sebastian Moeller <moeller0@gmx.de> a écrit :
Hi T.
so taking your proposa under consideration I canged the section that threw you off course to read:
• Ethernet with Overhead: SQM can also account for the overhead imposed by VDSL2 links - add 22 bytes of overhead (mpu 68). Cable Modems (DOCSIS) set both up- and downstream overhead to 18 bytes (6 bytes source MAC, 6 bytes destination MAC, 2 bytes ether-type, 4 bytes FCS), to allow for a possible 4 byte VLAN tag it is recommended to set the overhead to 18 + 4 = 22 (mpu 64). For FTTH the answer is less clear cut, since different underlaying technologies have different relevant per-packet-overheads; however underestimating the per-packet-overhead is considerably worse for responsiveness than (gently) overestimating it, so for FTTH set the overhead to 44 (mpu 84) unless there is more detailed information about the true overhead on a link available.
• None: All shaping below the physical gross-rate of a link requires correct per-packet overhead accounting to be precise, so None is only useful if approximate shaping is sufficient, say if you want to clamp a guest network to at best ~50% of the available capacity or similar tasks, but even then configuring an approximate correct per-packet-overhead is recommended (overhead 44 (mpu 84) is a decent default to pick).
I hope this is explicit enough.
Yes this looks a lot better, thank you.
Although I must confess that it certainly feels counter-intuitive that for ethernet (and FTTH) we suggest a higher overhead than e.g. VDSL2/cable (which themselves run off an ethernet interface).
That is simply because for (ADSL) DOCSIS VDSL2 we have a much clear picture about what we need to account for. And AON can be essentially using true ethernet encapsulation so we can expect an unspecified "FTTH" class to encompass a broad set of different encapsulations, if we want to recommend a single number that should also cover AON (the PONs are much less clear*). Why do you assume that FTTH necessarily would have a smaller per-packet-overhead than other link technologies?
I’m not (necessarily) making that assumption for FTTH (although I would expect it to be the case, from my limited understanding of FTTH technologies), I am however certainly making that assumption for plain ethernet, which is included in the 44-byte documentation case. I think it’s a reasonable one?
Now, if you have reliable information for say GPON-overhead, by all means add it (but to be useful this also should contain an easy identifier for other users to figure out whether they use GPON in the first place).
The bigger point however is IMHO, from the perspective of minimizing bufferbloat/latency-under-load-increase using a slightly too large per-packet-overhead is fully benign, while specifying to small an overhead can easily result in measurable bufferbloat increase. So IMHO it is fine to err on the side of too large when estimating the per-packet-overhead.
OK. Although I would think people reading the detailed explanation are looking for precise info and explanations, not one-stop-shop approximations. Not to mention the kind of users who want to squeeze the maximum performance out of their setup.