Re: [Bloat] benefits of ack filtering

If I understand the patch well, the ack filter is actually fixing the problem of ACK compression only. Because it is enforced on packets in the queue only. It is stateless. ACK compression would happen even w/o highly asymmetric access links by just having concurrent data streams with ack streams.

Re: [Bloat] benefits of ack filtering

Hi Mikael, > On Dec 13, 2017, at 10:46, Mikael Abrahamsson wrote: > > On Wed, 13 Dec 2017, Jonathan Morton wrote: > >> the uplink shaper is set to about a fiftieth of that. I seriously doubt >> that DOCSIS is ever inherently that asymmetric. > > Well, the products are, because that's what

Re: [Bloat] benefits of ack filtering

Okay, from the tables on that page, it seems that the most asymmetric maximal configuration is below 8:1. That's in line with what you'd expect given transmit power and thus SNR differences. Hence no legitimate reason to provision at 42:1 and above... - Jonathan Morton __

Re: [Bloat] benefits of ack filtering

> On Dec 13, 2017, at 11:03, Jonathan Morton wrote: > > Forgive my ignorance, but does each channel have the same capacity in both > directions in DOCSIS? A quick look at https://en.wikipedia.org/wiki/DOCSIS seems to reveal that there typically is higher capacity for each downstream versus ea

Re: [Bloat] benefits of ack filtering

Forgive my ignorance, but does each channel have the same capacity in both directions in DOCSIS? - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] benefits of ack filtering

On Wed, 13 Dec 2017, Jonathan Morton wrote: the uplink shaper is set to about a fiftieth of that. I seriously doubt that DOCSIS is ever inherently that asymmetric. Well, the products are, because that's what the operators seems to want, probably also because that's what the customers demand.

Re: [Bloat] benefits of ack filtering

Actually, the cost argument goes the other way. You need heavy DSP to *receive* high bandwidths; sending it is much easier computationally. Also, in aggregate a hundred cheap CPE boxes probably have more DSP horsepower than the one head-end box serving them. What the centralised head-end has an a

Re: [Bloat] benefits of ack filtering

On Wed, 13 Dec 2017, Jonathan Morton wrote: The one "correct" argument against ack-filtering I've seen is that it encourages (or rather validates) the use of extreme asymmetry ratios. I would sure rather have a extremely asymmetric ration than a 'proper' ratio with the same upstream bandwidth

Re: [Bloat] benefits of ack filtering

The one "correct" argument against ack-filtering I've seen is that it encourages (or rather validates) the use of extreme asymmetry ratios. However, these extreme ratios are already in widespread use without the aid of ack-filtering. Even ADSL2 Annex A has, as its "ideal" sync rate, a 16:1 ratio,

Re: [Bloat] benefits of ack filtering

Taking into account a variety of scenarios, I have difficulty identifying a case where an ack deleted by a reasonably conservative algorithm would have given any practical benefit had it remained, *including* considerations of smoothness of ack-clocking. If the uplink isn't congested then no delet

Re: [Bloat] benefits of ack filtering

On Tue, 12 Dec 2017, Benjamin Cronce wrote: I do not feel that thinning ACKs gains much for any healthy ratio of down:up. The overhead of those "wasteful" ACKs are on par with the overhead of IP+TCP headers. assuming that there was no traffic going the other way to compete with the acks. Any

Re: [Bloat] benefits of ack filtering

What kicked off this thread was my urge to get a little code review of https://github.com/dtaht/sch_cake/blob/cobalt/sch_cake.c#L904 because it seems to work well in a variety of tests, and ever better as your D/U ratio cracks 10/1. There are a few things I don't like about the implementation:

