Re: [Bloat] Bechtolschiem

[Dave Collier-Brown <davecb.42@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

It's written to look like an academic paper, but it's pure marketing.  
"Memory is cheap, we used a lot, so let's select some evidence that 
argues this is a good thing."

As always with the coin-operated, the way to get them to change is to 
offer additional information which

  * captures their attention,

and, more importantly

  * offers them a cheap way to /make more money/.

For example, a software change that make their big buffers not fill up 
with elephants...

--dave

On 2021-07-02 12:59 p.m., Stephen Hemminger wrote:
> On Fri, 2 Jul 2021 09:42:24 -0700
> Dave Taht <dave.taht@gmail.com> wrote:
>
>> "Debunking Bechtolsheim credibly would get a lot of attention to the
>> bufferbloat cause, I suspect." - dpreed
>>
>> "Why Big Data Needs Big Buffer Switches" -
>> http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pdf
>>
> Also, a lot depends on the TCP congestion control algorithm being used.
> They are using NewReno which only researchers use in real life.
>
> Even TCP Cubic has gone through several revisions. In my experience, the
> NS-2 models don't correlate well to real world behavior.
>
> In real world tests, TCP Cubic will consume any buffer it sees at a
> congested link. Maybe that is what they mean by capture effect.
>
> There is also a weird oscillation effect with multiple streams, where one
> flow will take the buffer, then see a packet loss and back off, the
> other flow will take over the buffer until it sees loss.
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com |              -- Mark Twain


[-- Attachment #2: Type: text/html, Size: 2923 bytes --]