From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from webmail.newmedia-net.de (smtps.newmedia-net.de [IPv6:2a05:a1c0:0:de::167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 45E713B2A4 for ; Wed, 21 Aug 2019 03:51:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=newmedia-net.de; s=mikd; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=UvjjeDvIOnJjcGFYPN7dur0erYZh86I+fh5libEvkmU=; b=a+NpxSUMlezU67J463W1wvtl7VR3NZM68D0GqnEwJ9VDxPQ0/9xUXVh8TShcsV/hmYT4cal1Wdbm/xaoqIctrxn5MueLFh/bjF00ipW/5knpWMdPxKR9cvrh7TzdjQLSqjVupo2b7daNyCfwP2bDpe3V26H2XQI0G1g2HeAtEuo=; To: Sebastian Moeller Cc: =?UTF-8?Q?Dave_T=c3=a4ht?= , "cake@lists.bufferbloat.net >> Cake List" References: <384866b4-4c91-cf2c-c267-ee4036e5fbf7@newmedia-net.de> From: Sebastian Gottschall Message-ID: Date: Wed, 21 Aug 2019 09:50:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Received: from [2003:c9:3f25:1300:e947:ab73:1d88:4792] by webmail.newmedia-net.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1i0LPZ-00083k-Ja; Wed, 21 Aug 2019 09:52:05 +0200 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:51:59 -0000 >> 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 Sebastian > > >