From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vsmta12-2.nsc.no (vip22scan.telenor.net [148.123.15.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B0F343B2A4 for ; Wed, 3 May 2017 07:10:18 -0400 (EDT) Received: from [153.110.251.167] ([153.110.251.167:50804] helo=ilp-smtp01.man.cosng.net) by vsmta12-2.nsc.no (envelope-from ) (ecelerity 3.6.22.53981 r(Core:3.6.22.0)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id F9/A9-06970-89AB9095; Wed, 03 May 2017 13:10:16 +0200 Received: from TNS-SKO-24-200.corp.telenor.no (TNS-SKO-24-200.corp.telenor.no [10.179.59.68]) by ilp-smtp01.man.cosng.net (Postfix) with ESMTP id BE147200A7; Wed, 3 May 2017 13:10:16 +0200 (CEST) Received: from TNS-SKO-24-208.corp.telenor.no (10.179.59.76) by TNS-SKO-24-200.corp.telenor.no (10.179.59.68) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 3 May 2017 13:10:16 +0200 Received: from TNS-SKO-24-208.corp.telenor.no ([fe80::b024:7a41:ba33:25b6]) by TNS-SKO-24-208.corp.telenor.no ([fe80::b024:7a41:ba33:25b6%12]) with mapi id 15.00.1178.000; Wed, 3 May 2017 13:10:16 +0200 From: To: CC: Thread-Topic: [Cake] Recomended HW to run cake and fq_codel? Thread-Index: AQHSw3QWlLDEM2lQwEWHw0Bwy0PLuKHiGDmL///5fQCAAGDO9g== Date: Wed, 3 May 2017 11:10:16 +0000 Message-ID: <1493809816975.62837@telenor.com> References: <7B914FA7-38A6-4113-9B2C-D6246873676A@gmail.com> <1493791193941.83458@telenor.com>, In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: nb-NO X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.181.50.8] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SCAN_VERDICT: inbox 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 11:10:18 -0000 > Fra: Pete Heist =0A= >=0A= > Another option for ISPs (failing AQM support in the devices, and instead = of deploying devices on the customer =0A= > side), could be to provide each customer a queue that=92s tuned to their = link rate. There could be an HTB tree =0A= > with classes for each customer and Cake at the leafs. Knowing each custom= er=92s link rate (assuming it=92s not =0A= > variable) you=92d set HTB=92s rate to something less than that. There wou= ld be work to do as each customer is =0A= > added and removed, but at least it would be transparent to them. AQM is b= est done at egress where packets =0A= > originate, so I=92m not sure how well it would work in practice.=0A= =0A= We are limited by what the HW can do here. The Juniper ERX's we use aggreg= ate multiple 10.000's of users. So Queue handeling must be supported in s= ilicone. We do have a queue pr customer, but we cant support HTB.=0A= =0A= =0A= > What=92s usually used for an ADSL provider=92s backhaul, fiber?=0A= =0A= I'm not sure what our competition use, but we mainly use fiber. There are = some edge cases using alternative backhaul such as radio. Norway has chall= enging topology for infrastructure, so some will have to suffer unfortunate= ly. :) =0A= =0A= =0A= =0A= -Erik=0A=