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

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

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