Re: [Cake] cake for net-next 4.8

[Dave Taht <dave.taht@gmail.com>]

On Tue, Sep 27, 2016 at 11:56 AM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> 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 have been avoiding the tcp-prague, l4s, etc debates, for health reasons,
and it's possible I've misunderstood something. All along I'd been assuming
that a specialized TCP of some new flavor yet-to-be-agreed-upon would
negotiate ECN and most/all its packets would be marked ECT(1), rather
than ECT(0), and a new AQM would treat a flow like that differently,
but still mark that flow with a CE that the endpoint would interpret
differently.

Are you saying ECT(1) would, instead, be used as a "weaker or harder" CE?


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



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