From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.toke.dk (mail.toke.dk [IPv6:2001:470:dc45:1000::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B6BA23BA8E for ; Tue, 1 May 2018 07:36:19 -0400 (EDT) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1525174577; bh=cSCjK18VY7IqefSyIvIX0a+BPsJ9lwR2dD4MzFETTqc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=O5YDI+A+peP7jhyM0w83+GkOsBYZrhcqVMAm5QYNxPZTwXWO6nY+ZJa3NmbCmgc23 1xHVlQ8cAWwLEcaLZgCvG9+pX26JdnYRQKkL5r7SHrHW225/cC8kFtj84QcfQ9q0Uj IqCuFmSkCU9ktNRjJcFUZ6w2x6JDVxU+KGhw1ZqPGaDPngbHhn6dKvBHm7KA8bzrEJ 9EGqQDiTYOfs2TGrVmDuZpKKlfRk1bicIZtEDot9evzW8EciYVS7sluuFbssiEXXAk T4456Smja0oqRl/Cv6TFHp4MPT3eMZ7UqV5Qz8QEI603pSZCTbrrWb0hz51UD49dzV 0A/7ZxO6sikbQ== To: Cong Wang , Dave Taht Cc: Linux Kernel Network Developers , Cake List In-Reply-To: References: <20180429213439.7389-1-toke@toke.dk> Date: Tue, 01 May 2018 13:36:16 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <8736zb38wf.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 11:36:20 -0000 Cong Wang writes: > On Mon, Apr 30, 2018 at 2:27 PM, Dave Taht wrote: >> On Mon, Apr 30, 2018 at 2:21 PM, Cong Wang wr= ote: >>> On Sun, Apr 29, 2018 at 2:34 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >>>> sch_cake targets the home router use case and is intended to squeeze t= he >>>> most bandwidth and latency out of even the slowest ISP links and route= rs, >>>> while presenting an API simple enough that even an ISP can configure i= t. >>>> >>>> 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 bandw= idth. >>>> * 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 tradeof= fs. >>>> * Support for zeroing diffserv markings for entering and exiting traff= ic. >>>> * 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