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 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.