From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 B77CB21F2E7 for ; Tue, 14 Apr 2015 03:34:17 -0700 (PDT) Received: from hms-beagle.lan ([134.2.89.70]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LqQTl-1ZLilw1jKD-00e6pK; Tue, 14 Apr 2015 12:34:13 +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: <23954505-84F7-4708-9EAD-4233B2DEFE81@gmail.com> Date: Tue, 14 Apr 2015 12:34:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4DB49702-F260-4841-8E1A-27D824C14A7E@gmx.de> References: <68E872EE-C0D3-4091-97C9-19596BF98AEB@gmail.com> <1D75F7D7-4EA1-47CB-8CA0-51144C58857E@gmail.com> <60B3F0CA-21B5-4E6E-B6F2-8BC679DE7558@gmx.de> <23954505-84F7-4708-9EAD-4233B2DEFE81@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:YqBscL4ZHxJd//2dLSyFTLAUS2gwkpAgS8jKkkeXaPMtKWjHC93 JUJkdkxmEonCaYtV9jXSV3EoBQAyCggtPP8uh9nvURIaiGQQx//K3UXMKNdE03dkcV/xvcK gfRk9IT46+jZEgFptzMyhUgGEdJd77+RiXJzomkciTNOkrdw4OLYslo+hdm0Lo5QIR/iKG2 SF/tD04gLJwNfQ15z4KCQ== 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: Tue, 14 Apr 2015 10:34:46 -0000 Hi Jonathan, On Apr 14, 2015, at 12:13 , Jonathan Morton = wrote: >=20 >> On 13 Apr, 2015, at 17:45, Sebastian Moeller wrote: >>=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 >>=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-atm carriers getting the per-packet overhead wrong is not as = terrible, but it will make the shaper suck with small packets=85 >=20 > Well yes, that=92s what I meant by =93orthogonal=94. Ah, good. >=20 >>> 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. >>=20 >> 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 >=20 > What I propose is that I add a numeric overhead parameter to cake=92s = configuration API, and then in iproute2 I can provide keywords as a more = user-friendly way of specifying the common cases, as well as offering = direct access to the numeric. So specifying =93pppoa vcmux=94 would be = shorthand for =93atm overhead 10=94, This is going to be challenging to keep it simple, as we still = need to think about what the kernel does on ethernet interfaces (it = accounts for the ethernet header) so for PPPoE, LLC/SNAP, RFC-2684 you = already need 3 flags plus a flag for ethernet header (which h the kernel = does account for on ethernet devices but not on true ATM devices even if = an ethernet header is used on the wire). Also most users do not really = know or have a reliable way to figure out the encapsulation used (short = of the slow empiric way I have been pushing for some time). But as long = as there is a way to specify the overhead numerically, having a nicer = symbolic way is not going to hurt. > =93vdsl=94 would be shorthand for =93noatm overhead 16=94, But, that is only true for my link including PPPoE and VLAN = overhead, vdsl2 only drags in an additional 5 bytes: VDSL (IEEE 802.3-2012 61.3 relevant for VDSL2): 2 Byte PPP + 6 Byte = PPPoE + 4 Byte VLAN + 1 Byte Start of Frame (S), 1 Byte End of Frame = (Ck), 2 Byte TC-CRC (PTM-FCS), =3D 16 Byte Also I am uncertain whether vdsl2 transmits the ethernet frame = check sequence or not=85 (and unlike with the ATM carrier I have no idea = how to measure the actual per packet overhead=85) In my case this really does not matter though, as the BRAS throttle = accounts for 16 bytes (dual VLAN tags) so that is the value I need to = shape for=85 > and =93raw=94 would allow reverting to an unadjusted configuration, = ie. =93noatm overhead 0=94. I like raw as simple way to clear all the individual symbolic = constants ;) > And it=92s easy to retrospectively refine the behaviour of those = keywords, because they=92re in userspace. Is it simlper to get a patch into iproute2 than the kernel? and = are the iproute2 maintainers open to redefinition of symbolic values? Best Regards Sebastian >=20 > - Jonathan Morton >=20