Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Cong Wang]

On Tue, May 1, 2018 at 12:12 PM, Eric Dumazet  wrote:
>
> I guess that nobody really wants to really review Cake if
> it is a file with 2700 lines of code and hundreds of variables/tunables.
>
> Sure, we have big files in networking land, as a result of thousands of 
> changes.
>
> If you split it, then maybe the work can be split among reviewers as a result.
>

+1

At *least* split it into CAKE without ack-filter and ack-filter implementation.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Toke Høiland-Jørgensen]

Eric Dumazet  writes:

> On 05/01/2018 12:31 PM, Toke Høiland-Jørgensen wrote:
>
>> Could you comment on specifically what you believe is broken in this,
>> please, so I can fix it in the same iteration?
>> 
>
> Apart from the various pskb_may_pull() this helper should not change skb 
> layout.
>
> Ideally, the skb should be const and you would use
> skb_header_pointer() to make clear you do not ever write this skb.
>
> This would make the reviewer job pretty easy, as no side effect can
> possibly happen.

Gotcha. Will fix; thanks :)

-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Eric Dumazet]

On 05/01/2018 12:31 PM, Toke Høiland-Jørgensen wrote:

> Could you comment on specifically what you believe is broken in this,
> please, so I can fix it in the same iteration?
> 

Apart from the various pskb_may_pull() this helper should not change skb layout.

Ideally, the skb should be const and you would use skb_header_pointer() to make 
clear
you do not ever write this skb.

This would make the reviewer job pretty easy, as no side effect can possibly 
happen.


