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

[Dave Taht <dave.taht@gmail.com>]

ok, I got BBR built with net-next + v2 of the BBR patch. If anyone
wants .deb files for ubuntu, I can put them up somewhere. Some quick
results:

http://blog.cerowrt.org/post/bbrs_basic_beauty/

I haven't got around to testing cubic vs bbr in a drop tail
environment, my take on matters is with fq (fq_codel) in place, bbr
will work beautifully against cubic, and I just wanted to enjoy the
good bits for a while before tearing apart the bad... and staying on
fixing wifi.

I had to go and rip out all the wifi patches to get here... as some
code landed to the ath10k that looks to break everything there, so
need to test that as a baseline first - and I wanted to see if
sch_fq+bbr did anything to make the existing ath9k driver work any
better.




On Sat, Sep 17, 2016 at 2:33 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sat, Sep 17, 2016 at 2:11 PM,  <dpreed@reed.com> 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.
>
> http://blog.cerowrt.org/flent/crypto_fq_bug/airtime_plot.png
>
>>
>>
>>
>> However, it's worth remembering two things: buffering above a certain level is never an improvement,
>
> which BBR recognizes by breaking things up into separate bandwidth and
> RTT analysis phases.
>
>>and flows through any shared router come and go quite frequently on the real Internet.
>
> Very much why I remain an advocate of fq on the routers is that your
> congestion algorithm for your particular flow gets more independent of
> the other flows, and ~0 latency and jitter for sparse flows is
> meaningful.
>
>> Thus RTT on a single flow is not a reasonable measure of congestion. ECN marking is far better and packet drops are required for bounding time to recover after congestion failure.
>
> Aww, give the code a chance, it's only been public for a day! I
> haven't even got it to compile yet!
>
> I think it is a *vast* improvement over cubic, and possibly the first delay
> sensitive tcp that can compete effectively with it. I'm dying to test
> it thoroughly,
> but have a whole bunch other patches for wifi in my queue.
>
>>
>> The authors suffer from typical naivete by thinking all flows are for file transfer and that file transfer throughput is the right basic perspective, rather than end to end latency/jitter due to sharing, and fair sharing stability.
>
> While I agree *strongly* that lots of short flows is how the internet
> mostly operates, (I used to cite a paper on this a lot)
>
> a huge number of bulk flows exist that has been messing up the short
> flows. I think the number was something 70% of internet traffic has
> become netflix-like. *anything* e2e that can reduce the negative
> impact of the big fat flows on everything else is a win.
>
>
>>
>>
>>
>> -----Original Message-----
>> From: "Jonathan Morton" <chromatix99@gmail.com>
>> Sent: Sat, Sep 17, 2016 at 4:11 pm
>> To: "Maciej Soltysiak" <maciej@soltysiak.com>
>> Cc: "Maciej Soltysiak" <maciej@soltysiak.com>, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
>> Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP innet-next
>>
>>
>>> 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 packet loss.
>>
>>  - Jonathan Morton
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> --
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org