Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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.
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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.
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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 drivers than pursue this. > >> So ACK f
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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 ? Thanks.
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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. 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. > 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. > So ACK filtering, if _really_ successful, would need to be > modularized. I really hope ACK filtering won't be "_really_ successful". Again, it is not meant to be a feature that's on everywhere, it's targeting a very specific use case that CAKE is optimised for: The home router use case. > Please split Cake into a patch series. > Presumably putting the ack-filter on a patch of its own. *sigh* - can do, I guess. Though I'm not sure what that is going to accomplish, exactly? -Toke
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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.
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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.
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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. 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. > > >> * 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. -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619
Re: [PATCH net-next v6] Add Common Applications Kept Enhanced (cake) qdisc
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.
