From: Alan Jenkins <alan.christopher.jenkins@gmail.com>
To: Dave Taht <dave.taht@gmail.com>, Maciej Soltysiak <maciej@soltysiak.com>
Cc: "cerowrt-devel@lists.bufferbloat.net"
<cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in net-next
Date: Wed, 21 Sep 2016 10:06:49 +0100 [thread overview]
Message-ID: <92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com> (raw)
In-Reply-To: <CAA93jw4+oTz00qvScSOyDmQyeEfhoYs__cB_1LJ-AZDHymUfkQ@mail.gmail.com>
On 17/09/16 19:53, Dave Taht wrote:
> 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
are we sure - that's a fairly different algorithm and different
expansion of the acronym...
> video streaming experiments ran on a live, production CDN,
where clients included real mobile and desktop users
> large, multinational production network
hmm, I suppose...
> ## Acknowledgments ##
>
> Van
> ...
> Eric
> ...
ok, there's clearly some overlap here :-D.
> 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 <maciej@soltysiak.com> 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.
next prev parent reply other threads:[~2016-09-21 9:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-17 18:34 Maciej Soltysiak
2016-09-17 18:53 ` Dave Taht
2016-09-21 9:06 ` Alan Jenkins [this message]
2016-09-21 9:39 ` Dave Taht
2016-09-21 10:10 ` Alan Jenkins
2016-09-21 10:15 ` Mikael Abrahamsson
2016-09-21 11:14 ` Alan Jenkins
2016-09-21 11:28 ` Mikael Abrahamsson
2016-09-21 11:19 ` Dave Taht
2016-09-21 11:32 ` Mikael Abrahamsson
2016-09-21 12:40 ` Mikael Abrahamsson
2016-09-21 13:49 ` [Cerowrt-devel] [Bloat] " Alan Jenkins
2016-09-17 20:11 ` [Cerowrt-devel] " Jonathan Morton
2016-09-26 18:47 ` Aaron Wood
2016-09-26 19:30 ` Neal Cardwell
2016-09-26 19:45 ` Aaron Wood
2016-09-26 21:38 ` Dave Taht
2016-09-26 22:09 ` Aaron Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com \
--to=alan.christopher.jenkins@gmail.com \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=maciej@soltysiak.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox