Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Andy Furniss <adf.lists@gmail.com>
To: xnor <xnoreq@gmail.com>, David Lang <david@lang.hm>
Cc: Cake@lists.bufferbloat.net
Subject: Re: [Cake] cake default target is too low for bbr?
Date: Fri, 28 Apr 2017 23:26:01 +0100	[thread overview]
Message-ID: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com> (raw)
In-Reply-To: <emaf6044d5-5cc1-4259-b66d-b547c04c0939@gaming>

xnor wrote:
> 
>> On Fri, 28 Apr 2017, xnor wrote:
>> 
>>> As I understand it, increase in RTT due to queueing of packets is
>>> the main feedback mechanism for BBR. So dropping packets, which I
>>> already consider harmful, is really harmful with BBR because
>>> you're not telling the sender to slow down.
>> 
>> If BBR does not slow down when packets are dropped, it's too
>> hostile to use on a public network. The only way for a public
>> network to respond to a flood of traffic higher than what it can
>> handle is to drop packets (with a possible warning via ECN shortly
>> before packets get dropped). If BBR doesn't slow down, it's just
>> going to be wasting bandwidth.
> No it isn't. Packet loss does not equal conguestion - it never did. 
> Dropping packets to signal congestion is an ugly hack for 
> implementations that are too dumb to understand any proper congestion
>  control mechanism.

Hmm, I bet a lot of carrier links are policed rather than smart queue.

It also seems (OK one quick possibly flawed test), that bbr ignores ECN
as well as drops in the sense that marked is just as high as dropped.

> Dropping due to queues being full normally doesn't happen before the
> RTT has significantly increased.

Not so good on ingress though - where normaly (ie. non bbr) a drop is
handy to signal early to back off - letting a buffer fill up too much is
also somewhat going to fill the remote buffer that you would like to
keep empty.

> 
> BBR fixes both of these problems: a) it ignores packet loss on
> unreliable links and therefore achieves much higher throughput than
> conventional congestion control algorithms (that wrongly assume
> congestion on packet loss) An experiment with 10 Gbps bottleneck, 100
> ms RTT and 1% packet loss (as described in the net-next commit)
> showed ~3000x higher throughput with BBR compared to cubic.

So on a congested policed link it will make matters worse for "normal"
tcp users - maybe everyone will need to use it soon.

> b) it reacts to increase in RTT. An experiment with 10 Mbps
> bottleneck, 40 ms RTT and a typical 1000 packet buffer, increase in
> RTT with BBR is ~3 ms while with cubic it is over 1000 ms.

That is a nice aspect (though at 60mbit hfsc + 80ms bfifo I tested with
5 tcps it was IIRC 20ms vs 80 for cubic). I deliberately test using ifb
on my PC because I want to pretend to be a router - IME (OK it was a
while ago) testing on eth directly gives different results - like the
locally generated tcp is backing off and giving different results.


  reply	other threads:[~2017-04-28 22:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.435.1493406198.3609.cake@lists.bufferbloat.net>
2017-04-28 21:11 ` xnor
2017-04-28 21:29   ` David Lang
2017-04-28 21:54     ` Andy Furniss
2017-04-28 22:02     ` xnor
2017-04-28 22:26       ` Andy Furniss [this message]
2017-04-28 23:52         ` Andy Furniss
2017-04-28 23:54           ` Andy Furniss
2017-05-03  9:50           ` Andy Furniss
2017-05-04  2:13             ` Jim Gettys
2017-05-04 10:22               ` Andy Furniss
2017-05-04 17:40                 ` Jim Gettys
2017-05-08 10:37                   ` Andy Furniss
2017-04-29  4:32         ` Jonathan Morton
2017-04-29 10:31           ` Andy Furniss
2017-04-28 19:03 Andy Furniss
2017-04-28 20:45 ` [Cake] " Andy Furniss

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/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com \
    --to=adf.lists@gmail.com \
    --cc=Cake@lists.bufferbloat.net \
    --cc=david@lang.hm \
    --cc=xnoreq@gmail.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