> On Aug 20, 2019, at 18:47, Sebastian Gottschall 
> <[email protected]> wrote:
> 
> 
> Am 20.08.2019 um 18:24 schrieb Dave Taht:
>> On Tue, Aug 20, 2019 at 5:09 AM Sebastian Gottschall
>> <[email protected]> wrote:
>>> [...]
>> 
>> If I had any one principal request it would be to make sure the dd-wrt
>> gui (if one is made) exposes the link layer parameters. Getting the
>> framing wrong is about the biggest error I see in the deployment:
>> https://www.youtube.com/watch?v=LjJW_s5gQ9Y
> i have seen this already. out plan here is that the user specifies the 
> internet connection type like vdsl2, cable, whatever in case of cake which 
> then will be used
> as argument

        Good goal, that also is theoretically well supported by cake with its 
multitude of encapsulation/overhead realated keywords. Unfortunately reality is 
not as nice and tidy as this collection of keywords implies, There are 8 
keywords for ATM/AAL5 based encapsulations (ADSL, ADSL2, ADSL2+, ...), 2 for 
VDSL2, 1 for DOCSIS, 1 for ethernet, for a total of 12 that all can be combined 
with one or more VLAN-tag keywords, for a total of 24 to 36 combinations. (And 
these are not even exhaustive, as e.g. the use of ds-lite can increase the 
per-packet overhead for IPv4 packets by another 20 bytes).
        Ideally one would just empirically measure the effective overhead and 
use the "overhead NN mpu NN" keywords instead, but that has issues as measuring 
overhead empirically is simply hard... The best bet would be to leverage BEREC 
to require ISPs to explicitly inform their customers of the effective 
gross-rates and applicable overheads for each link, but I am not holding my 
breath. Over at https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm 
we tried to give simplified instructions for setting the overheads for 
different access technologies, but these are not guaranteed to fit everybody 
(not even most users, as we have no numbers about the relative distributions of 
the different encapsulation options).

Best Regards
        "another" Sebastian


_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

Reply via email to