[Bloat] fq_codel, high bandwidth, and delays
David Lang
david at lang.hm
Tue Jul 8 00:38:54 EDT 2014
On Mon, 7 Jul 2014, Aaron Wood wrote:
>
> In talking with a friend over the weekend that moves data around for the
> national labs (on links at rates like 10Gbps), we ended up having a rather
> interesting discussion about just how radically different the problem
> spaces are vs. what he's seen in the bufferbloat community.
>
> They have few flows, long lived, and are trying to push >1Gbps per flow,
> across the continent (or from Europe to the US), with inherent delays on
> the order of 100ms. TCP under these conditions is, from his reports,
> incredibly fragile, where even a tiny packet error rate stops TCP for
> saturating the link (since it can't tell the difference between congestion
> and a non-congestion-related dropped packet).
>
> And suddenly the "every packet is precious" mode of thought becomes crystal
> clear.
Part of the answer for them is "don't do that" :-)
There are many tools around to move massive amounts of data through multiple
parallel TCP connections so that if one connection gets a lost packet, it
doesn't kill the entire flow, only the one connection slows down (if it's true
congestion, then all the flows will be slowed)
David Lang
> Clearly they are trying to solve different problems, yet they do have
> congestion events, when new flows are added to the network.
>
> Has anyone used fq_codel (or it's friends) in scenarios like this? fq is
> fairly new (2 years?) and I can't find much about it and high bandwidth
> links in my searches.
>
> Given that their problems aren't those that fq is trying to solve, I
> wouldn't expect it, but curious to see if anyone has any research on it.
>
> Thanks,
> Aaron
>
-------------- next part --------------
_______________________________________________
Bloat mailing list
Bloat at lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
More information about the Bloat
mailing list