From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B3DCA3B29E for ; Wed, 3 May 2017 04:24:36 -0400 (EDT) Received: from [172.17.3.29] ([134.76.241.253]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lxgt9-1e7r592uHD-017EQT; Wed, 03 May 2017 10:24:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: <1493796453297.40351@telenor.com> Date: Wed, 3 May 2017 10:24:31 +0200 Cc: me@lochnair.net, cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <1493397540.4184.959563328.3AB236CD@webmail.messagingengine.com> <1493721285271.28909@telenor.com> <1493727080.1510042.962956680.40220FCB@webmail.messagingengine.com> <1493789805885.56806@telenor.com> <647E5E04-C77A-426E-914A-88AE553F7B33@gmx.de> <1493796453297.40351@telenor.com> To: erik.taraldsen@telenor.com X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:VelpQjjxe15bm1NKqzJSskEwwrZU26zaWzxalnFrtGrf3hgH/Jm XiyKy5SMdno92EF+9NKYWVn9QSHHNUsEX8rR+KhDJS/npjIT0bhYjUxrY5Jt9Ma3Q+MwY2d vo4IpKxOJTvmc2/j1KWJdUU+pRGOJKuMw/u8FDMmt8ZeV+3Yoz2rvkm5rjuFFXCZTz8DsQd ze7zLs3IBtUyWBaHmLIbw== X-UI-Out-Filterresults: notjunk:1;V01:K0:pijGMcrpenM=:VrmNX6X46zbOs7xoqeUzAV SKEBGtNoNs7IFnD/2Sr5SjuDMAqFZuBbWdGLNnq7+OiwQStlwag/42YYEyVya7/7Gqzo/ICEY d7qNBNbRrWpuNhZrlNUSUhz2OuAGXAAWSL+Gaf8RsG9UxE/xK6PD0sUihLz8gxjvpsGHOnKoh DbDkGV3Fa9FtKraMqVWEr8gJVNgm6Mrvrlvpm4a8hgV0qWJ+v4/flILAktPkhPhJFSfhJ189X LpwLNex2iBSbDFUObAVy4gfqKo0ULxewOgqVWYpQH+aELh+DBXcXuTLhV04tGw0Fg2SiESnKc kl4XuiRLmxsCPJxNWHNi5PCXoMFpAWN9WDvUebdxkTRnCfj62R80VntlBoEAWgg9iTKUm9zuq JRIyjkYliNV5C3Gyy6YKNfjV8zT37jhEamYOYjH1B0Q+EICYzxpnAgILDv4trZZzZcmK0RyXs Sn3s/bZQoUPuXNT5kCy24PniUYQLT5budld0V1M370mI3i2+6ncUGZzfMtn+ZFB9Xd4s1VT3d v7wb8P96RCMklo0yB+Mo9E7nbOQq4GWgGX1tsDLZGOQVDI7SetMGU+Z+OGl8ETggABsOovhyO 4aoFSl8TZI2/GLe1klm4jEq4Y3HH9C9FOmC1jng/FZm4RA7jaH4OLtGlCrfYT41mbm+leRM/k LEIv260g2X+blm73rE5HWYo5iFpME9C9boIE3iF6dHLgnGfvFjRz0m0HIb8TDmdKx4h1vYv7P 2thuUDlTVD7hzC4tgfk6vmY/yuvI0UgIZCZrmydfq567IHOnwms/Xw2srzIse8OHlq78nmzOj zIrvShT Subject: Re: [Cake] Recomended HW to run cake and fq_codel? 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: Wed, 03 May 2017 08:24:37 -0000 Hi Erik, > On May 3, 2017, at 09:27, = wrote: >=20 >> Fra: Sebastian Moeller >>=20 >> Question: as an ISP what is your rationale to implement a = shaper at the BRAS? Simply the fact that=20 >> DSLAMs/MSANs are not capable to do it, or do you also need this to = make sure there is always room for > your own VoIP packets? >=20 > At least the DSLAMs we use are basically switches. Extremly limited = QoS/shaping. For a time we actually did not shape at the BRAS level and = let the DSLAM's just drop whatever it could not push throug. That was = not a success. It more or less behaved like a strictly policed access, = which is not something you want. So we went back to shaping at the = BRAS. Ah, thanks for the insight, I had always assumed the rationale = to be less obvious (like making VoIP more robust, keeping (D)DOS traffic = out of the aggregation network; I had never assumed that dslams might = simply be bad at traffic regulation ;) ) >=20 >=20 >=20 >> 0) get rid of all non-essential encapsulations, use DHCP option 82 = instead of PPPoE, rethink the need=20 >> for VLAN tags, >=20 > Done, with the exeption of some legacy business usages. This is quite enlightened, great! >=20 >=20 >> 1) make sure to properly account for all the quirks of ATM=E2=80=99s = AAL5 encapsulation (see cake=E2=80=99s=20 >> atm keyword or =E2=80=9Cman tc-stab=E2=80=9D) >=20 > Noted. All I ever learned about this topic should be summarized in = https://github.com/moeller0/ATM_overhead_detector/wiki . >=20 >> 2) preferably hoist your ADSL customers into the present and get your = device manufacturers=20 >> to implement PTM for adsl modems making 1) above much less involved = ;) >=20 > To much legacy, so more likely to migrate to VDSL across the board. Which effectively is the same for customers (except for unlucky = ones at the end of very long lines, I believe); ATM deserves to retire = ;) >=20 > Regarding BQL, we need the chipset vendors to do this. In particular = Broadcom. We do try and influence them to do this, but we simply are a = to small to get traction. Well, compared to most on this list you have a huge impact on = the chipset vendors, so I hope for the best. Is there anybode besides = Broadcom and Intel actually producing VDSL chipsets or is that the set = of vendors that need to be convinced? Best Regards Sebastian >=20 >=20 > -Erik