Re: [Bloat] benefits of ack filtering

2017-11-30 Thread Jan Ceuleers
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. ___

Re: [Bloat] benefits of ack filtering

2017-11-30 Thread David Lang
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

Re: [Bloat] Bufferbloat in high resolution + non-stationarity

2017-11-30 Thread Jonathan Morton
Cake already supports treating CS1 as less-than-besteffort by default. Adding more codepoints to that list is easy. The trick is getting applications to actually use them. That's a chicken-egg problem. - Jonathan Morton ___ Bloat mailing list

Re: [Bloat] Bufferbloat in high resolution + non-stationarity

2017-11-30 Thread Mikael Abrahamsson
On Thu, 30 Nov 2017, Jonathan Morton wrote: I submit that to provide *deployable* QoS schemes, you must either solve the classification problem elegantly (which is a Hard Problem), or else show that your scheme works adequately in the absence of classification. I'm taking the latter approach

Re: [Bloat] Bufferbloat in high resolution + non-stationarity

2017-11-30 Thread Jonathan Morton
A central assumption in all of your references so far is that the relevant traffic classes can be distinguished reliably in realtime and sent to appropriate queues. There is no fallback mechanism given for any cases where this assumption is false - the queue within each class is a FIFO, which as

Re: [Bloat] benefits of ack filtering

2017-11-30 Thread Neal Cardwell
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 >

Re: [Bloat] benefits of ack filtering

2017-11-30 Thread Eric Dumazet
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 > >

Re: [Bloat] benefits of ack filtering

2017-11-30 Thread Eric Dumazet
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

2017-11-30 Thread Neal Cardwell
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

Re: [Bloat] benefits of ack filtering

2017-11-30 Thread Mikael Abrahamsson
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

Re: [Bloat] Bufferbloat in high resolution + non-stationarity

2017-11-30 Thread Neil Davies
The key design goal was to create assured bounds on loss and delay for designated classes during extended periods of load saturation. The mechanisms, to some extent, are not the issue - the ability configure it and know a-prori (to a given error bound) what would happen to the traffic flows

Re: [Bloat] benefits of ack filtering

2017-11-30 Thread Eric Dumazet
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

2017-11-30 Thread Luca Muscariello
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: >