<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 12, 2016 at 5:01 PM, Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This *is* commonly a problem. Look up "TCP incast".<div><br></div><div>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.</div><div><br></div><div>It is almost like resonance in engineering. At the wrong "frequency", the bridge/switch will resonate and make everything go haywire.</div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Sun, Jun 12, 2016 at 11:24 PM, Steinar H. Gunderson <span dir="ltr"><<a href="mailto:sgunderson@bigfoot.com" target="_blank">sgunderson@bigfoot.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Jun 12, 2016 at 01:25:17PM -0500, Benjamin Cronce wrote:<br>
> Internal networks rarely have bandwidth issues and congestion only happens<br>
> when you don't have enough bandwidth.<br>
<br>
</span>I don't think this is true. You might not have an aggregate bandwidth issues,<br>
but given the burstiness of TCP and the typical switch buffer depth<br>
(64 frames is a typical number), it's very very easy to lose packets in your<br>
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<br>
network.)<br>
<span><br>
/* Steinar */<br>
--<br>
Homepage: <a href="https://www.sesse.net/" rel="noreferrer" target="_blank">https://www.sesse.net/</a><br>
</span><div><div>_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature">J.</div>
</font></span></div>
<br>_______________________________________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
<br></blockquote></div><br></div>