Re: [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 10:50 AM, Sebastian Moeller wrote: > Hi Mikael, > > > > On Nov 29, 2017, at 13:49, Mikael Abrahamsson wrote: > > > > On Wed, 29 Nov 2017, Sebastian Moeller wrote: > > > >> Well, ACK filtering/thinning is a simple trade-off: redundancy versus > bandwidth. Since the RFCs sa

Re: [Bloat] benefits of ack filtering

I wonder if TCP could be effectively changed to send an ACK every WindowSize/N number of packets. We'd need to be careful about how this would affect 'slow start'. On Wed, Nov 29, 2017 at 12:09 AM, Mikael Abrahamsson wrote: > On Tue, 28 Nov 2017, Dave Taht wrote: > > Recently Ryan Mounce added a

Re: [Bloat] benefits of ack filtering

While I haven't yet studied the ack filtering code in depth, Ryan indicated that some of those concerns were considered in its design. In particular, it won't ever delete the last remaining ack in a flow's queue, only replace it with a more recently arrived one. That should take care of interacti

Re: [Bloat] benefits of ack filtering

> Recently Ryan Mounce added ack filtering cabilities to the cake qdisc. > The benefits were pretty impressive at a 50x1 Down/Up ratio: If I read this posting right, you're only measuring bulk performance. What about interactive traffic, when there's only one or two data segments in flight at a gi

Re: [Bloat] benefits of ack filtering

> The better solution would of course be to have the TCP peeps change the > way TCP works so that it sends fewer ACKs. Which tends to perturb the way the TCP self-clocking feedback loop works, and to break Nagle. > In the TCP implementations I tcpdump regularily, it seems they send one > ACK per

Re: [Bloat] benefits of ack filtering

RFC 5690 and http://www.saber.ula.ve/bitstream/123456789/30345/1/thesis-francais-english.pdf Ch 4 and 5 regards a. > On 29 Nov 2017, at 14:36, Jonathan Morton wrote: > > There is an RFC about emitting fewer ac

Re: [Bloat] benefits of ack filtering

>> It does increase single-flow TCP throughput by up to a factor of two, >> though... Which everyone knows is the most important benchmark number ;) > Were you always as cynical as I am? (Giggle) Dave, you've always underestimated Toke ;-) ___ Bloat ma

Re: [Bloat] benefits of ack filtering

On Fri, Dec 1, 2017 at 10:57 AM, Luca Muscariello wrote: > https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html > Good news all over. I wonder what happens on cisco against the suite of tests toke made available here: https://www.cs.kau.se/to

Re: [Bloat] benefits of ack filtering

https://www.cisco.com/c/en/us/products/collateral/wireless/aironet-3700-series/white-paper-c11-735947.html On Fri 1 Dec 2017 at 19:43, Dave Taht wrote: > Luca Muscariello writes: > > > For highly asymmetric links, but also shared media like wifi, QUIC might > be a > > better playground for opt

Re: [Bloat] benefits of ack filtering

Luca Muscariello writes: > For highly asymmetric links, but also shared media like wifi, QUIC might be a > better playground for optimisations. > Not pervasive as TCP though and maybe off topic in this thread. I happen to really like QUIC, but a netperf-style tool did not exist for it when I las

Re: [Bloat] benefits of ack filtering

Toke Høiland-Jørgensen writes: > Luca Muscariello writes: > >> If I understand the text right, FastACK runs in the AP and generates an ACK >> on behalf (or despite) of the TCP client end. >> Then, it decimates dupACKs. >> >> This means that there is a stateful connection tracker in the AP. Not s

Re: [Bloat] benefits of ack filtering

Luca Muscariello writes: > If I understand the text right, FastACK runs in the AP and generates an ACK > on behalf (or despite) of the TCP client end. > Then, it decimates dupACKs. > > This means that there is a stateful connection tracker in the AP. Not so > simple. > It's almost, not entirely t

Re: [Bloat] benefits of ack filtering

If I understand the text right, FastACK runs in the AP and generates an ACK on behalf (or despite) of the TCP client end. Then, it decimates dupACKs. This means that there is a stateful connection tracker in the AP. Not so simple. It's almost, not entirely though, a TCP proxy doing Split TCP. On

Re: [Bloat] benefits of ack filtering

Jan Ceuleers writes: > On 01/12/17 01:28, David Lang wrote: >> Stop thinking in terms of single-flow benchmarks and near idle >> 'upstream' paths. > > Nobody has said it so I will: on wifi-connected endpoints the upstream > acks also compete for airtime with the downstream flow. There's a relate

Re: [Bloat] benefits of ack filtering

For highly asymmetric links, but also shared media like wifi, QUIC might be a better playground for optimisations. Not pervasive as TCP though and maybe off topic in this thread. If the downlink is what one want to optimise, using FEC in the downstream, in conjunction with flow control could be ve

Re: [Bloat] benefits of ack filtering

Hi All, you do realize that the worst case is going to stay at 35KPPS? If we assume simply that the 100Mbps download rate is not created by a single flow but by many flows (say 70K flows) the discussed ACK frequency reduction schemes will not work that well. So ACK thinning is a nice optimizati

