From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F17023CB39 for ; Thu, 11 Apr 2019 06:38:55 -0400 (EDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5AA14AF; Thu, 11 Apr 2019 12:38:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554979134; bh=uqNLxK72wZsJOUcsCTVZC9wpPDByotb97DUGHoBTAK0=; h=Date:From:To:Subject:From; b=Xn2SmxgokOXFPI8uzxz9xjxVpdv9a+V15hi9QUmEYjGgX1R3hOGiiiOg4ILvayJGr mV/wSQb3n8JK1mCInz+CVXh8Gwa0+fXdye1774deBTL9/+/nuCdTfiWiwepggqzEh1 TRubOes8QSleO9wEAbaMLe0WS4zW+sUU8q/Yna9s= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 587A69F for ; Thu, 11 Apr 2019 12:38:54 +0200 (CEST) Date: Thu, 11 Apr 2019 12:38:54 +0200 (CEST) From: Mikael Abrahamsson To: bloat@lists.bufferbloat.net Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-509021088-1554979134=:3490" Subject: [Bloat] datapoint from one vendor regarding bloat 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: Thu, 11 Apr 2019 10:38:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-509021088-1554979134=:3490 Content-Type: text/plain; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hi, I talked to Nokia (former Alcatel/Lucent equipment) regarding their typical buffer settings on BNG. I thought their answer might be relevant as a data point for people to have when they do testing: https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/3HE13300AAAATQZZA01_V1_Advanced%20Configuration%20Guide%20for%207450%20ESS%207750%20SR%20and%207950%20XRS%20for%20Releases%20up%20to%2014.0.R7%20-%20Part%20II.pdf "mbs and cbs — The mbs defines the MBS for the PIR bucket and the cbs defines the CBS for the CIR bucket, both can be configured in bytes or kilobytes. Note that the PIR MBS applies to high burst priority packets (these are packets whose classification match criteria is configured with priority high at the ingress and are in-profile packets at the egress). Range: mbs=0 to 4194304 bytes; cbs=0 to 4194304 bytes Note: mbs=0 prevents any traffic from being forwarded. Default: mbs=10ms of traffic or 64KB if PIR=max; cbs=10ms of traffic or 64KB if CIR=max" So the default setting is that they have a 10ms buffer and if a packet is trying to be inserted into this buffer and it's 10ms full, then that packet will instead be dropped. They claimed most of their customers (ISPs) just went with this setting and didn't change it. Do we have a way to test this kind of setting from the outside, for instance by sending a large chunk of data at wirespeed and then checking the characteristics of the buffering/drop for this burst of packets at receive side? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-509021088-1554979134=:3490--