On Thu, Dec 12, 2019 at 5:46 PM Eric Dumazet [off-list ref] wrote:

On 12/12/19 4:59 PM, Simon Barber wrote:

quoted

I’m currently adding ACK thinning to Linux’s GRO code. Quite a simple addition given the way that code works.

Simon

Please don't.

1) It will not help since many NIC  do not use GRO.

2) This does not help if you receive one ACK per NIC interrupt, which is quite common.

Packets accumulate in the wifi device and driver, if that's the bottleneck.

3) This breaks GRO transparency.

4) TCP can implement this in a more effective/controlled way,
   since the peer know a lot more flow characteristics.

Middle-box should not try to make TCP better, they usually break things.

I generally have more hope for open source attempts at this than other
means. And there isn't much left
in TCP that will change in the future; it is an ossified protocol.

802.11n, at least, has a problem fitting many packets into an
aggregate. Sending less packets is a win
in multiple ways:

A) Improves bi-directional throughput
B) Reduces the size of the receivers txop (and retries) - the client
is also often running at a lower rate than
the ap.
C) Delivers the most current ack, sooner

When further transiting an aqm that uses random numbers, it hits the
right packet sooner, also.

I welcome experimentation in this area.



-- 
Make Music, Not War

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-435-0729