Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
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.

  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