Date:        Tue, 29 Jul 2003 15:06:06 +0200
    From:        Ignatios Souvatzis <ignatios@theory.cs.uni-bonn.de>
    Message-ID:  <20030729130606.GE21990@cs.uni-bonn.de>

That's a reply to an ancient message...

[TCP PUSH]

  | Ah - so it's more or less the inverse of the Chaosnet
  | ack-delivery-to-application vs. ack-delivery-to-tcp-stack function.

Can't comment on similarities or otherwise wrt chaosnet - my knowledge
of that begins and ends with the fact that it provided the only class
in the DNS other than "IN".

But, there is no relationship at all between PUSH and ACK in TCP.
PUSH is just an instruction to the receiving stack to actually make
the data available to the receiving application (that is, TCP can
"hide" the fact that packets without PUSH arrived from an application
waiting to receive them).

On the other hand, TCP ACKs data (approximately) as soon as it arrives
at the TCP stack (which sounds similar to "ack-delivery-to-tcp-stack")
it never acks on delivery to the application.  ("approximately"
because of delayed acks, ack every 2nd segment, and other techniques
like those).  PUSH being set (or not set) has no impact on that at all.

PUSH was relevant mostly in the days when you really didn't want to
allow an application to run and fetch data when it wouldn't be able
to do anything useful with it, because the cost of resuming an
application was so high (thing swap out whatever is in memory and swap
in the one to run).   So, PUSH would be set when the sender knew it
had sent something that could usefully be processed at the receiver,
and particularly, when the sender was going to wait for the receiver
to send a reply (app level reply) before sending anything else.  If
PUSH isn't set in this final case, deadlock is possible.

These days, TCP stacks make data available to the app as soon as it
arrives (with no sequence number gaps), with or without PUSH.
Hence it really makes no difference to anything whether or not the
sender sets the PUSH flag (but because the lack of PUSH is really
the meaningful state now, many TCPs simply always set it).

PUSH means nothing at the data source (ie: assuming there's an
interface to do so, an app telling TCP to set PUSH does so to
pass that to the receiving TCP stack, it should not have any effect at
all on what the sender stack does).   If the sender desires some kind of
"send buffered data now" command, that's something of local relevance
only, and doesn't need header bits to achieve (just a new function
call in the original TCP mindset - an ioctl in the *BSD stacks).

kre