Re: [Bloat] benefits of ack filtering

On 01/12/17 01:28, David Lang wrote: > Stop thinking in terms of single-flow benchmarks and near idle > 'upstream' paths. Nobody has said it so I will: on wifi-connected endpoints the upstream acks also compete for airtime with the downstream flow. ___ B

Re: [Bloat] benefits of ack filtering

35K PPS of acks is insane, one ack every ms is FAR more than enough to do 'fast recovery', and outside the datacenter, one ack per 10ms is probably more than enough. Assuming something that's not too assymetric, thinning out the acks may not make any difference in the transfer rate of a single

Re: [Bloat] benefits of ack filtering

On Thu, Nov 30, 2017 at 10:55 AM, Eric Dumazet wrote: > On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote: > > On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet > > wrote: > > > I agree that TCP itself should generate ACK smarter, on receivers > > > that > > > are lacking GRO. (TCP sends at mos

Re: [Bloat] benefits of ack filtering

On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote: > On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet > wrote: > > I agree that TCP itself should generate ACK smarter, on receivers > > that > > are lacking GRO. (TCP sends at most one ACK per GRO packets, that > > is > > why we did not feel an ur

Re: [Bloat] benefits of ack filtering

On Thu, 2017-11-30 at 14:04 +0100, Mikael Abrahamsson wrote: > On Thu, 30 Nov 2017, Eric Dumazet wrote: > > > I agree that TCP itself should generate ACK smarter, on receivers > > that  > > are lacking GRO. (TCP sends at most one ACK per GRO packets, that > > is why  > > we did not feel an urgent

Re: [Bloat] benefits of ack filtering

On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet wrote: > I agree that TCP itself should generate ACK smarter, on receivers that > are lacking GRO. (TCP sends at most one ACK per GRO packets, that is > why we did not feel an urgent need for better ACK generation) > > It is actually difficult task, b

Re: [Bloat] benefits of ack filtering

On Thu, 30 Nov 2017, Eric Dumazet wrote: I agree that TCP itself should generate ACK smarter, on receivers that are lacking GRO. (TCP sends at most one ACK per GRO packets, that is why we did not feel an urgent need for better ACK generation) Could you elaborate a bit more on the practical im

Re: [Bloat] benefits of ack filtering

I agree that TCP itself should generate ACK smarter, on receivers that are lacking GRO. (TCP sends at most one ACK per GRO packets, that is why we did not feel an urgent need for better ACK generation) It is actually difficult task, because it might need an additional timer, and we were reluctant

Re: [Bloat] benefits of ack filtering

Agree and think this is a lucid analysis of the problem(s) and solution(s). But, what can be done to let clients upgrade orders of magnitude faster than today? Move transport in user space inside the app? Else? On Thu, Nov 30, 2017 at 8:48 AM, Jonathan Morton wrote: > I do see your arguments

Re: [Bloat] benefits of ack filtering

I do see your arguments. Let it be known that I didn't initiate the ack-filter in Cake, though it does seem to work quite well. With respect to BBR, I don't think it depends strongly on the return rate of acks in themselves, but rather on the rate of sequence number advance that they indicate. F

Re: [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 11:03 PM, Michael Welzl wrote: > Hi Bloaters, > > I’d like to give offer some information and thoughts on AckCC, at the bottom > of this email. > > > On Nov 29, 2017, at 4:53 PM, Luca Muscariello > wrote: > > > > On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson > wrote

Re: [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 11:03 PM, Michael Welzl wrote: > Hi Bloaters, > > I’d like to give offer some information and thoughts on AckCC, at the bottom > of this email. > > > On Nov 29, 2017, at 4:53 PM, Luca Muscariello > wrote: > > > > On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson > wrote

Re: [Bloat] benefits of ack filtering

Hi Bloaters, I’d like to give offer some information and thoughts on AckCC, at the bottom of this email. > On Nov 29, 2017, at 4:53 PM, Luca Muscariello > wrote: > > > > On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson > wrote: > On Wed, 29 Nov 2017, Luca Musca

Re: [Bloat] benefits of ack filtering

On Wed, 2017-11-29 at 15:59 -0800, Stephen Hemminger wrote: > On Wed, 29 Nov 2017 10:41:41 -0800 > Dave Taht wrote: > > > On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek > > wrote: > > > > The better solution would of course be to have the TCP peeps > > > > change the > > > > way TCP works

Re: [Bloat] benefits of ack filtering

On Wed, 29 Nov 2017 10:41:41 -0800 Dave Taht wrote: > On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek wrote: > >> The better solution would of course be to have the TCP peeps change the > >> way TCP works so that it sends fewer ACKs. > > > > Which tends to perturb the way the TCP self-clo

Re: [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 10:41:41AM -0800, Dave Taht wrote: > Linux TCP is no longer particularly ack-clocked. In the post pacing, > post sch_fq world, packets are released (currently) on a 1ms schedule. Most Linux hosts don't run sch_fq, though. I mean, it's not even default in a 4.15 kernel. /*

Re: [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 10:28 AM, Juliusz Chroboczek wrote: >> Recently Ryan Mounce added ack filtering cabilities to the cake qdisc. >> The benefits were pretty impressive at a 50x1 Down/Up ratio: > > If I read this posting right, you're only measuring bulk performance. > What about interactive t

Re: [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek wrote: >> The better solution would of course be to have the TCP peeps change the >> way TCP works so that it sends fewer ACKs. > > Which tends to perturb the way the TCP self-clocking feedback loop works, > and to break Nagle. Linux TCP is no

Re: [Bloat] benefits of ack filtering

Hi Mikael, > On Nov 29, 2017, at 13:49, Mikael Abrahamsson wrote: > > On Wed, 29 Nov 2017, Sebastian Moeller wrote: > >> Well, ACK filtering/thinning is a simple trade-off: redundancy versus >> bandwidth. Since the RFCs say a receiver should acknoledge every second full >> MSS I think the de

Re: [Bloat] benefits of ack filtering

Given an RTT estimate and knowledge of the congestion window, the AckCC option could be used to target a handful of acks (maybe 4 to 10) per RTT. As usual, extra acks would be sent when loss is suspected, on ECN events, and when the push flag is set. That would be perfectly sufficient. - Jonathan

Re: [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson wrote: > On Wed, 29 Nov 2017, Luca Muscariello wrote: > > Why does it say to do this? What benefit is there to either end system to >>> send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP >>> transfer? >>> >> >> Did you check RFC

Re: [Bloat] benefits of ack filtering

There is an RFC about emitting fewer acks in response to upstream congestion or some other cue; AckCC might be the name. - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] benefits of ack filtering

On Wed, 29 Nov 2017, Luca Muscariello wrote: Why does it say to do this? What benefit is there to either end system to send 35kPPS of ACKs in order to facilitate a 100 megabyte/s of TCP transfer? Did you check RFC 3449 ? https://tools.ietf.org/html/rfc3449#section-5.2.1 RFC3449 is all about

Re: [Bloat] benefits of ack filtering

Did you check RFC 3449 ? https://tools.ietf.org/html/rfc3449#section-5.2.1 It would be interesting to know what is the minimum ACK rate to achieve full utilisation. Or the how the downlink rate depends on the uplink ACK rate. I'm sure I've seen this dependency in some old paper. On Wed, Nov 29,

Re: [Bloat] benefits of ack filtering

On Wed, 29 Nov 2017, Sebastian Moeller wrote: Well, ACK filtering/thinning is a simple trade-off: redundancy versus bandwidth. Since the RFCs say a receiver should acknoledge every second full MSS I think the decision whether to filter or not should be kept to Why does it say to do this? What

Re: [Bloat] benefits of ack filtering

Well, ACK filtering/thinning is a simple trade-off: redundancy versus bandwidth. Since the RFCs say a receiver should acknoledge every second full MSS I think the decision whether to filter or not should be kept to the enduser and not some misguided middle boxes; if a DOCSIS ISP wants to secure

Re: [Bloat] benefits of ack filtering

On Tue, 28 Nov 2017, Dave Taht wrote: Recently Ryan Mounce added ack filtering cabilities to the cake qdisc. The benefits were pretty impressive at a 50x1 Down/Up ratio: http://blog.cerowrt.org/post/ack_filtering/ And quite noticeable at 16x1 ratios as well. I'd rather like to have a compell

[Bloat] benefits of ack filtering

Recently Ryan Mounce added ack filtering cabilities to the cake qdisc. The benefits were pretty impressive at a 50x1 Down/Up ratio: http://blog.cerowrt.org/post/ack_filtering/ And quite noticeable at 16x1 ratios as well. I'd rather like to have a compelling list of reasons why not to do this! A