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

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

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" 
> Sent: Sat, Sep 17, 2016 at 4:11 pm
> To: "Maciej Soltysiak" 
> Cc: "Maciej Soltysiak" , 
> "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
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[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 Internet.

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.

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.




-Original Message-
From: "Jonathan Morton" 
Sent: Sat, Sep 17, 2016 at 4:11 pm
To: "Maciej Soltysiak" 
Cc: "Maciej Soltysiak" , 
"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

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

[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 packet loss.

 - Jonathan Morton

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

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

http://blog.cerowrt.org/papers/bbr_thesis.pdf

which seemed closer to good than anything I'd read before, but still
wrong in a few respects, which has taken a few years to sort out. I
think reading the upcoming acm queue paper is going to be fun!

I think they have identified the right variables to probe - RTT and
bandwidth, in sequence - for modern congestion control to work much
better.

Still BBR makes a few assumptions that do not hold (or so I think) -
with wifi in the control loop, and it needs wider testing in more
circumstances than just google facing out - like on itty bitty nas's
and media servers - and especially seeing what happens when it
interacts with fq_codel and cake would be good to see. I've watched
youtube be *excellent* for 2 years now, and only had the faintest
hints as to why.

It was quite amusing that the original patchset didn't compile on 32
bit platforms.

And make no mistake - it still makes plenty of sense to apply
fq_codel-like algorithms to routers, and the stuff we just did to wifi
for fq_codel and airtime fairness. Had I thought BBR solved everything
I'd have quit years ago.



On Sat, Sep 17, 2016 at 11:34 AM, Maciej Soltysiak  wrote:
> 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
> bufferbloat problem"
>
> So, instead of waiting for packet loss they probe and measure, e.g. when
> doing slow start (here called STARTUP) they don't speed up until packet
> loss, but slow down before reaching estimated bandwidth level.
>
> 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.
>
>
> Best regards,
> Maciej
>
>
> ___
> 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
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[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
bufferbloat problem"

So, instead of waiting for packet loss they probe and measure, e.g. when
doing slow start (here called STARTUP) they don't speed up until packet
loss, but slow down before reaching estimated bandwidth level.

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.


Best regards,
Maciej
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

[Cerowrt-devel] BBR congestion control

[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 behavior over time tells a clearer
> story. BBR uses a measurement strategy designed to resolve this
> ambiguity. It combines these measurements with a robust servo loop
> using recent control systems advances to implement a distributed
> congestion control algorithm that reacts to actual congestion, not
> packet loss or transient queue delay, and is designed to converge with
> high probability to a point near the optimal operating point.

Got the bit from Steinar H. Gunderson's blog,
,
where before he has shared his troubles with bufferbloat while delivering video
streams from big events of young hackers.

___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel