Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

2016-09-17 Thread Dave Taht
On Sat, Sep 17, 2016 at 2:11 PM, wrote: > The assumption that each flow on a path has a minimum, stable RTT fails in > wireless and multi path networks. Yep. But we're getting somewhere serious on having stabler RTTs for wifi, and achieving airtime fairness.

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next

2016-09-17 Thread dpreed
The assumption that each flow on a path has a minimum, stable RTT fails in wireless and multi path networks. However, it's worth remembering two things: buffering above a certain level is never an improvement, and flows through any shared router come and go quite frequently on the real

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next

2016-09-17 Thread Jonathan Morton
> On 17 Sep, 2016, at 21:34, Maciej Soltysiak wrote: > > Cake and fq_codel work on all packets and aim to signal packet loss early to > network stacks by dropping; BBR works on TCP and aims to prevent packet loss. By dropping, *or* by ECN marking. The latter avoids

Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next

2016-09-17 Thread Dave Taht
BBR is pretty awesome, and it's one of the reasons why I stopped sweating inbound rate limiting + fq_codel as much as I used to. I have a blog entry pending on this but wasn't expecting the code to be released before the paper was... and all I had to go on til yesterday was Nowlan's dissertation:

[Cerowrt-devel] BBR congestion control algorithm for TCP in net-next

2016-09-17 Thread Maciej Soltysiak
Hi, Just saw this: https://patchwork.ozlabs.org/patch/671069/ Interested to see how BBR would play out with things like fq_codel or cake. "loss-based congestion control is unfortunately out-dated in today's networks. On today's Internet, loss-based congestion control causes the infamous

[Cerowrt-devel] BBR congestion control

2016-09-17 Thread Erkki Lintunen
This may already be yesterday news to list subscribers, but may there be still be others like me missing this fascinating new entry, I'm for rescue. > While it is impossible to disambiguate any single bandwidth or RTT > measurement, a connection's