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
>
>