I have found this to be a bit aggressive when the MTU is large (for example, the MTU of the loopback device is 65536 bytes). In such scenarios, every other received segment can be significantly different from every two full-size segments. In short, this can result in too many or too frequent ACKs being sent.
An ACK SHOULD be generated for at least every second full-sized segment or 2*RMSS bytes of new data (where RMSS is the MSS specified by the TCP endpoint receiving the segments to be acknowledged, or the default value if not specified) (SHLD-19).
However, note that the RFC above only says "at least 2*RMSS bytes", which is not a hard requirement. In practice, I think that it is reasonable to follow the Linux kernel's empirical value of sending an ACK for every RMSS byte of new data. The Linux kernel implementation can be found here:
/* More than one full frame received... */
if (((tp->rcv_nxt - tp->rcv_wup) > inet_csk(sk)->icsk_ack.rcv_mss &&
Previously, we let the delayed ACK timer expire and sent an immediate ACK for every other segment received, as described in the following comments: https://github.com/smoltcp-rs/smoltcp/blob/45fa98422b581128591cf18fee659a3db47e8d4f/src/socket/tcp.rs#L2067-L2073
I have found this to be a bit aggressive when the MTU is large (for example, the MTU of the loopback device is 65536 bytes). In such scenarios, every other received segment can be significantly different from every two full-size segments. In short, this can result in too many or too frequent ACKs being sent.
Acroding to the latest RFC, RFC 9293 states:
However, note that the RFC above only says "at least 2*RMSS bytes", which is not a hard requirement. In practice, I think that it is reasonable to follow the Linux kernel's empirical value of sending an ACK for every RMSS byte of new data. The Linux kernel implementation can be found here: