Am 21.08.2019 um 09:56 schrieb Sebastian Moeller:

On Aug 21, 2019, at 09:50, Sebastian Gottschall <[email protected]> 
wrote:

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
as i said. i just started. lets see if i can find a better solution or a clever 
way of auto detecting/measuring the overhead
        If you do find a clever and fat way, please let me know ;). The best I 
came up with only works for ATM/AAL5 and is neither clever, automated or fast 
is at https://github.com/moeller0/ATM_overhead_detector (which has the 
advantage of also confirming ATM/AAL5-quantisation). I have some ideas about 
how to deduce overhead generically but these require very precise measurements 
of maximum goodput for different packet sizes and even less fit for general 
consumption that the atm stuff.
then the only solution is having a good reliable peer for measuring. we may missuse speedtest servers :-)

Best Regards
        Sebastian


Sebastian




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

Reply via email to