Date:   Tue, 01 May 2018 13:36:16 +0200
From:   Toke Høiland-Jørgensen <toke@...e.dk>
To:     Cong Wang <xiyou.wangcong@...il.com>,
        Dave Taht <dave.taht@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>,
        Cake List <cake@...ts.bufferbloat.net>
Subject: Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

Cong Wang <xiyou.wangcong@...il.com> writes:

> On Mon, Apr 30, 2018 at 2:27 PM, Dave Taht <dave.taht@...il.com> wrote:
>> On Mon, Apr 30, 2018 at 2:21 PM, Cong Wang <xiyou.wangcong@...il.com> wrote:
>>> On Sun, Apr 29, 2018 at 2:34 PM, Toke Høiland-Jørgensen <toke@...e.dk> wrote:
>>>> sch_cake targets the home router use case and is intended to squeeze the
>>>> most bandwidth and latency out of even the slowest ISP links and routers,
>>>> while presenting an API simple enough that even an ISP can configure it.
>>>>
>>>> Example of use on a cable ISP uplink:
>>>>
>>>> tc qdisc add dev eth0 cake bandwidth 20Mbit nat docsis ack-filter
>>>>
>>>> To shape a cable download link (ifb and tc-mirred setup elided)
>>>>
>>>> tc qdisc add dev ifb0 cake bandwidth 200mbit nat docsis ingress wash
>>>>
>>>> CAKE is filled with:
>>>>
>>>> * A hybrid Codel/Blue AQM algorithm, "Cobalt", tied to an FQ_Codel
>>>>   derived Flow Queuing system, which autoconfigures based on the bandwidth.
>>>> * A novel "triple-isolate" mode (the default) which balances per-host
>>>>   and per-flow FQ even through NAT.
>>>> * An deficit based shaper, that can also be used in an unlimited mode.
>>>> * 8 way set associative hashing to reduce flow collisions to a minimum.
>>>> * A reasonable interpretation of various diffserv latency/loss tradeoffs.
>>>> * Support for zeroing diffserv markings for entering and exiting traffic.
>>>> * Support for interacting well with Docsis 3.0 shaper framing.
>>>> * Extensive support for DSL framing types.
>>>> * Support for ack filtering.
>>>
>>> Why this TCP ACK filtering has to be built into CAKE qdisc rather than
>>> an independent TC filter? Why other qdisc's can't use it?
>>
>> I actually have a tc - bpf based ack filter, during the development of
>> cake's ack-thinner, that I should submit one of these days. It
>> proved to be of limited use.
>
> Yeah.
>
>>
>> Probably the biggest mistake we made is by calling this cake feature a
>> filter. It isn't.
>
>
> It inspects the payload of each packet and drops packets, therefore it
> is a filter by definition, no matter how you name it.

Well, sure, but the distinguishing feature is that it is a *stateful*
filter, whose reaction depends on the current state of the queue.

>> Maybe we should have called it a "thinner" or something like that? In
>> order to properly "thin" or "reduce" an ack stream
>> you have to have a queue to look at and some related state. TC filters
>> do not operate on queues, qdiscs do. Thus the "ack-filter" here is
>> deeply embedded into cake's flow isolation and queue structures.
>
> TC filters are installed on qdiscs and in the beginning qdiscs were
> queues,for example, pfifo. We already have flow-based filters too
> (cls_flower),so we can make them work together, although probably it
> is not straight forward.

Yeah, but filters don't have any visibility into the queue. You could
conceivably amend the TC filter API to allow this, but it would be quite
intrusive, especially for complicated qdiscs.

I'm not opposed to seeing an API change and generalising the CAKE ACK
filter based on it. But that is certainly out of scope for this
submission...

-Toke

Powered by blists - more mailing lists