From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 10B963CB35 for ; Fri, 2 Jul 2021 13:50:58 -0400 (EDT) Received: by mail-qv1-xf34.google.com with SMTP id d2so5056703qvh.2 for ; Fri, 02 Jul 2021 10:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=jXIYzaubuNsjFxAigo0P7qEnEgATGIEUpQWHyt0obFA=; b=T6uE4EDT70B81oU8ucnI6/SbD2JQVryNZBFqd7d0zMZ1a2Nv3PIJ8RpyFllNs/bKuY O58S6axwI+ANi9/QuIjaRbOMOUDWqFVz4X5bOwXRDjOQB35UN4cNzocgAc29cjwvgdDf +1vJwJ13eEM6CYKPHuEyZZItx4TCCh5x9pqU18GH9QIN3g4P6XeFZpwzREtohR7GCuLN fSrCQMAOr52qPsJBwXBccnX56/YU/fSVveVeKTBRzacH5oHkWNz2JDJ4iiPi4HdkOfVu lH1uKZqOpLpWcdvyo8iRCuVkvRiU2ioct5XX275on+53S+gRX0feGvzK3MpVUrVLfStn elFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=jXIYzaubuNsjFxAigo0P7qEnEgATGIEUpQWHyt0obFA=; b=ofYfm0A0n+8ucM4RnnYeF1ZZOBse/OFQ0z2Zn3WumdBshMrwZvO8C7hIDDEO0QKZ3U qKjYfk6Pl1XzZiyEy04LnEBB6n6c0+rd+/mQJ5ju/ZKpPgMHaucXGocYXRcZCzqUp5oU qBa4gn32SyXsc51tvRvr7NtceUHSRF7O031PnoVhhmcE8puiYsty2cV76Rln3WU3pYa4 mP5D5dLJMRwqDFjkcywjstwdEBdFXbaq2ncdivw4UZHkzvTlad3cdeN6KwtichIJinq+ g6+BSZUpiVZV5vERMVkE+gyiEF7vI6o9xDZXL3jdJSV6SW1gpDbuAA0liIqYskFfwPBK 6dEw== X-Gm-Message-State: AOAM532KwwXc00ywvMFN5Gb1mzPE20PElVR0jKXr5ZZnUP7jYAAtAZsb DLHevxRh6PInZNDmBrhHibY= X-Google-Smtp-Source: ABdhPJyAcNnXAAKzxmAJGY55KeTW5dWNyIRR8in4wQRBOO5f+7NYjidLD6jaZ5DeiQhGM0wtJbw+Zg== X-Received: by 2002:ad4:58e9:: with SMTP id di9mr625518qvb.62.1625248257624; Fri, 02 Jul 2021 10:50:57 -0700 (PDT) Received: from [192.168.7.123] ([99.241.212.236]) by smtp.gmail.com with ESMTPSA id p64sm1689377qka.114.2021.07.02.10.50.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Jul 2021 10:50:57 -0700 (PDT) From: Dave Collier-Brown X-Google-Original-From: Dave Collier-Brown Reply-To: dave.collier-brown@indexexchange.com To: bloat@lists.bufferbloat.net References: <55fdf513-9c54-bea9-1f53-fe2c5229d7ba@eggo.org> <871t4as1h9.fsf@toke.dk> <3D32F19B-5DEA-48AD-97E7-D043C4EAEC51@gmail.com> <1465267957.902610235@apps.rackspace.com> <20210702095924.0427b579@hermes.local> Organization: Index Exchange Message-ID: <121b464e-4c93-4e8f-a825-7f33c3e38d2d@indexexchange.com> Date: Fri, 2 Jul 2021 13:50:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20210702095924.0427b579@hermes.local> Content-Type: multipart/alternative; boundary="------------6D67C01D4810F1B56483E530" Content-Language: en-US Subject: Re: [Bloat] Bechtolschiem 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: Fri, 02 Jul 2021 17:50:58 -0000 This is a multi-part message in MIME format. --------------6D67C01D4810F1B56483E530 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 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 --------------6D67C01D4810F1B56483E530 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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
--------------6D67C01D4810F1B56483E530--