Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] cake for net-next 4.8
Date: Tue, 27 Sep 2016 11:18:22 -0700	[thread overview]
Message-ID: <CAA93jw6cT7hpVXhtn7R__d4KO-X1b2jsPSkyWp4YKGOEdUNycg@mail.gmail.com> (raw)
In-Reply-To: <32E6B0A0-6014-4510-9D97-02645F0EFDFD@gmail.com>

On Tue, Sep 27, 2016 at 10:52 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 25 Sep, 2016, at 21:30, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Judging from me tearing apart how TCP BBR works (presently) with ecn,
>> it looks like we need to add the equivalent to fq_codel ce_threshold
>> behaviors as well.
>
> If I’m reading the legend correctly, you are setting ce_threshold to 1ms to get the better-controlled result.  But that effectively disables the codel algorithm and turns it into a simple “mark all packets over 1ms sojourn” for ECN capable traffic, because it’s a tighter limit than codel’s target.  That’s too aggressive for non-BBR traffic.

Yes it is. :) However the consensus appears to be that ECN should be
an earlier signal than drop, and the work over on the tcp-prague list
centers around repurposing ECT(1) as more like a DCTCP multi-bit
signal.

ce_threshold 1ms is more like signaling loudly - "this is a solid
indicator of  your real OWD" and "you should fiddle with your TCP's
'gain' to compensate for it" - and it's certainly a lot simpler than
codel to do it this way. I haven't got around to fully evaluating a
comparison between BBR with ce_threshold and a non-ecn enabled TCP vs
codel, concurrently (or implementing different behaviors for ECT(1) in
the TCP negotiation step) ...

and... I'm really not sure if what I've seen with ce_threshold is the
desired behavior, vs a vs BBR, thus far - but I'd like to see the
option for it enter cake.

Also, in doing in my network this way, it became apparent to me that -
like several ecn encapsulation rfcs suggest - that when a packet is
already marked CE, and we want to also mark it CE, that the rightest
answer is to drop the packet - not giving pre-CE-marked flows a free
ride.

> In these cases, I think you have to relax and let the FQ action take care of it.

And yes, FQ handles it nicely. Got pics of that somewhere. I did do a
test with ce_threshold + ecn + bbr, vs no ecn and cubic, with the
usual lovely fq'd result.

>  - Jonathan Morton
>



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

  reply	other threads:[~2016-09-27 18:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-25 18:30 Dave Taht
2016-09-27 14:38 ` Jonathan Morton
2016-09-27 16:04   ` Dave Taht
2016-09-27 16:13     ` Jonathan Morton
2016-09-29 23:22       ` Neil Shepperd
2016-09-30  8:02         ` Toke Høiland-Jørgensen
2016-09-30 13:08           ` Neil Shepperd
2016-09-30 19:42           ` Dave Täht
2016-09-30 20:37             ` Neil Shepperd
2016-09-30 21:10               ` Dave Täht
2016-10-03 21:17                 ` Neil Shepperd
2016-10-04  6:33                   ` Henning Rogge
2016-10-04 16:09                   ` Dave Täht
2016-10-20  5:56                     ` Neil Shepperd
2016-09-27 17:52 ` Jonathan Morton
2016-09-27 18:18   ` Dave Taht [this message]
2016-09-27 18:56     ` Jonathan Morton
2016-09-27 19:29       ` Dave Taht
2016-09-27 19:54         ` Jonathan Morton
2016-09-28 23:26       ` Dave Taht
2016-09-28 23:34         ` Jonathan Morton
2016-09-29 20:43           ` Andrew Shewmaker

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=CAA93jw6cT7hpVXhtn7R__d4KO-X1b2jsPSkyWp4YKGOEdUNycg@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=chromatix99@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