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 300A83B2A4 for ; Wed, 21 Aug 2019 03:56:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1566374192; bh=95ZeZLHv3Rm6Rtdd3RNx3bJq+Hro8iXelh9LpD8AJBo=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Z49/tKZYe0XYZrluPBz0u9PrOnnenjuTB6NPOgs1du98QD70OL+hbwErYoZ2qRTF5 3DxUhR9rhAcR5Kw/RjZomvsqPtvLXYbYgP4pWVVBfxrMwqVjkT4i7EmCmVTMH2QRpf b5cKcqspf3T+5vtzqwmxEyyfP7/OofmlP90X4PiI= 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 0Lvkwm-1iImb61vbg-017XwS; Wed, 21 Aug 2019 09:56:32 +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 09:56:31 +0200 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , "cake@lists.bufferbloat.net >> Cake List" Content-Transfer-Encoding: quoted-printable Message-Id: 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:dqxHZ+eola98RbippefxQzxGfGg9cuIAIP4KGcT4v4GhD9iNd34 o3jVJ+c2HtyDQ3Wh81pDR/QPyiE2Pt7INCIj8VyYOp71Pw3lmrzrFF4Zg8R5t1k4iOSADpf Nr+ZP5Mc9aLDPqcNMOkDp/B4cLtveAPK8k3vm6zr/sMuWtjQrganClME/Ao3oSC1JmBZ2k0 JRQUS3Pn2Hl8iFZ4z9N8Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:piKOb7yQwak=:EQHVg7EHena6HrjjJ0D8Lc h+FFRZUW0olFPpe28rPzKQ3LbbAISD0INOx1h0ns3K70+HvumM4/bfcaLSOK840yVjPPul2ye XVT60xhUJto5YHTXZ7x/dsRuDXZfaQ6Y44UK4ssDtOWeKs1YJxvDdvkixIHKaHzDzN7tKHOIM q6Q3yJahUhywHk7aNRxTUot4pT+jtYzEHexu+TzDv9zA2DJm9RKjZtMf/zUvoTMpEMFD52Z0H wL7tJVUfgthj/HZoBFoV+o2+JObHOPmTPAD/ZcJEmv8LR3Lq7Z4TiNv17/Y63Lg083HsHnVhs B4C9VWeimzLALDm4F7gnzhE6kXfYuEWJ38fH/VCl35ZlPcs/wXJD8+nhnNNCW55WTKg3Bdh62 N069XQHW2SzyagGBICuw4qR24NhnoH7dqLSQTAK/5N4bANIL5QfvEzrY8UlXVej1obwezqvjf GSdWVLuPq0AZJo4AUSEYcS/MezEstz7AKw4E4pfvTGEeBBoJrCJeaMkUcTcAjcBLhAkunSh91 Q+KvJO2K8+XMip1iuRkl+QAg9YtIbLaTlxb06bHRX32Tv9VW7twGcfIvtSek+pp6YrTh1Jcop hdG0rCUVTVv4xZhcwxxXeF5QkwViPvzIpsdEBGrXKaDmukVGlaIIu4ad71hbzAdEY/b+5a0pN 297cUe9tuvxXxtFqWaJpuRAOIxNGk4kubt+gaiJV4DLPKGroaPwQh3rwzhGeWFhDodQinnbvo 5pw59TmEMKvCqNIuMudumd+/OsdNCxntMYPAGbueCr2GWx4ELZYhL04nqLAQ86Ds3boVkuZiz 6L/jULjE4hNQsjzXqszCX6FH8ISgMOvHgVcnrH7Nfhft8CmOldx0vSqNKyuGy8LvEh2YNH11O tDNxadCtCMYt8Eb7LLX2u/K6QatLlh+/p83HfDWusvfIU80/2T7CqmfJ6esBQ/f2UX8VwP7Lu j2ERK0avalyzKqRsasfOknRUYvv+hTOhUApnr1p7ZFc7+y319JT606yUKhdH4WVQS2JoAK2ag PERM7ebiU6LFzV095KLsi8zkaVda4KKtEPqKUGF2eATDwLjvO+mjA02hhFBxu0bdvhcD1tgDd L6DD4oFjetIvc7lcVHhj4Q5hJa262CrqNyKI6SlrnnZqbBkxVIulaDoiA1+T/+YXbbXKhGRn7 Gw/OlosdHW7BBMedU2b9uop/oH8FS0PL8g94CBiPQ0yyCxfA== 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 07:56:35 -0000 > 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 >=20 > 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. Best Regards Sebastian >=20 > Sebastian >=20 >>=20 >>=20 >>=20