From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 E6F913CB3B for ; Thu, 11 Apr 2019 13:34:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1555004041; bh=JgOt9kgMPIZeA+xtj1vRzxZ41vEIzWprjTTZwXdtSek=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:From; b=lRPQU+jM5MFfZ8ZeiHefmZ8lzYiQ3FSWHrkxvZgHbyDuYFTJEvwDhWTm3wRv/psg1 qeKx9LxtfT4oxQhBClqFJrjQeMSilZdPfW3WTAS9zhOAvP1555MdpQ2U3rGf6CuscN 0LZ9AnDY1zQkp+OqeqaUe6PLbmzLEPvCwfatoPfk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.18.225.17] ([80.187.115.181]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lh7M3-1gZChy1nb5-00oWl5; Thu, 11 Apr 2019 19:34:01 +0200 Date: Thu, 11 Apr 2019 19:33:56 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <6C67CA63-A06F-4D39-BD87-60D7DE7D79DA@gmx.de> References: <6C67CA63-A06F-4D39-BD87-60D7DE7D79DA@gmx.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----M49S9JNBY3BC1PTOKNA6M6Q8FZU1RA" Content-Transfer-Encoding: 7bit To: bloat@lists.bufferbloat.net,Mikael Abrahamsson From: Sebastian Moeller Message-ID: <7FACD20C-7431-4025-B5B6-1248B59F8EA5@gmx.de> X-Provags-ID: V03:K1:q/OdP8f12L9+5566yZL/HI8JVv0ykYtlrmGGhY9/Py8cFM02flG wNakUbdex1Uw8non9UDLapagxJ3XZYniBh21PwKIPBU+9jikBX40zij3744//ZtFzB2g0q1 kWnYUhPOHerRfSNnC//lc5ULTwztEFfEMiKyqczuuZo732T6HtAPd89yOWtq5svCE7/C6yK HokI6rOX4IGoyofYoSaTw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:0Y69kdkOrSc=:Jxc8w8MNhTpqDOS2Wg4RiM D414Capk6xMeBIUVgN9Ii8EvDRrnBa5ueKlzdL+vpB98iIZcj7GNNgREjEhcrMcf3cT57lpMa O+8uWXMRfwiERMjjg7ey0p0etF4NSH2eF7vay0381qyqb960felnPEHRFuAFzjSuM0QYHPhrL sgEAAEWjSTGakxBC9bXD4D3Ifq5rvcRA5PgdF4H57sVFFsUO725ybPMJX3IrLUx45iAiA39Ue SjNnt/f1CLvhmfRfqf2NTWUJXUUIDpS8va0w2kNWZpHTufLUpBKS3IZARXuvLjrfjtcI+K+ex PyerFp2ZUCRH2IRPTLOtFezxffK9lv9mFrkjFK+Y9R5x9ACnQOb6KvpIAOSMPFu1de+WgM4Mj XJxLu3LzsiN+D4A0mBMoS91Im8/ZQ4tJVm/iFiLnhviI/d2QP6NXmSSTc5SPnc97rLrvlCnmz acoZOSXDvMvJv9TiNn8uF6UR6sh0S+LE9jPyCEAYYEJfAvajNjZTwJDqzXE3Ri1aHjqoQhQKH tA9/5f4GqkESWIH9CX4ZD5IZ+sGspqoIqEMhxe2KSXpttrirsK3IjJk25i2fPyOolHeFN/aMC 9dyrSsBVCk+NPb2m0brqHcR7SC3X2uxWe2uUsHNyIEjKi0qhEPu+e81ra/W/Uon/pLHbr4fsn SAxWMxQeqeUGRviFgkRRG0lbBBqh0tYCSGl/AWDn3/nNqMlhZU0vgprRO4ICjwxXlbU/x2YbN cMvw2egShZ+mZN3LK86IOx36Ch+HX8+rWUOp09fqwXoAHqgm34liRyHowTK9cdbbFjphnFLR0 tho/boO2d2waf+t65/1KvFA8cWxnEDMl+TH+CH+Fbe73MlmmTPwcyiZVi9f37Ud87TsMz4f8m PVFKBnqz7XUylCyTEjxmXn2pXehJd2U0oRwMWhpVwbiVNTG7n45fPkyrqa8JvdojqI+IyD+mF QerSoFAEiVw== Subject: Re: [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 17:34:04 -0000 ------M49S9JNBY3BC1PTOKNA6M6Q8FZU1RA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I just noticed netalyzr shut down last month=2E=2E=2E=2E On April 11, 2019 2:45:19 PM GMT+02:00, Sebastian Moeller wrote: >Interesting! Thanks for sharing=2E I wonder what the netalyzr buffertest >would report for these? > >Best Regards > Sebastian > >On April 11, 2019 12:38:54 PM GMT+02:00, Mikael Abrahamsson > wrote: >> >>Hi, >> >>I talked to Nokia (former Alcatel/Lucent equipment) regarding their=20 >>typical buffer settings on BNG=2E I thought their answer might be >>relevant=20 >>as a data point for people to have when they do testing: >> >>https://infoproducts=2Ealcatel-lucent=2Ecom/cgi-bin/dbaccessfilename=2Ec= gi/3HE13300AAAATQZZA01_V1_Advanced%20Configuration%20Guide%20for%207450%20E= SS%207750%20SR%20and%207950%20XRS%20for%20Releases%20up%20to%2014=2E0=2ER7%= 20-%20Part%20II=2Epdf >> >>"mbs and cbs =E2=80=94 The mbs defines the MBS for the PIR bucket and th= e cbs=20 >>defines the CBS for the CIR bucket, both can be configured in bytes or > >>kilobytes=2E Note that the PIR MBS applies to high burst priority >packets >> >>(these are packets whose classification match criteria is configured >>with=20 >>priority high at the ingress and are in-profile packets at the >egress)=2E >> >>Range: mbs=3D0 to 4194304 bytes; cbs=3D0 to 4194304 bytes Note: mbs=3D0 >>prevents=20 >>any traffic from being forwarded=2E Default: mbs=3D10ms of traffic or 64= KB >>if=20 >>PIR=3Dmax; cbs=3D10ms of traffic or 64KB if CIR=3Dmax" >> >>So the default setting is that they have a 10ms buffer and if a packet >>is=20 >>trying to be inserted into this buffer and it's 10ms full, then that=20 >>packet will instead be dropped=2E >> >>They claimed most of their customers (ISPs) just went with this >setting >> >>and didn't change it=2E >> >>Do we have a way to test this kind of setting from the outside, for=20 >>instance by sending a large chunk of data at wirespeed and then >>checking=20 >>the characteristics of the buffering/drop for this burst of packets at > >>receive side? >> >>--=20 >>Mikael Abrahamsson email: swmike@swm=2Epp=2Ese > >--=20 >Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------M49S9JNBY3BC1PTOKNA6M6Q8FZU1RA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I just noticed netalyzr shut down last month=2E=2E= =2E=2E

On April 11, 2019 2:45:19 PM GMT+0= 2:00, Sebastian Moeller <moeller0@gmx=2Ede> wrote:
Interesting! Thanks for sharing=2E I wonder what the netalyzr buffertest w= ould report for these?

Best Regards
Sebastian

On April 11, 2019 12:38:54 PM GMT+02:00, Mikael Abra= hamsson <swmike@swm=2Epp=2Ese> wrote:

Hi,

I talked to Nokia (former Alcatel/Luc=
ent equipment) regarding their 
typical buffer settings on BNG=2E I thou=
ght their answer might be relevant 
as a data point for people to have w=
hen they do testing:

https://infoprod=
ucts=2Ealcatel-lucent=2Ecom/cgi-bin/dbaccessfilename=2Ecgi/3HE13300AAAATQZZ=
A01_V1_Advanced%20Configuration%20Guide%20for%207450%20ESS%207750%20SR%20an=
d%207950%20XRS%20for%20Releases%20up%20to%2014=2E0=2ER7%20-%20Part%20II=2Ep=
df

"mbs and cbs =E2=80=94 The mbs defines the MBS for the PIR bu=
cket and the cbs 
defines the CBS for the CIR bucket, both can be config=
ured in bytes or 
kilobytes=2E Note that the PIR MBS applies to high bur=
st priority packets 
(these are packets whose classification match crite=
ria is configured with 
priority high at the ingress and are in-profile =
packets at the egress)=2E 
Range: mbs=3D0 to 4194304 bytes; cbs=3D0 to 4=
194304 bytes Note: mbs=3D0 prevents 
any traffic from being forwarded=2E=
 Default: mbs=3D10ms of traffic or 64KB if 
PIR=3Dmax; cbs=3D10ms of tra=
ffic or 64KB if CIR=3Dmax"

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=2E
They claimed most of their customers (ISPs) just went with this setting and didn't change it=2E

Do we have a way to test this kind of sett=
ing from the outside, for 
instance by sending a large chunk of data at =
wirespeed and then checking 
the characteristics of the buffering/drop f=
or this burst of packets at 
receive side?
<= /blockquote>
--
Sent from my Android device with K-9 Mail=2E P= lease excuse my brevity=2E ------M49S9JNBY3BC1PTOKNA6M6Q8FZU1RA--