[e2e] ACK on PUSH?

[Charles M. Hannum]

On Friday 06 August 2004 04:47, Sam Manthorpe wrote:
> There has to be a good reason for this, but does anyone
> know why it is that the two TCP stacks I use regularly don't
> seem to a force an ACK when they receive a data packet
> with PUSH flagged? (as opposed to doing delayed ack).

This is something I implemented in 1994 (and which was copied by many people 
after that) because it fixed a very nasty performance problem with some 
applications.  Later on it was decided to solve the same problem by instead 
castrating delayed ACK and forcing an immediate ACK on every other packet.


As I wrote on comp.protocols.tcp-ip at the time (in 1994):

I've found a problem with the TCP delayed ack algorithm.  If the writer's
buffer becomes full before sending an entire window, the writer will stop
and the ack will be delayed and the transmission will be stalled pending
a timeout on (and transmission of) the delayed ack.

As an experiment, I've applied the following patch to my (NetBSD) kernel,
and it alleviates the problem.

The worst case for this change is that the writer sets the PSH bit on
every outgoing packet, in which case delayed ack is effectively disabled.
This is not an issue of correctness, however, and since most vendors use
the PSH bit a bit more intelligently, it doesn't seem like a serious
problem.