Re: [Bloat] benefits of ack filtering

[Eric Dumazet <eric.dumazet@gmail.com>]

On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote:
> On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet <eric.dumazet@gmail.com
> > 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, because it might need an additional
> > timer, and we were reluctant adding extra complexity for that.
> 
> How about just using the existing delayed ACK timer, and just making
> the delayed ACK logic a bit smarter? We could try using the existing
> logic and timers, but using something adaptive instead of the magic
> "2" MSS received to force an ACK.

Keep in mind some distros have HZ=250 or even HZ=100

So even a 'one jiffie' timer could add 10ms delay.

That is why I believe only a hrtimer could be used (and that would
imply CONFIG_HIGH_RES_TIMERS=y )

I am waiting for Anna-Maria Gleixner work (  hrtimer: Provide softirq
context hrtimers ) so that we can avoid a trip through a tasklet.

>  
> > An additional point where huge gains are possible is to add TSO
> > autodefer while in recovery. Lacking TSO auto defer explains why
> > TCP
> > flows enter a degenerated behavior, re-sending 1-MSS packets in
> > response to SACK flood.
> 
> Yes, agreed. I suspect there is some simple heuristic that could be
> implemented to allow TSO deferral for most packets sent in recovery.
> For example, allowing TSO deferral once the number of packet bursts
> (TSO skbs) sent in recovery is greater than some threshold. Perhaps
> TSO deferral would be fine in Recovery if we have sent, say, 10 skbs,
> because at that point if the ACK stream from the original flight
> dries up due to massive/tail loss, we have probably sent enough data
> in the new flight in Recovery to ensure some kind of ACKs come back
> to keep the ACK clock going.
> 
> neal
>  
> > 
> > On Thu, 2017-11-30 at 09:48 +0200, Jonathan Morton wrote:
> > > 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.  For this purpose, having the
> > receiver
> > > emit sparser but still regularly spaced acks would be better than
> > > having some middlebox delete some less-predictable subset of
> > them. 
> > > So I think BBR could be a good testbed for AckCC implementation,
> > > especially as it is inherently paced and thus doesn't suffer from
> > > burstiness as a conventional ack-clocked TCP might.
> > > The real trouble with AckCC is that it requires implementation on
> > the
> > > client as well as the server.  That's most likely why Google
> > hasn't
> > > tried it yet; there are no receivers in the wild that would give
> > them
> > > valid data on its effectiveness.  Adding support in Linux would
> > help
> > > here, but aside from Android devices, Linux is only a relatively
> > > small proportion of Google's client traffic - and Android devices
> > are
> > > slow to pick up new kernel features if they can't immediately
> > turn it
> > > into a consumer-friendly bullet point.
> > > Meanwhile we have highly asymmetric last-mile links (10:1 is
> > typical,
> > > 50:1 is occasionally seen), where a large fraction of upload
> > > bandwidth is occupied by acks in order to fully utilise the
> > download
> > > bandwidth in TCP.  Any concurrent upload flows have to compete
> > with
> > > that dense ack flow, which in various schemes is unfair to either
> > the
> > > upload or the download throughput.
> > > That is a problem as soon as you have multiple users on the same
> > > link, eg. a family household at the weekend.  Thinning out those
> > acks
> > > in response to uplink congestion is a solution.  Maybe not the
> > best
> > > possible solution, but a deployable one that works.
> > > - Jonathan Morton
> > > _______________________________________________
> > > Bloat mailing list
> > > Bloat@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/bloat
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> > 
> 
>