On Mon, 4 May 1998 03:32:57 -0500 (CDT) 
 Jeff Thieleke <thieleke@iafalls.com> wrote:

 > Am I correct in assuming that the new 'ack_on_push' sysctl is mainly useful
 > for increasing interactive (i.e. telnet) responsiveness?  

Actually, it will roughly double the packet count with telnet; telnet
is one of the programs that benefits from delayed ACK, which ACK-on-PUSH
effectively disables for applications like telnet.

It's designed to avoid a situation where a transmitter, because its
socket buffer is too small, can't send the two packets necessary to
trigger the ACK from the other side.  The other side's delayed ACK
timer fires eventually, and the ACK is transmitted, but at the loss
of approximately one RTT.

The original commit message, from the source-changes archive, is:

 ----- snip -----
As I described this on comp.protocols.tcp-ip:

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.
 ----- snip -----

The change was made by Charles Hannum (mycroft), and the message went out
on April 25, 1994; it was there for a while :-)

It's not a very common situation, but if it occurs, and you're on a
high delay network, you'll find it generally annoying.

This makes the other side ACK the packet the sender was able to send (since
it would have PUSH set, because all of the data in the socket buffer was
sent), providing the other side is a NetBSD system with this option turned
on.

 > Are there other advantages/disadvantages to enabling it? 

Like I said, it effectively disables delayed ACK in certain situations
where delayed ACK is beneficial (and, there was even a bug report about it).

It was the standard behavior of our TCP for a while, but I changed that
(removed it) a short while ago.  I reintroduced it this way as a sort of
compromise.

I don't really know of any other TCP that does ACK-on-PUSH, and I
wouldn't recommend enabling it unless you know you need it.  (If you
have to ask yourself "How will I know?", then you probably don't :-)

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939