From: Sebastian Moeller <moeller0@gmx.de>
To: bloat@lists.bufferbloat.net,Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: [Bloat] datapoint from one vendor regarding bloat
Date: Thu, 11 Apr 2019 14:45:19 +0200 [thread overview]
Message-ID: <6C67CA63-A06F-4D39-BD87-60D7DE7D79DA@gmx.de> (raw)
In-Reply-To: <alpine.DEB.2.20.1904111234410.3490@uplift.swm.pp.se>
[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]
Interesting! Thanks for sharing. 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 <swmike@swm.pp.se> wrote:
>
>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
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[-- Attachment #2: Type: text/html, Size: 2396 bytes --]
next prev parent reply other threads:[~2019-04-11 12:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 10:38 Mikael Abrahamsson
2019-04-11 12:45 ` Sebastian Moeller [this message]
2019-04-11 17:33 ` Sebastian Moeller
2019-04-11 17:54 ` Jonathan Morton
2019-04-11 18:00 ` Holland, Jake
2019-04-11 18:28 ` Jonathan Morton
2019-04-11 23:56 ` Holland, Jake
2019-04-12 0:37 ` Jonathan Morton
2019-04-12 0:45 ` Holland, Jake
2019-04-12 9:47 ` Mikael Abrahamsson
2019-04-11 18:02 ` Jan Ceuleers
2019-04-11 18:27 ` Luca Muscariello
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6C67CA63-A06F-4D39-BD87-60D7DE7D79DA@gmx.de \
--to=moeller0@gmx.de \
--cc=bloat@lists.bufferbloat.net \
--cc=swmike@swm.pp.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox