On Wed, Nov 29, 2017 at 3:31 PM, Mikael Abrahamsson <swmike@swm.pp.se> 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 3449 ?
https://tools.ietf.org/html/rfc3449#section-5.2.1

RFC3449 is all about middleboxes doing things.

I wanted to understand why TCP implementations find it necessary to send one ACK per 2xMSS at really high PPS. Especially when NIC offloads and middleboxes frequently strip out this information anyway so it never reaches the IP stack (right?).

I would say because it is complex to guess at which PPS to work. You would need an adaptation mechanism. Need also to change the client and the server sides. The AckCC Jonathan has mentioned

might be a solution to that.

Probably an ACK pacer in the end host, out of the TCP stack, doing Ack filtering and decimation can be simpler to implement than the proper adaptation mechanism in TCP.

Maybe inside sch_fq it would be doable. Maybe not.