From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1F9523B2A4 for ; Wed, 21 Aug 2019 05:17:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1566379037; bh=z/lTuwpZlaZG8F8T6LKv+N9VcKau+6OnCR6c8R7UqIs=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=R2tGbaFxHNItTOSOaeDyJbeUC5yEghaAzrvVsRVLtDcnPwU77KCXbFbGmHQYGyqPQ UrWY6UXHyCd+C4BhFHvVwIgNYHlzmPjT7WEuNfMyIQlCgmvlQvNjN6oMJbPEPyS+CS eR7pvaeZq6W238JAjnLw+1CcnY6Fq3LgzMamIewo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.32] ([134.76.241.253]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MQ33z-1hwGGl3t1H-005EhA; Wed, 21 Aug 2019 11:17:16 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sebastian Moeller In-Reply-To: Date: Wed, 21 Aug 2019 11:17:16 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , "cake@lists.bufferbloat.net >> Cake List" Content-Transfer-Encoding: quoted-printable Message-Id: <417D900A-4FA9-436D-BED0-9B9CB0BBE54E@gmx.de> References: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> To: Sebastian Gottschall X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:iCZKwynT79fdZN9DMw8V5fg+QUp+Fr2NT7g2r7iwzXS43s+ghmf ItPf/NnyKa6c9i9Tnf7SvvTrRlJb71b712QUsPKJgPACeYhXxEYR6PvDdF3lLCMT5hri51P FtL9Ha8OksRKeT/RFtlqGBm7bf6OHovBmorPCX0lO92u1d5h4JbiKSELdAxmGnwW0gTBbC0 TFHFTimWFan0/DDBraUmw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:oZSMd5G5MYU=:r+s+F/hXCdIfXZNSp0dK+K NAEuzKMBdkFxarDcaPAly8JOshxMiPN7GiUberlXPPQdrO+ClesxdIe//jZMFV4lOvkE11lbf jML8/I2qY4N3DczTweWZWFuFxxbWjSlZndAL4d0c9oOvgyxud6X0tSSSdYEMnp5Ag+Z9cRCzU rEBd0EKw8+o34ZnEpqeF+DRqSNdhc5jSEacQ0u17lDDOqfNNkM8cn2J1jP/SjZ4GzR/517bAo Sa78E0LRHdjO7uMAS6E8MduQyk9NAtOb3I8CFjuA422VV2wbyHUDt3AkSDzdadyHlIIK5gj7r Oj5OcJ55uJ+miZSD0cS173Pt6Qs6JTuRmWmqc5YFb18d0KW6veDzaEWT6x9FEZdqtQR1QiQGB Vlzi9NFGt2zuRWLVxYdCXIL4uunAOOxVQ3xhxeuQxxB1gSxDuP+HMQLmY9PFofHoGJ2SL8sns Z/8E8qP5JX7bTvzrh1xEUYpBy+Nl02Bee4Q4w7wg4s0z9o1IKbGIFYboAfOPYrg9QNYec2dnW mVZSNjJlqncybTWjE+ST0lTYLSWMGKhj1iGdXW6KZ4DiahqIR7/+CAIwNXfeuL3Y0KaoRKh0L t+pRVHa0iqOviwvzqYe2KUiYdso1tFmlQTiG+sJ2jt0+MgcpbDuqS0ULjL7DMoocbEhCmilkx V8r6K7/q98eQy0bwBt84jxKRE/WdezW1L1cazR2/Xx0zn/ZWwo17fl4rhEXO20ixZBnExa53+ w2TSYRiXDzjYcGxgYnRmB1MHZB4YzZGdRpDmjV5vvpf7LdeLGMqGDBUo/7K+PT+qSDXLQ6eQH g73YP1II5V/eTYLYQOEHAfxYpoRpURrQiu5WuW5WiSrO6zPpK6SUxGZNH1Pwyl1tjZm/y6zcz 9Ud90/CB4Fs13oTpEtOfzm3EUCsY6jc+7tPhTJKT4FCdU6ohsXnBET9W4Lg2169f6ZSY6Eh4K wIamlAj/APU6S5l/zKI6ETpEpS6GlLFQjD8PlA3m/CC++KdJRZi2EOhHWm2jtjisIa1BJ3GDD uapDdfmaOy6R/Od8hAFZke0uyl8eVcXUsDq20R9h/tO1VrWY+xO3mS+v7RUPn9vBnzXpFMLxT AszBrD1GDRYjSkxvYeAS9zq3FXn+8Uz3VmGloezaH2uLk0Dx7WIjEwzsji18nDKuXWFwsMrA9 sFzbCAxbMxuR5yNjJLmAW8VySu31P5qef7V4WRDgEPpTy3jQ== Subject: Re: [Cake] cake in dd-wrt X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2019 09:17:19 -0000 > On Aug 21, 2019, at 11:04, Sebastian Gottschall = wrote: >=20 >=20 > Am 21.08.2019 um 09:56 schrieb Sebastian Moeller: >>=20 >>> On Aug 21, 2019, at 09:50, Sebastian Gottschall = wrote: >>>=20 >>>>> 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). >>>>=20 >>>> 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. >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>> Sebastian >>>=20 >>>>=20 >>>>=20 >>=20