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 CAC523CB3B for ; Thu, 11 Apr 2019 08:45:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1554986722; bh=5xmRbnt+ECJLay+HBQ/qBOlhJYXv/Qk51+xdqvj7CVo=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:From; b=DPAWWX68XnsTlUGBOvI2vopO7OumUkisF6v4dK1srhxZBhhf021qfcpSXj2ehUQmu q4YHVt1CD3kXWZWWbldBh2joE5S5UZ+dic0yrbYpfPczvcViAnUARoeC5n8vpwgf07 P8A5DtCcvi31TDT+I5cfl5GLC8pyAdKIztJtt3LU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.18.225.17] ([80.187.115.181]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Ld1CS-1gWfbe136e-00iF2t; Thu, 11 Apr 2019 14:45:22 +0200 Date: Thu, 11 Apr 2019 14:45:19 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----T75KQVIOA1QL7UV5LZHJAO7CN9P7LW" Content-Transfer-Encoding: 7bit To: bloat@lists.bufferbloat.net,Mikael Abrahamsson From: Sebastian Moeller Message-ID: <6C67CA63-A06F-4D39-BD87-60D7DE7D79DA@gmx.de> X-Provags-ID: V03:K1:gwu8nCbDsOacDRpbq0u8ApNWJmBx/Sgyv/NYVz2Lc/8I3O2uQAo Ce29y1v+Ukf1yrfhFhxTKg6D6fCK9Ht0CAn6gbuoHR7dCuC3ttfmQcBzYBXwU0nUgPl5dX7 z10XLlzolheCwDBsYXAOiKsLr9WdLhs8Fa09/JmpI1MMRhssBoxb1TdhZGz5t3wmApH6KbG f8a2aN8iXHUOoG6NM5tXQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:OruHNX7fKY4=:GM3VDSb6zQv3kP/W9DNxEu IN0Cmp/bm4E0SvQTjSXo8xHEi9UT0tb+PmrpBQGuN0Nuvfvdv0h3jTDRne+uWFyilPwatY5Vr b6ofkTd18z78IBBKruVLShbvmIkzlaokDl2NV6PZGduEMphQnIYs22mQYTLSUhlO4i1NfB5B3 jedgajK4rk4iUnBshjnPSwhjef7Nb3t6tTw9eNNKvdQun+g3+xOHVi1C6FY9mb6b5k8jekAYy FuzdzDepsIapgkRUq/7SZVuk59k7D/LDAj42yZzdg3E6BRleg+wGGRfi0A+MrikEVULa/ptXB 28ua0VNxhY9I1Z4XccRWxjU9jdfHgqPmnqZ7OwLmb0ixxplcCh3gJvVz+1q5CdYh/R3xU7Qe7 g6rMnFpFP17+KgczhJyLszgiPMrtlDUZqs7HQmaU+3e4v2twvSZ8RAouorP6E2knYOXJhKDye BaprqiIqywGbMmDLolt4TGyGm94NNjhPMCxESFtT92C417ZrfF8AzaLc+MeY+DBrB+p4FXOum EUNgwIaO8z7o0qF9zAro6kZvPoOJEHWPqzeEzFjldsDZLiyMXNV1oSpu1kjJmRLg4TqCWnUr+ /AZ5wZnVxz9Bban5OgdUh3Eb9QyzLScCw5nMZlRV+H2NuM8v3sFmRXhXLOx42ELcKv3vBajQ1 jlcM6yp5gBok571zUwX4b3mqEZ2TTyOOkiwgPiTBFVDNugad6cEgY9lXbgV1lbPgpAUXbsvdX 3RButlm8AbvvWfMS8IImiDWrxPsGhfeYQGpGecepZMlaMSfH4wuD3MU4UyL8BeBAFsC5MHPRp qweGRKMR+aq+Ig++jTTHUAPB4JgU7uR6s9dBrUBjrVgcec6jczHOQ8h8I8f4sqJtgGLd6weyE x3Yjr8Jr5ckMz3WztFgPc4D1UFx5DGz08KuPc6bK6JKABLtJL0BiMu2fV31MbbtA79f00EVhM HzZeut3awYg== 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 12:45:25 -0000 ------T75KQVIOA1QL7UV5LZHJAO7CN9P7LW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Interesting! Thanks for sharing=2E I wonder what the netalyzr buffertest wo= uld 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=2Ecg= i/3HE13300AAAATQZZA01_V1_Advanced%20Configuration%20Guide%20for%207450%20ES= S%207750%20SR%20and%207950%20XRS%20for%20Releases%20up%20to%2014=2E0=2ER7%2= 0-%20Part%20II=2Epdf > >"mbs and cbs =E2=80=94 The mbs defines the MBS for the PIR bucket and the= cbs=20 >defines the CBS for the CIR bucket, both can be configured in bytes or=20 >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 64K= B >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=20 >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 ------T75KQVIOA1QL7UV5LZHJAO7CN9P7LW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Interesting! Thanks for sharing=2E I wonder what t= he netalyzr buffertest would report for these?

Best Regards
= Sebastian

On April 11, 2019 12:38:54 P= M GMT+02:00, Mikael Abrahamsson <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?
<= br>--
Sent from my Android device with K-9 Mail=2E Please excuse my bre= vity=2E ------T75KQVIOA1QL7UV5LZHJAO7CN9P7LW--