[ih] TCP PUSH flag

[touch at strayalpha.com]

Hi, all,

If you want to discuss the history of the PUSH flag, this is a good list to continue.

If you want to know the current recommendations, please take the discussion to the IETF TCPM mailing list here, esp after reviewing the updated spec in RFC9293:
https://datatracker.ietf.org/wg/tcpm/about/

Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On May 15, 2025, at 7:46 AM, Matt Mathis via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Allow me to describe my mental model for push.
> 
> TCP is full of "dally algorithms" of which delayed ACK is the most famous.
> These heuristics all choose to do work now, or dally a bit, in hopes of
> aggregating additional work.  Other examples include TSO*, GRO*, the logic
> around waking  select and read, mapping write boundaries into segments
> boundaries, etc.
> 
> The point of push is to say "don't dally, because there isn't more pending
> work"
> 
> In all cases these algorithms fall back to a timer, and in many cases there
> are other signals not to dally.    The point being that not using or
> implementing push won't cause failures, but for some workloads on some
> systems it might cause substantially reduced performance.  As an
> implementer you don't know if TCP's peer needs push to be efficient.
> 
> * Note that the check for PSH is implicit, because all TCP flag
> changes terminate aggregation.
> 
> Thanks,
> --MM--
> Evil is defined by mortals who think they know "The Truth" and use force to
> apply it to others.
> -------------------------------------------
> Matt Mathis  (Email is best)
> Home & mobile: 412-654-7529 please leave a message if you must call.
> 
> 
> 
> On Thu, May 15, 2025 at 6:15 AM David Finnigan via Internet-history <
> internet-history at elists.isoc.org> wrote:
> 
>> Following is something of a short essay that I researched and wrote in
>> March. Posting here because it may invoke some comment or interesting
>> discussion.
>> 
>> Correction and clarifications always welcome, too! :-)
>> 
>> ---------
>> 
>> What to do with the TCP PUSH flag?
>> 
>> Yesterday I spent a lot of time researching the TCP PUSH flag, its
>> purpose, and whether it has any relevance today. The PUSH flag evolved
>> out of the End of Letter (EOL) flag during the development of TCP in the
>> late 1970s and early 1980s. RFC 793, dated September 1981 tells us that
>> "A push causes the TCPs to promptly forward and deliver data up to that
>> point to the receiver. The exact push point might not be visible to the
>> receiving user and the push function does not supply a record boundary
>> marker." And further summarizes that "The purpose of push function and
>> the PUSH flag is to push data through from the sending user to the
>> receiving user.  It does not provide a record service."
>> 
>> Later on, RFC 793 describes the TCP Send function as containing a PUSH
>> flag argument. When this argument is set, "the data must be transmitted
>> promptly to the receiver, and the PUSH bit will be set in the last TCP
>> segment created from the buffer.  If the PUSH flag is not set, the data
>> may be combined with data from subsequent SENDs for transmission
>> efficiency." In its description of a TCP Receive call, the document
>> states that the PUSH flag may be returned as part of this call.
>> 
>> That was the specification in 1981, but the varying implementations
>> differed. Some implementations of TCP would not return a buffer of
>> received data to the reading application if the buffer were not
>> completely full. The TCP would only send a partial buffer of received
>> data if the PUSH flag accompanied it. The TCP and SMTP implementations
>> on TOPS-20 were known to have this behavior in the early 1980s.
>> 
>> 
>> -- Berkeley's Implementation of PUSH --
>> 
>> The Berkeley TCP/IP implementation took a different approach. Received
>> data that fits in the receive window is always made available to a
>> reading socket, regardless of whether the PUSH flag is set or not. In
>> fact, for many years, the BSD TCP did nothing at all with an incoming
>> PUSH flag, other than to clear it when trimming a segment to fit the
>> receive window.
>> 
>> The rationale, so far as I can surmise, is because Berkeley's TCP and
>> sockets interface do not withhold any received, valid, in-window and
>> in-order data from a receiving application.
>> 
>> Upon output, BSD only set the PSH bit in the segment header if it
>> emptied the socket's send buffer. There was no user-accessible mechanism
>> to set or clear the PUSH flag upon sending data, nor was the application
>> provided any means to detect whether the PUSH flag had been set for
>> incoming data.
>> 
>> 
>> -- RFC 1122 makes user-control of the PUSH flag optional --
>> 
>> RFC 1122, issued October 1989, clarified the PUSH flag in its section
>> 4.2.2.2, stating that "A TCP MAY implement PUSH flags on SEND calls.  If
>> PUSH flags are not implemented, then the sending TCP: (1) must not
>> buffer data indefinitely, and (2) MUST set the PSH bit in the last
>> buffered segment (i.e., when there is no more queued data to be sent)."
>> 
>> Just as RFC1122 made a user-accessible PUSH flag an optional part of the
>> Send call, this RFC also made signaling a PUSH flag to a receiving
>> application optional, saying "Passing a received PSH flag to the
>> application layer is now OPTIONAL."
>> 
>> BSD's implementation and use of TCP's PUSH function was thus
>> standardized.
>> 
>> Thirty years later, the PUSH flag is still largely ignored by
>> BSD-derived TCP implementations. With just one exception of which I am
>> aware. The TCP in Mac OS X has a congestion control module that uses the
>> PUSH flag as part of a heuristic to control delayed ACKs. The subroutine
>> tcp_cc_delay_ack() in file tcp_cc.c has a comment reading "If TH_PUSH is
>> set, take this as a clue that we need to ACK with no delay. This helps
>> higher level protocols who won't send us more data even if the window is
>> open because their last "segment" hasn't been ACKed."  NetBSD has a
>> similar ACK-on-PUSH option which will refrain from delaying an ACK to an
>> incoming segment which has the PSH bit set.
>> 
>> Those, so far as I know, are the only practical uses of the PUSH flag on
>> incoming TCP segments in BSD-derived TCP implementations.
>> 
>> So, for my implementation of TCP, what should I do with the PUSH flag?
>> Is it, like the URGENT flag, effectively deprecated? Is it just a relic
>> of the early 1980s? Or should I just model Berkeley TCP's use of it,
>> setting the PSH bit automatically when transmitting segments?
>> 
>> 
>> ---------
>> 
>> -David Finnigan
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -
>> Unsubscribe:
>> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history
> -
> Unsubscribe: https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history