From: Jesper Louis Andersen <jesper.louis.andersen@gmail.com>
To: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Questions About Switch Buffering
Date: Mon, 13 Jun 2016 00:01:21 +0200 [thread overview]
Message-ID: <CAGrdgiXwqaHLG__Sn+-cedasUuJaRAOHycNg23-1rOPTuaRUiQ@mail.gmail.com> (raw)
In-Reply-To: <20160612212440.GB25090@sesse.net>
[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2349 bytes --]
next prev parent reply other threads:[~2016-06-12 22:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-12 17:44 Noah Causin
2016-06-12 17:48 ` Steinar H. Gunderson
2016-06-12 18:25 ` Benjamin Cronce
2016-06-12 21:24 ` Steinar H. Gunderson
2016-06-12 22:01 ` Jesper Louis Andersen [this message]
2016-06-13 1:07 ` Benjamin Cronce
2016-06-13 1:50 ` Jonathan Morton
2016-06-13 4:34 ` Dave Taht
2016-06-13 8:23 ` Steinar H. Gunderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGrdgiXwqaHLG__Sn+-cedasUuJaRAOHycNg23-1rOPTuaRUiQ@mail.gmail.com \
--to=jesper.louis.andersen@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=sgunderson@bigfoot.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox