From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from tn-mailgw-04.telenor.no (tn-mailgw-04.telenor.no [153.110.76.7]) (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 66F9C3B29D for ; Mon, 23 Nov 2020 07:57:03 -0500 (EST) IronPort-SDR: QklxH9qP2H0JsEQKF0OLoHBKU/cFuYCDXwtyTPQaXUsdr1MRwDqY7Mb6RhpXZoFmKZ7RgW0jZR 6fZ5un65CmpcgshdFG1HK79gWUCGkaqahYHNQFT4FDaMz0bwjtHpEXfWEewoDaG6TzMSb036vO fR5o381FGDa+1TGr1OAOeN9daqzrjKrD5Tr1sCx3UV64x0tYNVZj2/0rGYnTsLoEQGCEVCkIsx gPJtZ4naoyspn9/B2vjBoZwrJPlhCycCqGicWFFyGJrElraxeNrz1phz3WoYEcu2QSeE7iwj5e +vA= X-IronPort-AV: E=Sophos;i="5.78,363,1599523200"; d="scan'208";a="77830340" Received: from tns-sko-24-207.corp.telenor.no ([10.179.59.75]) by tn-mailgw-04.corp.telenor.no with ESMTP; 23 Nov 2020 12:58:11 +0000 Received: from TNS-SKO-24-208.corp.telenor.no (10.179.59.76) by TNS-SKO-24-207.corp.telenor.no (10.179.59.75) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Nov 2020 13:57:00 +0100 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.1497.008; Mon, 23 Nov 2020 13:57:00 +0100 From: To: , CC: , , , , , Thread-Topic: [Bloat] BBR implementations, knobs to turn? Thread-Index: AQHWvCk4fuZ0GUZeA0yszB3/rex4WqnLMe2AgACyr3iAAHkbAIACs0jKgABWrYCAAB2cvoABTSKAgAAZzICABMO78g== Date: Mon, 23 Nov 2020 12:57:00 +0000 Message-ID: <1606136220411.40216@telenor.com> References: <1605540351240.98589@telenor.com> <1605607524611.20916@telenor.com> <20201117160744.395f108e@carbon> <1605772623976.41134@telenor.com> <1605796526806.72220@telenor.com> <20201120121027.2a61b319@carbon>,<877dqgrygo.fsf@toke.dk> In-Reply-To: <877dqgrygo.fsf@toke.dk> 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.9] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Bloat] BBR implementations, knobs to turn? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 12:57:03 -0000 ________________________________________=0A= Fra: Toke H=F8iland-J=F8rgensen =0A= =0A= > > I really appreciate that you are reaching out to the bufferbloat commun= ity=0A= > > for this real-life 5G mobile testing. Lets all help out Erik.=0A= >=0A= > Yes! FYI, I've been communicating off-list with Erik for quite some=0A= > time, he's doing great work but fighting the usual up-hill battle to get= =0A= > others to recognise the issues; so +1, let's give him all the help we=0A= > can :)=0A= =0A= Thanks! I'll need all the patting on the back which can be provided. :)=0A= =0A= =0A= > > From your graphs, it does look like you are measuring latency=0A= > > under-load, e.g. while the curl download/upload is running. This is=0A= > > great as this is the first rule of bufferbloat measuring :-) (and Luca= =0A= > > hinted to this)=0A= =0A= I've been using Flent since day one of the Fixed Wireless project. In fact= =0A= it was an part of the CPE RFQ process that all participating vendors must = =0A= deliver test results from Flent as a part of the technical response. Not s= o much=0A= that we should save ourselves the work of testing. But to force the vendor= s=0A= to see how their equipment handle latency. Trying to establish Flent as a = =0A= standard part of their test suit.=0A= =0A= Toke and Dave has been of great help both in helping me in interpreting=0A= Flent results, and moral support as it can be an up hill battle to achieve = =0A= awareness of the bufferbloat issues.=0A= =0A= =0A= > > The Huawei policer/shaper sounds scary. And 1000 packets deep queue=0A= > > also sound like a recipe for bufferbloat. I would of-cause like to=0A= > > re-write the Huawei policer/shaper with the knowledge and techniques we= =0A= > > know from our bufferbloat work in the Linux Kernel. (If only I knew=0A= > > someone that coded on 5G solutions that could implement this on their= =0A= > > hardware solution, and provide a better product Cc. Carlo)=0A= =0A= I have tried on several occasions to get the vendors to subscribe to this= =0A= mailing list. And individuals here have been willing to do consulting=0A= work for vendors in Telenors RFQ, but as far as I know they have not=0A= been contacted.=0A= =0A= =0A= > Your other points about bloated queues etc, are spot on. Ideally, we=0A= > could get operators to fix their gear, but working around the issues=0A= > like Erik is doing can work in the meantime. And it's great to see that= =0A= > it seems like Telenor is starting to roll this out; as far as I can tell= =0A= > that has taken quite a bit of advocacy from Erik's side to get there! :)= =0A= =0A= As you say Toke, I have had some success. In particular with Huawei=0A= on the base station side I believe we will have the largest impact.=0A= =0A= The CPE side has met willingness to investigate these issues from early=0A= on, but it seems that buffer handling is much harder on CPE chipsets =0A= than on base station chipsets. In particular on 5G. We have had some =0A= very good results on 4G, but they do not translate to 5G.=0A= =0A= =0A= -Erik=