From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 D8C0C21F300 for ; Mon, 13 Apr 2015 07:45:59 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lfjxq-1Z9bVx0ini-00pME1; Mon, 13 Apr 2015 16:45:55 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <1D75F7D7-4EA1-47CB-8CA0-51144C58857E@gmail.com> Date: Mon, 13 Apr 2015 16:45:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <60B3F0CA-21B5-4E6E-B6F2-8BC679DE7558@gmx.de> References: <68E872EE-C0D3-4091-97C9-19596BF98AEB@gmail.com> <1D75F7D7-4EA1-47CB-8CA0-51144C58857E@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:HayX1IyJz3kMA2iG4qpu/rbZGruRo7bTWvzvKaWa5qXr+4M43tS o7JvhRHWVvH1IQSi2SciN56PWXpZcBLEJZ/wr4VxBrL5vVpbavWj5Jm95JOkFInyp5p0Ki6 hi5XgZLIScwWrvhogK4kpuFfMFPEdlh2z5J4AuLCBIrUBXcES0+J0pcXeNrtOqos3HVwW72 OFOa1/uWmtYiLF3W9Xt7w== 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 14:46:30 -0000 Hi Jonathan, On Apr 13, 2015, at 02:45 , Jonathan Morton = wrote: >=20 >> 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=85 >=20 > The other problem with stab is that the configuration is awfully = verbose - pretty much what I was trying to avoid with cake. =20 I agree, =93overhead" and "link layer" should be sufficient and = link layer can be turned into a simple =93atm=94 flag as you already = implemented. > I=92ll 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. I think your method is superior to the table as it will work for = any packet size, and will not require the user to either specify the = table sizing parameters or default to a crazy 64K table to cover GRO. >=20 > That=92s a recipe for people (and, more seriously, CPE vendors) = getting it wrong. Yes, simple wins here, but it needs to be complex enough to = actually cover the relevant use cases... >=20 > So cake just has that simple =93atm=94 flag, which adds roughly the = right amount of overhead for cell-framing already. =20 The cell framing with the last partly padded cell absolutely = requires the correct overhead (well too large an overhead will only cost = bandwidth) to work well, other wise the occasional packet will drag in = up to 47 bytes of unaccounted bandwidth use. > Any optimisations to that calculation (which are certainly possible) = are an internal matter and not for public consumption. There is no reliably way, that I n=3Dknow to quickly auto detect = the encapsulation overhead; I do have a rather crufty and slow method = that will take hours. >=20 > 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. =20 I fully endorse this, actually this =93overhead=94 parameter = should work independent of the =93atm=94 flag (on my VDSL link I have 16 = bytes overhead that needs accounting on top of the ethernet header). For = non-arm carriers getting the per-packet overhead wrong is not as = terrible, but it will make the shaper suck with small packets... > 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. Have a look at = http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ and = http://www.faqs.org/rfcs/rfc2684.html (neither of which deals with = potential VLAN tags between BRAS and Modem, that are =93invisible=94 to = packet captures as they never reach the endusers network, but still cost = bottleneck bandwidth); the whole encapsulation issue is a mess that will = most likely not lend it self to a small enumeration of encapsulations, = so I vote for a) defaulting to 44-14 bytes overhead (this is pretty much = the largest I have seen in the wild, but I have not seen much) and b) = allowing the user to override this with something along =93overhead 26=94 = that will completely replace the 44-14 bytes from above. So have a = reasonable default, but allow fine-tuning >=20 > All of this will help with setting cake=92s shaper closer to, and = eventually perhaps *at* the physical link rate. =20 Just a data point, when my link was still running ADSL2+ I = manged to get the egress shaping to work well at 100% of line rate = (around 2500 Kbps), so even sqm-scripts could reach that goal. (After = the switch to vdsl2 I learned the hard way that my ISP had implemented a = BRAS throttle that sort of mooted my attempts to reach 100% of the vdsl = line rate). > The relative lack of bursting from cake=92s shaper already allows some = of that, since it=92s no longer necessary to allow the initial burst = from the token bucket to drain from the dumb FIFO downstream. Interesting. Best Regards Sebastian >=20 > - Jonathan Morton >=20