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.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C1D6D3B2A0 for ; Thu, 2 Jun 2016 10:51:08 -0400 (EDT) Received: from [192.168.10.55] ([134.76.241.253]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZU7V-1auOO40NnJ-00LJ5W; Thu, 02 Jun 2016 16:51:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <2A84540D-AA30-4BD0-AF9A-5510EA00B7E8@gmail.com> Date: Thu, 2 Jun 2016 16:51:04 +0200 Cc: Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <574FFE52.1040501@darbyshire-bryant.me.uk> <2A84540D-AA30-4BD0-AF9A-5510EA00B7E8@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:68gCRrgbIPuixEWlejW0z6GHnEml8Yoh8CoscuwhIttOm6BEWRV P2oK6VId/iVZHtigbSG2kBgN9mBwji4Gb1uFh3YGxIQe6LivwYXJZ5jIeQ4+KcynbY0+CWk XIVQCGmfmedksCfkTE22IHWygX1LyzzAYcbcDlkBOEGFjhGCr8/qsFabDYWqYpjyli3s/mi hiEXMqr65zBMpKFVy1+SQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:u0vP2YufGiQ=:YPpLGRE9PsBz5RXjTyhmgp zKYIFSOpgIg1kAtori3QnCpogOiXrddKsJYr4s097Yx77Ybvw5bHkIWJaCitLZ45kqQLmdESc XihsgIqDtCg0UtgAev+naKa3NLqrdHLXG5wEbBZlZTM3tkgCM7H0kyTt7GHWQT9U6fyFWExDw X2O0RrFPhgqaT3cHCPF6GEtjIL/I9K414ofI0vfBc7vJWgpvWIpyNVXSOAkAXjyqUjK7GEaY2 31FsgAjEh476iIAtOybRvMITctXAa4iKkFRq6tRIto7ASCrC4RnG06er3oWKvKQRuMbKA7Go+ hu8Wm7wnygITW28/rfydC1GyghsM53jLPTetSTTt414mTf2rk++GcNekuWnv95ZeYgciivxR8 /RNm3ZXb2wqHSDeavTFq/5KEOWkvl8gI60ubba2++F27uz7S2uYaIMaYCDzlG4YXECxufN9YT 3DabvnRMQZlUE+wELcucaMPgKbb7kzn7xlEuAx0J8k9ZXQ0iQz5yG8QyEiyVETa2AYl4tRdVo VfRy8wVktDv0EGo2AMmm9mmlrdQn2G/c4EHLjGKfz3bSZpIJJlJGkXmOU82Jt7/XRiN6A+XRl 7Pe2CHDLs6K1ZrVgqFJW+Heh4a38aKEHoMiKt1WVgM7BlcqSg3dUIPwYJ7GGf1nLJtciaJOfA /4o8l3g5S4afleiyHrFBZkLIUAM8WYBGCA9uRykGZKB1XvizdmHT/GC72MHwIjRMBZC7T20o9 6FWrof3QatdVHp+4ZpkQ+qji03FgabfjhQN2H8dxEXzQy2Q0aE9qBkOh151djxisrvi9N2/t2 gavQudn Subject: Re: [Cake] cake/tc - removal of atm/ptm/ethernet specific overhead keywords 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: Thu, 02 Jun 2016 14:51:09 -0000 Hi Jonathan, > On Jun 2, 2016, at 16:22 , Jonathan Morton = wrote: >=20 >=20 >> On 2 Jun, 2016, at 12:37, Kevin Darbyshire-Bryant = wrote: >>=20 >> I'd be sort of interested to know if anyone is actually using those = keywords: ipoa-vcmux, ipoa-llcsnap, bridged-vcmux, bridged-llcsnap, = ppoa-vcmux, pppoa-llc, pppoe-vcmux, pppoe-llcsnap, pppoe-ptm, = bridged-ptm, via-ethernet, ether-phy, ether-all, ether-fcs, ether-vlan. >>=20 >> How many actually knew they even existed? >=20 > Since they are poorly documented, probably not many. But I=E2=80=99d = rather improve the documentation than delete them. My take is that if you write a comprehensive description of per packet = overhead that remains readable and interesting you would do a great = thing, But it would be too much for just being a section in the cake man = page.=20 >=20 > In principle, the existence and naming of these keywords is a = potential clue to the uninitiated user of the overhead feature=E2=80=99s = purpose. =20 In practice actual overheads are a) more complex than the = keywords implied and b) less invariant as one would hope (in that ISPs = change their composition without noticing their users). > The concept of protocol overhead affecting shader function is not an = obvious one outside of networking specialists; making users look up a = number in a cryptic table will simply result in nobody doing it at all. Making people pick potentially wrong values from a set of = (under-documented) keywords will have similar results. >=20 > Having shortcut keywords for this purpose in tc also helps to avoid = the trap of other UI layers doing their own (incomplete or inaccurate) = research on the correct compensation to apply. =20 Yeah, but this only is an improvement if the keywords are = complete and accurate, the last batch was not=E2=80=A6 > Currently LuCI is extremely clumsy at handling SQM configuration, and = the general quality of vendor firmware doesn=E2=80=99t give me = confidence. Thanks for the kind words ;). >=20 > I=E2=80=99ve just pushed an update which makes all the keywords = incremental, rather than some of them being absolute. Existing correct = examples of how to use these keywords remain correct. " This still does not fix the fact that it is quite unclear what = exactly =E2=80=9Cpppoe-llcsnap" should expand to, and whether = =E2=80=9Cpppoe-llcsnap vlan vlan=E2=80=9D really is that much user = friendlier than =E2=80=9Coverhead NN=E2=80=9D. >=20 > It would be nice if LuCI could infer information about the likely = overheads from the rest of the configuration, and apply (or suggest & = default) the correct keywords in sqm-scripts. That would make the = feature much more widely used. Yes, if reality was less complex life would be easier, I agree. = In reality ISPs are beginning to implement their own policers/shapers at = the BRAS/BNG level making the whole thing even more difficult, as at = that level the shapers sits on top of ethernet with an unknown = per-packet overhead that is difficult to measure remotely=E2=80=A6 Best Regards Sebastian >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake