From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 D6A243CB35; Fri, 2 Jul 2021 12:42:35 -0400 (EDT) Received: by mail-il1-x12e.google.com with SMTP id o10so10309852ils.6; Fri, 02 Jul 2021 09:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6tMMa3tztE2rDwncOMWf9vEQ36eGATKY/0t5Hkprbeg=; b=V0p97hieumjH9DF11i9DUkuLdvolAMN9ScMl/T54QLES2cG+DTXd8ANqCbLdoBMa7+ yB32tmo5peIaBl7ItvZug0sGa5oE7eoJjmFwzzOAGZareKS1Q9EU11omZq8mKsXEswp6 C7ieCr2mjx3jZ4suK7DyZKio6NPo1X16qByov06kJWMu8ZVrloszmgoFfSkkSbcY/Q+s GVk64DxyhqFSkQSp2TyhBbOSXDBH2E6klf7c1TNR0N+moqK7uxkQgkZ/z+grEyjLGf+3 6z0zoPpZ58uTtAezqAOg4jgsmHp5nu5n0QFq0oP++ngTBTHfpe2aOWCIXCClud4YjtOG +ZjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6tMMa3tztE2rDwncOMWf9vEQ36eGATKY/0t5Hkprbeg=; b=lfnuoeaFuza3zOy4fgZGZOgIrZ1omMXBJgJlSv+0ny9buYuM0pgdGmK/e58MuwKJap Yq+IYiAYUqPcp3ldkqdKUJZPLV+3wwpnGNEGfKZErKnN+Yp0Sj2Bu3FkzWI8DG9iAeQw mKq3KpkX2GeU43AV9fNis/8HeKATsTcedP0V+3Lm0j/4auvrrxcUMJNHaLlHTznTJzyG iSf6jdvH9nPSDy3/ibzZO5cqYhQ/AkboQwOng4VML22Af+U+QVlZUWdO8zkCSy5lD/tq 0Ug4RzBb/VNkjBo8g95GID1SB7TwD08/Fgkz7RPGR7aCUTbgl/zv5zTvlUZE7iprgBHa PyHg== X-Gm-Message-State: AOAM5317e7xlJfEtC1G5dC6TowcRV8qR1iM7b32h3hnA5tc68xAEZzpL fm0OOBypOctA2UQ+f3ccJhHCfHip3EcTZRhr84M= X-Google-Smtp-Source: ABdhPJwZ8sCiv3jzVxd9R7bQ5qq7Maf5/H/ssCPHk1SGvnoQFuqpa7ekeU9f3k1PQIbSf6/3DW6tNw8YPDHO9g1lbAU= X-Received: by 2002:a05:6e02:1245:: with SMTP id j5mr572305ilq.249.1625244155251; Fri, 02 Jul 2021 09:42:35 -0700 (PDT) MIME-Version: 1.0 References: <55fdf513-9c54-bea9-1f53-fe2c5229d7ba@eggo.org> <871t4as1h9.fsf@toke.dk> <3D32F19B-5DEA-48AD-97E7-D043C4EAEC51@gmail.com> <1465267957.902610235@apps.rackspace.com> In-Reply-To: <1465267957.902610235@apps.rackspace.com> From: Dave Taht Date: Fri, 2 Jul 2021 09:42:24 -0700 Message-ID: To: David Reed , bloat Cc: Ketan Kulkarni , Jonathan Morton , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [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 16:42:35 -0000 "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 .. i think i've just gained access to a few networks with arista gear in the bottleneck path. On Mon, Jun 6, 2016 at 7:52 PM wrote: > > So did anyone write a response debunking their paper? Their NS-2 simula= tion is most likely the erroneous part of their analysis - the white paper = would not pass a review by qualified referees because there is no way to ch= eck their results and some of what they say beggars belief. > > > > Bechtolsheim is one of those guys who can write any damn thing and it bec= omes "truth" - mostly because he co-founded Sun. But that doesn't mean that= he can't make huge errors - any of us can. > > > > The so-called TCP/IP Bandwidth Capture effect that he refers to doesn't s= ound like any capture effect I've ever heard of. There is an "Ethernet Cap= ture Effect" (which is cited), which is due to properties of CSMA/CD binary= exponential backoff, not anything to do with TCP's flow/congestion control= . So it has that "truthiness" that makes glib people sound like they know = what they are talking about, but I'd like to see a reference that says this= is a property of TCP! > > > > What's interesting is that the reference to the Ethernet Capture Effect i= n that white paper proposes a solution that involves changing the backoff a= lgorithm slightly at the Ethernet level - NOT increasing buffer size! > > > > Another thing that would probably improve matters a great deal would be t= o drop/ECN-mark packets when a contended output port on an Arista switch de= velops a backlog. This will throttle TCP sources sharing the path. > > > > The comments in the white paper that say that ACK contention in TCP in th= e reverse direction are the problem that causes the "so-called TCP/IP Bandw= idth Capture effect" that is invented by the authors appears to be hogwash = of the first order. > > > > Debunking Bechtolsheim credibly would get a lot of attention to the buffe= rbloat cause, I suspect. > > > > > > On Monday, June 6, 2016 5:16pm, "Ketan Kulkarni" sai= d: > > some time back they had this whitepaper - > "Why Big Data Needs Big Buffer Switches" > http://www.arista.com/assets/data/pdf/Whitepapers/BigDataBigBuffers-WP.pd= f > the type of apps they talk about is big data, hadoop etc > > On Mon, Jun 6, 2016 at 11:37 AM, Mikael Abrahamsson wr= ote: >> >> On Mon, 6 Jun 2016, Jonathan Morton wrote: >> >>> At 100ms buffering, their 10Gbps switch is effectively turning any DC i= t=E2=80=99s installed in into a transcontinental Internet path, as far as p= eak latency is concerned. Just because RAM is cheap these days=E2=80=A6 >> >> Nono, nononononono. I can tell you they're spending serious money on ins= erting this kind of buffering memory into these kinds of devices. Buying th= ese devices without deep buffers is a lot lower cost. >> >> These types of switch chips either have on-die memory (usually 16MB or l= ess), or they have very expensive (a direct cost of lowered port density) o= ff-chip buffering memory. >> >> Typically you do this: >> >> ports ---|------- >> ports ---| | >> ports ---| chip | >> ports ---|------- >> >> Or you do this >> >> ports ---|------|---buffer >> ports ---| chip |---TCAM >> -------- >> >> or if you do a multi-linecard-device >> >> ports ---|------|---buffer >> | chip |---TCAM >> -------- >> | >> switch fabric >> >> (or any variant of them) >> >> So basically if you want to buffer and if you want large L2-L4 lookup ta= bles, you have to sacrifice ports. Sacrifice lots of ports. >> >> So never say these kinds of devices add buffering because RAM is cheap. = This is most definitely not why they're doing it. Buffer memory for them is= EXTREMELY EXPENSIVE. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Latest Podcast: https://www.linkedin.com/feed/update/urn:li:activity:6791014284936785920/ Dave T=C3=A4ht CTO, TekLibre, LLC