From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 930453B2B0 for ; Sun, 12 Jun 2016 18:02:02 -0400 (EDT) Received: by mail-lf0-x236.google.com with SMTP id j7so50558563lfg.1 for ; Sun, 12 Jun 2016 15:02:02 -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=JkmUgftkuVnA8ylu6pwYcbr/Ry4Tkmh4YeE98yl9CXc=; b=qyarNNcpg+MG+VSgwMIKu3bZD/k7OraUdkJCdGd7QoHmgfjbAGwlEnxR3qw8RKGT/s RcojtFUN2f1nhMmKMz9voBQbGm+dpuDatG6Mx6YXq8GhVZ8SzqAUZXCHrj01f+2xZB8S g/2p3P2dp+ZjXTb3NzoAOyGd1FdODnYvlZID0/Xf5BGWEfBxWZPtVz2FWjM/sIuA0YT9 dRXARIMt0UkNwr6i+UFXY9M7JHNDexVGXmcxJbuyrqNI+e2U3IJzHasP59pL43PSqVgw B71CnDd+EyGurGgrNyDtjOIfpqk9Tw80vNcFVSf56Fo3bgHmTvEUma9mn2x+1jSvMLLr ZEug== 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=JkmUgftkuVnA8ylu6pwYcbr/Ry4Tkmh4YeE98yl9CXc=; b=fvscAoIUWCiuVs2tUY6zdk/kQAE2rAq0nbTTmFj+ORo31Kd9l7K1wJNcRVkBlu26cO uQqpkVx5Nk9lRKs8ja86B08MI5AtzdmBeUqLsRDpeHL6Wk+GREChqOBwT8yUIPuqQD8f N4MGxCsq8qw2tIw594mdBM8PgOGnvv2D4laVuKkE4M0biPSCEGZTOPuMFpTt4vp/ez/E +cfChDhQovux25XsuwFAudwBBtLe87rS9Ff+PilIWHVPgZyRojTNCPmaMlllYaavRsjJ 5qNg3Ual4PWs9rJDXNVhd0CbkrXjL93NpM5W6RH4b+h2vccjPMzeAh+Gk9+NCbTweoOW Vmug== X-Gm-Message-State: ALyK8tJGB87SnMbsiPsL/+Mnps0D2Hpp04Tgrsz4LAKvnuvrF0NtJKTzAMvG/rk6NoEwevP4khVFYLNKtr3Hyw== X-Received: by 10.25.146.81 with SMTP id u78mr2558492lfd.224.1465768921392; Sun, 12 Jun 2016 15:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.155.135 with HTTP; Sun, 12 Jun 2016 15:01:21 -0700 (PDT) In-Reply-To: <20160612212440.GB25090@sesse.net> References: <151299a8-87ec-6a8a-b44b-9f710c31a46f@gmail.com> <20160612212440.GB25090@sesse.net> From: Jesper Louis Andersen Date: Mon, 13 Jun 2016 00:01:21 +0200 Message-ID: To: "Steinar H. Gunderson" Cc: bloat Content-Type: multipart/alternative; boundary=001a11401e74e1ece205351bebf7 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: Sun, 12 Jun 2016 22:02:02 -0000 --001a11401e74e1ece205351bebf7 Content-Type: text/plain; charset=UTF-8 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. --001a11401e74e1ece205351bebf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This *is* commonly a problem. Look up "TCP incast&quo= t;.

The scenario is exactly as you describe. A distribut= ed 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 ac= cess 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 d= rops packets. TCPs congestion algorithm gets into play.

It is almost like resonance in engineering. At the wrong "freque= ncy", the bridge/switch will resonate and make everything go haywire.<= /div>


On Sun, Jun 12, 2016 at 11:24 PM, Steinar H. Gunderson <sg= underson@bigfoot.com> wrote:
On Sun, Jun 12, 2016 at 01:25:17PM -0500, Benjamin Cronc= e 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@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat



--
=
J.
--001a11401e74e1ece205351bebf7--