From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 23C773B2B0 for ; Sun, 12 Jun 2016 21:07:44 -0400 (EDT) Received: by mail-oi0-x22b.google.com with SMTP id u201so59826884oie.0 for ; Sun, 12 Jun 2016 18:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fij5XxPa6Xnfvz6tnMXMb7v9hDzd3d0Zl1JfSl/7d1k=; b=syV5Jwp0nMuoulWX5DgwV1EPekpO2ItNuq4Qvuu+LPVaepPaNV1Zhq5NdyMhN+4Phe FPc5g9rJ7ESD9cNPVEhGEEPQIygO/lLPYgrkpgY/S0Z2+SYfA6IlQ8H9U6gohEAIi2jx +QhTdore34D25+ALzbnbtPWiw+9BE+J88ihS7ZTejluP/IyYHLb6bJJ+hayhQTDX6+UJ ZasAg53/rJk7UHk+yt/p4DIKTvsHAYmJrv6ezRiT/WGLziYJyhQ/dqcOrukXEGVmtkCr jS6VUT2YGEGDoMUiuUTvYtrR1lulON/ukZWvwZgH4DodAajP0u9d53V2I57G4Nt2F1vo kIOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fij5XxPa6Xnfvz6tnMXMb7v9hDzd3d0Zl1JfSl/7d1k=; b=lKifs6Os8DqSBJlwkdYASpXcBEY41v75BplsDX29fN5ajVmGX2qSmnnezPo9suROXH tRvdRmyOnxJptbydc9SoMhawdykTdIQc2FCpSzzOD0NWk+GGWirbLYnJHViIIDv8JfMS cx7atwPpg27HeLziDABUIfJs6RuGv23vU3NER7aTP9RJdMDRm43arAB/08tNmmA/C28i 3ISFZ6F6dVHnmia/sf3l6+hHbXoIVh4MoYPYers4kcBis4j6GI+dRb9eTW5iW7SdZHw1 QxWcYBOJyscP+LHW+wjexGkCI5ORPCl79CjQ5griNaYXKA9+P7aMFXjsC6kITHMo6Nvi MpeQ== X-Gm-Message-State: ALyK8tKCnE2kxT3EKuf+igmJEF4FdMsGhX7dYRDfSoG/ZRCpbotO0NlyYlTuBQWtMKgVetb7ylhoLYZWI5yNZg== X-Received: by 10.202.108.19 with SMTP id h19mr6548416oic.69.1465780063614; Sun, 12 Jun 2016 18:07:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.16.115 with HTTP; Sun, 12 Jun 2016 18:07:42 -0700 (PDT) In-Reply-To: References: <151299a8-87ec-6a8a-b44b-9f710c31a46f@gmail.com> <20160612212440.GB25090@sesse.net> From: Benjamin Cronce Date: Sun, 12 Jun 2016 20:07:42 -0500 Message-ID: To: Jesper Louis Andersen Cc: "Steinar H. Gunderson" , bloat Content-Type: multipart/alternative; boundary=001a1142e14a02bc7105351e84cc Subject: Re: [Bloat] Questions About Switch Buffering 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: Mon, 13 Jun 2016 01:07:44 -0000 --001a1142e14a02bc7105351e84cc Content-Type: text/plain; charset=UTF-8 I'm not arguing the an AQM isn't useful, just that you can't have your cake and eat it to. I wouldn't spend much time going down this path without first talking to someone with a strong background in ASICs for network switches and asking if it's even a feasible. Everything(very little) I know about ASICs and buffers is buffering is a very hard problem that east up a lot of transistors and more transistors means slower ASICs. Almost always a trade-off between performance and buffer size. CoDel and especially Cake sound like they would not be ASIC friendly. On Sun, Jun 12, 2016 at 5:01 PM, Jesper Louis Andersen < jesper.louis.andersen@gmail.com> wrote: > This *is* commonly a problem. Look up "TCP incast". > > The scenario is exactly as you describe. A distributed database makes > queries over the same switch to K other nodes in order to verify the > integrity of the answer. Data is served from memory and thus access times > are roughly the same on all the K nodes. If the data response is sizable, > then the switch output port is overwhelmed with traffic, and it drops > packets. TCPs congestion algorithm gets into play. > > It is almost like resonance in engineering. At the wrong "frequency", the > bridge/switch will resonate and make everything go haywire. > > > On Sun, Jun 12, 2016 at 11:24 PM, Steinar H. Gunderson < > sgunderson@bigfoot.com> wrote: > >> On Sun, Jun 12, 2016 at 01:25:17PM -0500, Benjamin Cronce wrote: >> > Internal networks rarely have bandwidth issues and congestion only >> happens >> > when you don't have enough bandwidth. >> >> I don't think this is true. You might not have an aggregate bandwidth >> issues, >> but given the burstiness of TCP and the typical switch buffer depth >> (64 frames is a typical number), it's very very easy to lose packets in >> your >> switch even on a relatively quiet network with no downconversion. (Witness >> the rise of DCTCP, made especially for internal traffic on this kind of >> network.) >> >> /* Steinar */ >> -- >> Homepage: https://www.sesse.net/ >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > > > > -- > J. > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --001a1142e14a02bc7105351e84cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not arguing the an AQM isn't useful, just that= you can't have your cake and eat it to. I wouldn't spend much time= going down this path without first talking to someone with a strong backgr= ound in ASICs for network switches and asking if it's even a feasible. = Everything(very little) I know about ASICs and buffers is buffering is a ve= ry hard problem that east up a lot of transistors and more transistors mean= s slower ASICs. Almost always a trade-off between performance and buffer si= ze. CoDel and especially Cake sound like they would not be ASIC friendly.

On Sun, Jun 1= 2, 2016 at 5:01 PM, Jesper Louis Andersen <jesper.louis.ande= rsen@gmail.com> wrote:
This *is* commonly a problem. Look up "TCP incast".<= div>
The scenario is exactly as you describe. A distributed d= atabase makes queries over the same switch to K other nodes in order to ver= ify the integrity of the answer. Data is served from memory and thus access= times are roughly the same on all the K nodes. If the data response is siz= able, then the switch output port is overwhelmed with traffic, and it drops= packets. TCPs congestion algorithm gets into play.

It is almost like resonance in engineering. At the wrong "frequency&= quot;, the bridge/switch will resonate and make everything go haywire.

On Sun, Jun 12, 2016 at 11:24 PM, Steinar H. Gu= nderson <sgunderson@bigfoot.com> wrote:
On Sun, Jun 12, 2016 at 01:25:17PM -0500, Benjamin= Cronce wrote:
> Internal networks rarely have bandwidth issues and congestion only hap= pens
> when you don't have enough bandwidth.

I don't think this is true. You might not have an aggregate band= width issues,
but given the burstiness of TCP and the typical switch buffer depth
(64 frames is a typical number), it's very very easy to lose packets in= your
switch even on a relatively quiet network with no downconversion. (Witness<= br> the rise of DCTCP, made especially for internal traffic on this kind of
network.)

/* Steinar */
--
Homepage: https://www.sesse.net/
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat



<= /div>--
J.

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat


--001a1142e14a02bc7105351e84cc--