> On Aug 21, 2019, at 11:04, Sebastian Gottschall
> <[email protected]> wrote:
>
>
> 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 :-)
Nah, barely good enough, breitbandmessung.de might be suited (they have
access control to not overwhelm their test servers), but other Speedtests are
notoriously inaccurate* (I am looking at you Ookla...) and occasionally report
"measured" goodput in excess over the actual goddput achivable over the given
gross access rate.
IMHO the real challenge is that to set our shaper correctly we need
both information about the gross rate of the link (which can bei either
physically bound, by say a dsl-link's sync-rates, or in softwar, say in a
BRAS/BNG-level traffic shaper) and of the worst applicable overhead between
user and ISP (which again might be a physical link property or might come from
the configuration of the ISPs traffic shaper). Most ISP will giver very little
information about the precise value of any of the two. So we need to solve for
two unkowns (per direction, even though per-packet-overhead likely is going to
be identical for both directions), making the whole endeavor way more
complicated than it should be. If we would know at least one of the values
precisely, gross-limit-rates or per-packet-overhead, we could "simply" try
different values fr the other and measure the resulting bufferbloat, plotting
the bloat versus the variable should show a more or less step-like increase
once we exceed the parameter's true value. But I digress, we do not know any of
the two...
*) I guess they are precise and accurate enough for their intended use-case,
but they are somewhat problematic for precise measurements of real maximum
goodput.
>>
>> Best Regards
>> Sebastian
>>
>>
>>> Sebastian
>>>
>>>>
>>>>
>>
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
