Re: [Cake] cake for net-next 4.8

[Jonathan Morton <chromatix99@gmail.com>]

> On 27 Sep, 2016, at 21:18, Dave Taht <dave.taht@gmail.com> wrote:
> 
>> 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.

My interpretation of the consensus is more subtle: we need a signal earlier than we currently do, and with a weaker meaning, but we still need the strong, later signal.

I don’t think we should use CE for that; it has a long-established and widely-deployed meaning.  We *can* use ECT(1), which is presently unused in practice.

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

Before I even consider doing that, could you add a comparable run with the current version of cake to that graph?  COBALT is not quite identical to Codel, and this looks like a case where one of the differences could be important.

 - Jonathan Morton