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 8BBFC3B2A0 for ; Thu, 2 Jun 2016 11:33:26 -0400 (EDT) Received: from [172.17.3.79] ([134.76.241.253]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MbKXI-1arvfz1PrI-00ImrS; Thu, 02 Jun 2016 17:33:23 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <1A507BE4-35F2-4B09-98C8-915D15EAA641@gmail.com> Date: Thu, 2 Jun 2016 17:33:21 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , 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> <87a8j3fyxc.fsf@toke.dk> <7E9009E9-DB53-4B0E-90F5-5DC3171BEC89@gmx.de> <1A507BE4-35F2-4B09-98C8-915D15EAA641@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:wQmB6+aOEIK6RWxZvU0XHbEqxuzJjIlIFQjn+6124XvJvOALAv+ 8GtCDhqLpMtyZLxXMq5U0jWRuwW2mFxfR28O84ByqvqUowXKiCo1hKA5TFtOohh3xvOsT5u ltDZfkHBc8PyA44e/v68V7y1lc7PfwTHrdujCpyaQOKeJm0Bk36DC5gSkIg78sVmL3ec9gL y6X6di+EQ2BEhMBxtpigA== X-UI-Out-Filterresults: notjunk:1;V01:K0:/wh0CjG1p40=:rweT13I2Zyr8pZ10C6eu4a pkQgpBJ9L2ClSePC9vlVg7lsG4fd1PvS4j8/H71R1Z7BbpN7t0Fc5s/sJPGUF/6ses2B4uvAr TUUyPgX2pei9GQ8/t+XyWNrwCJyyEazzD8twQ3EFXcpCyz3mAg7Grc1MQCO8zmhgn7pCm4KX3 nWjoNNXC3PTqM4iVriRZfHnHEa477b5zh+oGBJc8cMT5ZyKLrowi4OBSvqMcTCdbGdh9K6pqk rtt2zB+lxeRlnAi84Sj3Ftf3lrD8skOWbHG5+uucaDIv/T01O6SrV/Jsiya+0M3KYkGLQL45b /+g/zOvTvRdjHzQFMMSrCcV6GVGgLWC86yDhcHK11Ha29i2CAwltD8eENxVqfm/9J6TdYp7RI Kz3J7XAFMIva/hcHSpFhugDfias3MsAhnhtis28gkhV+50icOXLIqF10WSngm0xaDjzQWAnP7 QLmXukF5CtA/x/5lKWJk+qxlzdBqtP0ZM4+pRXO+Oks0PX14yw20RgySIWqXXRxcpBWeG/ycW pcnrcMe7Lf27TdJDffftWvtKyu1BBbMuzuNtOTKxE0LZkUQILtv9YzSA2O0JcIQrhyiHk/Pe6 dUh2Vng0gHa6TKnQ5LlhYOz9ZoRI0gy8KCkr0+1qKqGrbCherrfq/XvL2KjXlK0ZbVBO9GvQj orz6MORNvHJDvzCzagO/ccU5r8VnYfiXVSuvTaME9GDNqko2k90qJ2KeYNZndOs2ndV+vHiW4 W/eOZYMjf4uygnTh2FbVzZ2XMGoD/fRxxRCDWznMbNYfCsI9QWCyeGp9rtUHy263n2n1xd3JA my2ZpTP 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 15:33:26 -0000 Hi Jonathan, > On Jun 2, 2016, at 17:10 , Jonathan Morton = wrote: >=20 >=20 >> On 2 Jun, 2016, at 17:59, moeller0 wrote: >>=20 >> As I tried to convey before the matter is far from simple. For = example my ISP, DTAG, has at least 4 different sets of per packet = overhead (ATM versus PTM, BRAS versus BNG) so even for this one ISP = there is not one solution to the issue. And with BRAS/BNG shaping as = used by say DTAG the actual VDLS2 related overhead becomes irrelevant = compared to the overhead setting of that applied policer. I believe = trying to simplify this complexity will lead to false overhead = recommendations. I would rather direct people to better documentation = how to deduce the overhead by measurements and research=E2=80=A6 >=20 > I think we can make a couple of usefully simplifying assumptions: >=20 > 1: The encapsulation overhead on the wire is the same in both = directions. That seems reasonable. >=20 > 2: The BRAS is irrelevant, because we need to set an ingress qdisc = below the line rate anyway in order to exert control, and the BRAS = doesn=E2=80=99t apply on upload. Not at all, either the BRAS shaper is set above the XDSL link = capacity (in which case it does not matter) or it is set below link = capacity and then ONLY the BRAS shaper matters. As an example DTAG = changed their DSLAMs/MSANs to alway sync as high as possible, so my = Modem syncs at 109/38Mbps, but I have 50/10Mbps plan, all the shaping is = happening at the BNG/BRAS, the parameters of the VDSL2 links do not = matter at all anymore. It seems that the BNG shaper effectively limits = the brutto rate and then they use dual-VLAN tags and the pppoe overhead, = so that the shapers overhead in practice is equal to the PTM link=E2=80=99= s. But even if the would not account for any overhead the difference = between 50 and 100 is large enough to make the real VDSL2 overhead = irrelevant. At least for DTAG=E2=80=99s BNG rollout the shaping/policing = happens in the BNG both for upstream and downstream. I believe this illustrates why we should not try to sugarcoat = this complexity. Instead of telling the user our best guess of his/her = specific overhead, we would do them a greater service by explaining how = to actually measure their overhead=E2=80=A6 Best Regards Sebastian >=20 > Does that help at all? >=20 > - Jonathan Morton >=20