From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1043621F2AC for ; Sun, 12 Apr 2015 23:51:49 -0700 (PDT) Received: from android-2583f1a230e6e877.home.lan ([87.164.165.7]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lubnw-1ZPaAU3yCW-00zrLb; Mon, 13 Apr 2015 08:51:47 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <1D75F7D7-4EA1-47CB-8CA0-51144C58857E@gmail.com> References: <68E872EE-C0D3-4091-97C9-19596BF98AEB@gmail.com> <1D75F7D7-4EA1-47CB-8CA0-51144C58857E@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ERP05DMWPMTBZT5WPY2CJHWPDA67NC" Content-Transfer-Encoding: 7bit From: Sebastian Moeller Date: Mon, 13 Apr 2015 08:51:45 +0200 To: Jonathan Morton Message-ID: <0B243775-FBDC-49EF-B98C-BAE7A61B2AFA@gmx.de> X-Provags-ID: V03:K0:1+qKZS66SqNQwFKMBlX4bXxdGdfGPK0TCwmASf48kmZLh/gzFJy i+Upq4kNhOA5S1w/45meCw2NEiqRO1FfQ2rThf2m0S8c2L+wajHjFRticXn870D8oO4Crij a+ZS2R00VLqTFEMpwWDX0GLIHUZThuOA2Cj91m7qmPQdXtDzKDje8c24vGJ7wOb4ubH5Efc a21miA7MzPWVmoyZxweXA== X-UI-Out-Filterresults: notjunk:1; Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] #17 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 06:52:18 -0000 ------ERP05DMWPMTBZT5WPY2CJHWPDA67NC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jonathan, On April 13, 2015 2:45:35 AM GMT+02:00, Jonathan Morton wrote: > >> On 13 Apr, 2015, at 03:23, Sebastian Moeller wrote: >>=20 >> Ignore my gibberish below, that is almost all required: >ceil(len+additional_per_packet_overhead/48)*53 seems the winner ;) >Effectively this is what stab should offer, but its implementation with >a table has issues if packets are larger than the table estimated=E2=80= =A6 > >The other problem with stab is that the configuration is awfully >verbose - pretty much what I was trying to avoid with cake=2E =20 I fully agree that simple and automatic are real requirements if we want t= his to be actually used=2E I also agree that tc stab has more options than = absolutely necessary=2E I=E2=80=99ll admit >that a table lookup can be faster than a calculation (under favourable >circumstances), but exposing those sorts of implementation details to >userspace is just going to give people headaches while they try to >figure out what to put and why=2E I am not arguing for the table approach, calculating the size expa= nsion directly might be a bit more costly, but it will scale to GRO packets= without requiring special configuration, so certainly your current approac= h seems better suited for cake than a table=2E > >That=E2=80=99s a recipe for people (and, more seriously, CPE vendors) get= ting >it wrong=2E Well, getting it wrong is bad, but not being able to configure it = at all is also going to be wrong for ATM users 100% of the time ;) > >So cake just has that simple =E2=80=9Catm=E2=80=9D flag, which adds rough= ly the right >amount of overhead for cell-framing already=2E =20 Let me be frank here, roughly the right amount is most likely a ch= iffre for wrong most of the time=2E As long as you overestimate the overhea= d you are sacrificing some bandwidth, but underestimating the overhead will= make the shaper misbehave=2E=2E=2E Any optimisations to that >calculation (which are certainly possible) are an internal matter and >not for public consumption=2E I fear that this is not going to work to well, some things have co= mplex solutions because the problem is complex=2E > >It could be refined by adding an additional, orthogonal setting for >non-cell framing overhead, which would be added before the cell-framing >calculation; this would allow adding the 8 bytes of PPPoE framing >and/or the 2 bytes of Ethernet VLAN tag, for people who want to get it >exactly right=2E =20 I fully endorse this plan! Whether these are simple, self-descriptive flags which >can be combined for the desired effect, or a numeric parameter which >must be set up, is open for discussion=2E If you look at the available tables for valid ATM per packet overh= eads you will notice them to be quite large, even though none of them inclu= des vlan tags=2E I want to argue that enumerating them to turn these into s= ymbolic flags is going to be the opposite of simple; hence I would argue fo= r a simple numeric parameter 'overhead'=2E Maybe default to your automatic = estimate unless 'overhead' is specified? > >All of this will help with setting cake=E2=80=99s shaper closer to, and >eventually perhaps *at* the physical link rate=2E The relative lack of >bursting from cake=E2=80=99s shaper already allows some of that, since it= =E2=80=99s no >longer necessary to allow the initial burst from the token bucket to >drain from the dumb FIFO downstream=2E With the correct link layer encapsulation values I ran my ATM link= with sqm-scripts shaped at 100% egress without induced latency (above the = expected), so if sqm scripts can do it so sure can cake :) Best Regards Sebastian > > - Jonathan Morton --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------ERP05DMWPMTBZT5WPY2CJHWPDA67NC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jonathan,
--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------ERP05DMWPMTBZT5WPY2CJHWPDA67NC--