Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Andy Furniss <adf.lists@gmail.com>
Cc: xnor <xnoreq@gmail.com>, David Lang <david@lang.hm>,
	Cake@lists.bufferbloat.net
Subject: Re: [Cake] cake default target is too low for bbr?
Date: Sat, 29 Apr 2017 07:32:19 +0300	[thread overview]
Message-ID: <77335E95-3774-4F55-BD78-50335D811603@gmail.com> (raw)
In-Reply-To: <85386ca9-f0be-f60f-796a-e5aa3b8ee212@gmail.com>


> On 29 Apr, 2017, at 01:26, Andy Furniss <adf.lists@gmail.com> 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.

Actually, BBR considers mainly a measurement of “delivery rate”, and paces its sending to match that.  It does *not* primarily rely on a congestion window as most TCPs do; one is provided only as a safety net of last resort.

Measurements of RTT are mostly used for two purposes: to size the congestion window so that it doesn’t interfere with normal operation; and to estimate when “queue draining” is complete after a bandwidth probe cycle.

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

Policing should theoretically produce a consistent delivery rate, which is what BBR needs to work effectively.  A wrinkle here is that most policers and shapers to date rely on a token-bucket algorithm which permits bursts at rates well above the policy, and BBR has to attempt to infer the policy rate from the medium-term behaviour.

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

Yes, BBR ignores ECN, which I consider to be an unfortunate feature; it could quite reasonably be used to terminate bandwidth probes early, before they build up a significant queue (which then needs to be drained).

Cake works very well with BBR, provided it is deployed at the upstream end of the bottleneck link.  In this position, Cake happily absorbs the temporary standing queue caused by bandwidth probes, and the deficit-mode shaper means that BBR tends to see a consistent delivery rate, which it considers ideal.  In practice it matters little whether the BBR sender negotiates ECN or not, in this case.

When deployed at the downstream end of the bottleneck link, Cake works less well with BBR - but that’s true to some extent of all TCPs.  In ingress mode, at least, dropping packets effectively causes a reduction in the delivery rate, which should influence BBR more strongly to correct itself.  But if ECN is negotiated, these packet drops do not occur.  In both cases, the temporary standing queue collects in the upstream dumb queue, unless Cake is configured to a conservative enough margin below the bottleneck rate.  Cake does everything it reasonably can here, but the topology is fundamentally unfavourable.

 - Jonathan Morton


  parent reply	other threads:[~2017-04-29  4:32 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
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 [this message]
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=77335E95-3774-4F55-BD78-50335D811603@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=Cake@lists.bufferbloat.net \
    --cc=adf.lists@gmail.com \
    --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