> +static inline struct tcphdr *cake_get_tcphdr(struct sk_buff *skb)
> +{
> + struct ipv6hdr *ipv6h;
> + struct iphdr *iph;
> +
> + /* check IPv6 header size immediately, since for IPv4 we need the space
> +  * for the TCP header anyway
> +  */
> + if (!pskb_may_pull(skb, skb_network_offset(skb) +
> + sizeof(struct ipv6hdr)))
> + return NULL;
> +
> + iph = ip_hdr(skb);
> +
> + if (iph->version == 4) {
> + /* special-case 6in4 tunnelling, as that is a common way to get
> +  * v6 connectivity in the home
> +  */
> + if (iph->protocol == IPPROTO_IPV6) {
> + if (!pskb_may_pull(skb, (skb_network_offset(skb) +
> +  ip_hdrlen(skb) +
> +  sizeof(struct ipv6hdr
> + return NULL;
> +
> + ipv6h = (struct ipv6hdr *)(skb_network_header(skb) +
> +ip_hdrlen(skb));
> +
> + if (ipv6h->nexthdr != IPPROTO_TCP)
> + return NULL;
> +
> + skb_set_inner_network_header(skb,
> +  skb_network_offset(skb) +
> +  ip_hdrlen(skb));
> + skb_set_inner_transport_header(skb,
> + skb_inner_network_offset(skb) +
> + sizeof(struct ipv6hdr));

This is not allowed for a dissector.


___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Toke Høiland-Jørgensen]

Eric Dumazet  writes:

> On 05/01/2018 11:53 AM, Toke Høiland-Jørgensen wrote:
>
>> *sigh* - can do, I guess. Though I'm not sure what that is going to
>> accomplish, exactly?
>
>
> I guess that nobody really wants to really review Cake if
> it is a file with 2700 lines of code and hundreds of variables/tunables.
>
> Sure, we have big files in networking land, as a result of thousands
> of changes.
>
> If you split it, then maybe the work can be split among reviewers as a
> result.
>
> Or maybe David Miller can simply merge your patch as is, and hope for
> the best, I really do not know.
>
> It seems you guys spent years/months on work on this stuff, so what is
> the big deal about presenting your work in the best possible way ?

I was objecting to what felt like an arbitrary moving of goal posts
without an explanation. Now that you give one, that is fine of course.
I'll split it an resubmit.

Could you comment on specifically what you believe is broken in this,
please, so I can fix it in the same iteration?

+static inline struct tcphdr *cake_get_tcphdr(struct sk_buff *skb)
+{
+   struct ipv6hdr *ipv6h;
+   struct iphdr *iph;
+
+   /* check IPv6 header size immediately, since for IPv4 we need the space
+* for the TCP header anyway
+*/
+   if (!pskb_may_pull(skb, skb_network_offset(skb) +
+   sizeof(struct ipv6hdr)))
+   return NULL;
+
+   iph = ip_hdr(skb);
+
+   if (iph->version == 4) {
+   /* special-case 6in4 tunnelling, as that is a common way to get
+* v6 connectivity in the home
+*/
+   if (iph->protocol == IPPROTO_IPV6) {
+   if (!pskb_may_pull(skb, (skb_network_offset(skb) +
+ip_hdrlen(skb) +
+sizeof(struct ipv6hdr
+   return NULL;
+
+   ipv6h = (struct ipv6hdr *)(skb_network_header(skb) +
+  ip_hdrlen(skb));
+
+   if (ipv6h->nexthdr != IPPROTO_TCP)
+   return NULL;
+
+   skb_set_inner_network_header(skb,
+skb_network_offset(skb) +
+ip_hdrlen(skb));
+   skb_set_inner_transport_header(skb,
+   skb_inner_network_offset(skb) +
+   sizeof(struct ipv6hdr));
+
+   } else if (iph->protocol == IPPROTO_TCP) {
+   /* we always set the inner headers so we can use those
+* unconditionally in the filtering logic
+*/
+   skb_set_inner_network_header(skb,
+skb_network_offset(skb));
+   skb_set_inner_transport_header(skb,
+  skb_network_offset(skb) +
+  ip_hdrlen(skb));
+   } else {
+   return NULL;
+   }
+
+   } else if (iph->version == 6) {
+   ipv6h = (struct ipv6hdr *)iph;
+
+   if (ipv6h->nexthdr != IPPROTO_TCP)
+   return NULL;
+
+   /* we always set the inner headers so we can use those
+* unconditionally in the filtering logic
+*/
+   skb_set_inner_network_header(skb,
+skb_network_offset(skb));
+   skb_set_inner_transport_header(skb,
+  skb_network_offset(skb) +
+  sizeof(struct ipv6hdr));
+
+   } else {
+   return NULL;
+   }
+
+   if (!pskb_may_pull(skb, skb_inner_transport_offset(skb) +
+   sizeof(struct tcphdr)) ||
+   !pskb_may_pull(skb, skb_inner_transport_offset(skb) +
+   inner_tcp_hdrlen(skb)))
+   return NULL;
+
+   return inner_tcp_hdr(skb);
+}


Thanks,

-Toke
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Dave Taht]

On Tue, May 1, 2018 at 11:53 AM, Toke Høiland-Jørgensen  wrote:
> Eric Dumazet  writes:
>
>> On 04/30/2018 02:27 PM, Dave Taht wrote:
>>
>>> 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.
>>>
>>> Probably the biggest mistake we made is by calling this cake feature a
>>> filter. It isn't.
>>>
>>> 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.
>>
>> A feature eating packets _is_ a filter.
>>
>> Given that a qdisc only sees one direction, I really do not get why
>> ack-filter is so desirable in a packet scheduler.
>
> The ACK filter in CAKE is there to solve a very particular use case:
> Residential internet connections with bandwidths so asymmetric that it
> hurts TCP performance. It is not on by default; but rather meant to be
> configured by users which suffer from this particular ISP brokenness
> (which, sadly, does happen; there are ISPs who believe a 50/1 bandwidth
> ratio is reasonable). For those users, the ACK filter can help.
>
> We certainly do not advise people to turn it on in the general case! As
> you point, in general TCP performance is best improved in the TCP stack...
>
>> You have not provided any numbers to show how useful it is to maintain
>> this code
>
> You mean apart from that in the linked blog post and the paper?
> Here's an executive summary:
>
> On a 30/1 Mbps connection with a bidirectional traffic test (RRUL),
> turning on the ACK filter improves downstream throughput by ~20% and
> upstream throughput by ~12% in conservative mode and ~40% in aggressive
> mode, at the cost of ~5ms of inter-flow latency due to the increased
> congestion.

On a simulated 50/1 comcast connection, I got double the throughput
on a similar test, with no obvious glitches in the tcp flow, in the early stages
of development.

http://blog.cerowrt.org/post/ack_filtering/

I was very, very dubious about the value of ack thinning until that point,
but it was hard to argue with the data.

> In *really* pathological cases, the effect can be a lot more; for
> instance, the ACK filter increases the achievable downstream throughput
> on a link with 100 Kbps in the upstream direction by an order of
> magnitude (from ~2.5 Mbps to ~25 Mbps).
>
>> (probably still broken btw, considering it is changing some skb
>> attributes).
>
> As you may have noticed over the last few iterations, I've actually been
> trying to fix any brokenness. If you could be specific as to what is
> still broken, that would be helpful.
>
> (I'm assuming are referring to the calls to skb_set_inner* - but do you
> mean all of them, or just the ones that set inner == outer?)
>
>> On wifi (or any half duplex medium), you might gain something by
>> carefully sending ACK not too often, but ultimately this should be
>> done by TCP stack, in well controlled environment [1], instead of
>> middle-boxes happily playing/breaking some Internet standards.
>>
>> [1] TCP stack has the estimations of RTT, RWIN, throughput, and might
>> be able to avoid flooding the network with acks under some conditions.
>
> You are quite right that in general, TCP performance is best improved in
> the TCP stack. But home users are not generally in control of that; the
> ACK filter helps in those specific deployments (again, it's off by
> default, and you shouldn't turn it on in the general case!).
>
>> Say RTT is 100ms, and we receive 1 packet every 100 usec (no GRO
>> aggregation) Maybe we do not really _need_ to send 5000 ack per second
>> (or even 10,000 ack per second if a hole needs a repair)
>
> Yes, please do fix that.

:) I really would like to see cake tested at 10GigE and above, and its
performance improved overall. I tend to think we need more queues than 1024
at 40GigE+, and we presently run out of cpu (even unshaped) long
before we hit that point.

>
>> Also on wifi, the queue builds in the driver queues anyway, not in the
>> qdisc.
>
> Actually, we've fixed that (for some drivers); there is now no qdisc on
> WiFi interfaces, and we've integrated FQ-CoDel'ed queueing into the
> stack where it can be effective. But no, running CAKE with an ACK filter
> on a WiFi link is not going to be effective. Don't do that.

I share the belief with eric that thinning acks (either at the wifi qdisc or
in tcp) on wifi interfaces will help - given that the underlying wifi layer
is reliable and does retransmits, and the number of packets that can
fit into a wifi aggregate limited,
you really only need one ack per wifi aggregate per flow to keep the
tcp connection running.

That said, I'd much rather see fq_codel work with more wifi 

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[David Miller]

From: Eric Dumazet 
Date: Tue, 1 May 2018 12:12:45 -0700

> It seems you guys spent years/months on work on this stuff, so what
> is the big deal about presenting your work in the best possible way
> ?

+1
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Jonathan Morton]

> On 1 May, 2018, at 7:06 pm, Eric Dumazet  wrote:
> 
> You have not provided any numbers to show how useful it is to maintain this
> code (probably still broken btw, considering it is changing some skb 
> attributes).

A simple calculation shows what the maximum tolerable asymmetry for a 
conventional TCP connection is.  If the MTU is 1500, a pure ack is 84 bytes, 
and an ack is sent for every 3 packets received, bandwidth asymmetry exceeding 
about 50:1 will inevitably result in the inability to fully utilise downstream 
bandwidth.  This ratio drops to 34:1 if acks are sent every two data packets, 
and 17:1 for the RFC-mandated "ack every packet" behaviour when loss is 
detected.

Physical asymmetry ratios exceeding 20:1 are not rare.  They are increased 
still further if reverse traffic is present; given a nominal 10:1 asymmetry, 
interleaving one ack with one MTU packet (as SFQ would) gives an *effective* 
asymmetry for the downstream flow of 188:1, and seriously affects downstream 
goodput.

High asymmetry ratios can be tolerated by TCPs implementing sparser acks than 
1:3 ratios, as proposed in AckCC.  Without AckCC however, I understand a strict 
reading of the RFCs prohibits TCPs from going beyond 1:3.  Even if Linux TCPs 
do so anyway, billions of Windows, Mac and mobile hosts most likely will not.  
This makes a solely end-to-end solution impractical for the time being, with no 
obvious hope of improvement.

To maintain downstream goodput under these conditions, it is either necessary 
to send bursts of acks between the upstream traffic (which is slightly wasteful 
of bandwidth and also upsets RTT-sensitive TCPs like BBR) - which Cake will do 
quite happily if the ack-filter is disabled - or to delete some of the acks.  
When there are many upstream flows competing with a single ack flow, the latter 
is the only reasonable solution unless acks are hard-prioritised (which has 
negative effects of its own, so we didn't consider it).

Middleboxes *are* permitted to drop packets, and AQM routinely does so.  We 
found that AQM could delete acks beneficially, but that it ramped up too slowly 
to really solve the problem (acks being individually small, much larger numbers 
of them must be dropped once they become a saturating flow, compared to a data 
flow).  Also, ack flows are often *antiresponsive*, in that dropping some of 
them causes an increase in their arrival rate due to increasing the ack-clocked 
downstream traffic, so it should be moderately obvious that conventional AQM 
strategies don't apply.  We also looked at existing ack filters' behaviour and 
found it wanting, so we were initially reluctant to implement our own.

However, having seen many counterexamples of how *not* to write an ack filter, 
we were eventually able to write one that *didn't* break the rules, and ensured 
that the information TCP relies on remained in acks that were not deleted even 
when many acks were.  This includes preserving the triple-repetition rule for 
detecting packet loss, and preserving the tail ack signifying reception of the 
end of a flow - which naturally results in only dropping acks if it's 
worthwhile to do so.  In short, we're fully aware of the potential for breaking 
TCP this way, and we've done our level best to avoid it.

Testing revealed an appreciable, simultaneous improvement in both downstream 
and upstream goodput, and in the downstream flow's internal RTT, under 
appropriate traffic conditions.  A more aggressive variant, going to the edges 
of what might be allowed by RFCs, actually showed *less* improvement than the 
standard one - it interfered with TCP's behaviour too much.  We can dig up the 
data if required.

> Also on wifi, the queue builds in the driver queues anyway, not in the qdisc.
> So ACK filtering, if _really_ successful, would need to be modularized.

Agree that the wifi queues would also benefit from ack filtering.  In fact, 
with make-wifi-fast improvements active, installing Cake or any other qdisc on 
that interface should be unnecessary.  Cake's shaper can't easily adapt to 
variable-rate links on the timescales required, anyway.  (It could if something 
told it directly about the variations.)

However, I don't see a way to install the ack-filter as a separate entity in 
its own right, without the ability to manipulate the queue downstream of 
itself.  The arrival of a new ack may trigger the deletion of a previous one, 
never the one just arrived, yet keeping an internal queue of acks within the 
filter would be counterproductive.  That's why we implemented it within Cake 
instead of as a separate thing.

It may be possible to modularise it sufficiently that qdiscs could add support 
for ack-filtering without duplicating the code, rather than the other way 
around.  This would also allow wifi queues to be modified the same way.  Would 
that be acceptable?

 - Jonathan Morton

___
Cake mailing list

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Eric Dumazet]

On 04/30/2018 02:27 PM, Dave Taht wrote:

> 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.
> 
> Probably the biggest mistake we made is by calling this cake feature a
> filter. It isn't.
> 
> 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.

A feature eating packets _is_ a filter.

Given that a qdisc only sees one direction, I really do not get why ack-filter
is so desirable in a packet scheduler.

You have not provided any numbers to show how useful it is to maintain this
code (probably still broken btw, considering it is changing some skb 
attributes).

On wifi (or any half duplex medium), you might gain something by carefully
sending ACK not too often, but ultimately this should be done by TCP stack,
in well controlled environment [1], instead of middle-boxes happily 
playing/breaking
some Internet standards.

[1] TCP stack has the estimations of RTT, RWIN, throughput, and might be able to
avoid flooding the network with acks under some conditions.

Say RTT is 100ms, and we receive 1 packet every 100 usec (no GRO aggregation)
Maybe we do not really _need_ to send 5000 ack per second 
(or even 10,000 ack per second if a hole needs a repair)

Also on wifi, the queue builds in the driver queues anyway, not in the qdisc.
So ACK filtering, if _really_ successful, would need to be modularized.

Please split Cake into a patch series.
Presumably putting the ack-filter on a patch of its own.



___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Toke Høiland-Jørgensen]

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  wrote:
>>> On Sun, Apr 29, 2018 at 2:34 PM, Toke Høiland-Jørgensen  
>>> 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
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Cong Wang]

On Sun, Apr 29, 2018 at 2:34 PM, Toke Høiland-Jørgensen  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?


> * Extensive statistics for measuring, loss, ecn markings, latency
>   variation.
>
> A paper describing the design of CAKE is available at
> https://arxiv.org/abs/1804.07617
>

Thanks.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc

[Cong Wang]

On Mon, Apr 30, 2018 at 2:27 PM, Dave Taht  wrote:
> On Mon, Apr 30, 2018 at 2:21 PM, Cong Wang  wrote:
>> On Sun, Apr 29, 2018 at 2:34 PM, Toke Høiland-Jørgensen  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.

>
> 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.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake