From gregskinner0 at icloud.com  Tue May 13 10:44:46 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Tue, 13 May 2025 10:44:46 -0700
Subject: [ih] Fwd: Zaw-Sing Su has passed away
References: <1857872314.9912.1747156102515@mail.yahoo.com>
Message-ID: <F31D15D3-DD7A-4B2A-B612-920D44E7F98F@icloud.com>

Forwarded for Barbara

> From: Barbara Denny <b_a_denny at yahoo.com>
> To: Internet-history <internet-history at elists.isoc.org>
> Sent: Tuesday, May 13, 2025 at 09:45:25 AM PDT
> Subject: Zaw-Sing Su has passed away
> 
> I was very sad to learn recently that Zaw-Sing Su passed away last year on April 15.  I don't think I saw a message on this list so I wanted to let people know.  
> 
> If you haven't heard of Zaw-Sing, I think he started to work on pieces of the Internet in the 70s. While at UCLA, he worked on tasks for the packet radio program involving simulation and  taking measurements of the experimental network. I think he then came to SRI where he wrote RFC 781 (IP Timestamp Option) and became a key contributor to DNS. He also worked on the design approach used in the Reconstitution Protocol project.  After SRI, I believe he went to Telenor and unfortunately that is where I lost touch with him. I am sure he did much more as this is just the little I know. I hope some of you also had a chance to talk to him about his experiences growing up in China.
> 
> barbara
> 



From df at macgui.com  Thu May 15 06:15:26 2025
From: df at macgui.com (David Finnigan)
Date: Thu, 15 May 2025 08:15:26 -0500
Subject: [ih] TCP PUSH flag
Message-ID: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>

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


From matt.mathis at gmail.com  Thu May 15 07:46:45 2025
From: matt.mathis at gmail.com (Matt Mathis)
Date: Thu, 15 May 2025 07:46:45 -0700
Subject: [ih] TCP PUSH flag
In-Reply-To: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
Message-ID: <CA+s1KQG-aNR_o2xyvQS=nvcgxeaEo0dKc0kP8fVywepjaM6HMw@mail.gmail.com>

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
>


From touch at strayalpha.com  Thu May 15 09:13:28 2025
From: touch at strayalpha.com (touch at strayalpha.com)
Date: Thu, 15 May 2025 09:13:28 -0700
Subject: [ih] TCP PUSH flag
In-Reply-To: <CA+s1KQG-aNR_o2xyvQS=nvcgxeaEo0dKc0kP8fVywepjaM6HMw@mail.gmail.com>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
 <CA+s1KQG-aNR_o2xyvQS=nvcgxeaEo0dKc0kP8fVywepjaM6HMw@mail.gmail.com>
Message-ID: <2EE0E32B-51BE-48AB-8A87-14FE00F43F70@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



From gregskinner0 at icloud.com  Thu May 15 10:04:57 2025
From: gregskinner0 at icloud.com (Greg Skinner)
Date: Thu, 15 May 2025 10:04:57 -0700
Subject: [ih] TCP PUSH flag
In-Reply-To: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
Message-ID: <6905A219-B260-468B-B79A-324B9F544CDD@icloud.com>

Shortly after the 1-Jan-1983 NCP-to-TCP/IP cutover, there were some issues with SMTP involving the PSH flag.  [1] Also take a look at the first few months in 1983 of the tcp-ip mailing list. [2]

--gregbo

[1] https://www.rfc-editor.org/in-notes/museum/smtp-mail-errors
[2] https://github.com/matthewgream/www-securitydigest-org/tree/master/tcp-ip/archive/1983

From jack at 3kitty.org  Fri May 16 11:10:51 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 16 May 2025 11:10:51 -0700
Subject: [ih] TCP PUSH flag
In-Reply-To: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
Message-ID: <f6c0d089-db44-42dd-bf8e-de36b66c7a83@3kitty.org>

The "PUSH" mechanism was part of a larger issue that was discussed and 
debated in the early 1980s, while we had The Internet on the operating 
table to replace TCP V2 with TCP/IP V4.? I don't recall exactly what we 
called that issue - something like "Out-Of-Band Control" (OOBC).

OOBC was one of the items that the ICCB put on the "things we have to 
figure out" list, for more research to figure out exactly what to do and 
get it into the next release.

The basic issue of OOBC was the need for some mechanism to "interrupt" 
an ongoing interaction between the two end-users of a TCP connection.?? 
When a connection was in progress, significant data might be buffered 
"in the pipe", and the apps communicating over TCP often were unwilling 
to accept more data from the pipe as they worked to complete a previous 
task.

This was a real practical problem.? One memorable example involved the 
simple use of printers, such as one that might be attached to a TAC 
port, printing a document arriving via TCP from some computer out on the 
'net.

It was a common, and annoying, experience to accidentally send a 
document which wasn't a text file to be printed, such as some kind of 
graphics document, core dump, or other "data" file.? At the time, 
printers that could print diagrams or pictures were quite rare (the 
Xerox XGP being one example).?? Most printers only printed characters, 
either very slowly (a mod 33 TTY or a TI700 terminal) or very quickly 
(any of the big high-speed printers attached to a PDP-10 or similar CPU).

If you accidentally sent a non-text file to such a printer, it tried to 
put it on paper.?? But many of the bytes being "printed" would be 
control codes - e.g., octal 014 was "form feed".? That caused a printer 
to advance to the next page.?? Octal 015 was "carriage-return".? Octal 
012 was "line feed".

A graphics file with lots of 015s but few 012s would print lines of text 
on top of previous lines.? After a few such lines, the paper would shred 
at that line, and then create a huge mess inside the printer as it kept 
feeding paper.

Or a file with lots of 014 bytes could consume a thousand feet of paper 
in seconds.?? Every 014 caused a new page to be rapidly ejected.

We were quite familiar with such disasters.? It had even been a problem 
at the demonstration of the ARPANET at the ICCC '72 conference.

So, the question was how to stop such chaos - what mechanisms would 
allow a user (or the user's app) to somehow stop such scenarios.

The PUSH mechanism provided one approach, telling the recipient TCP to 
stop waiting for more data.? It complemented the URGent mechanism which 
indicated that there was something important coming and the receiving 
app should do something about it.? Perhaps it was an ABORT command, 
which would stop that out-of-control printer.

For me at least, at the time I was remembering earlier experiences in 
the 70s implementing electronic mail, and even wrote up some "Thoughts 
on Interactions in Distributed Services" (see RFC722 if you're curious, 
especially the notion of "Request Reply Discipline").

The PUSH mechanism provided a way to tell a receiving TCP that it 
shouldn't wait for more data.?? But that didn't mean the receiving app 
would be willing to accept it.?? The URGent mechanism was intended to 
tell the app that it should accept more data as fast as possible, 
because there was something important coming.? But there was no way for 
the app to find out how that future data should be handled.??? E.g., in 
that printer scenario, what would your app code do when it somehow got 
an URGent indication??? How would the human user stop a printout?

There were many discussions about how to provide some mechanisms for 
OOBC.? One idea was to simply advise apps to utilize a second TCP 
connection for "control" traffic (FTP did this on the ARPANET).?? A 
Type-of-Service (TOS) setting of "Priority" might cause the underlying 
Internet to deliver such "control" traffic more quickly than the bulk 
data being transferred through the main TCP connection - once someone 
figured out how to implement TOS in the datagram infrastructure.

Using multiple connections would be of course more complicated to 
implement and coordinate in the app code, so a simpler solution was 
desired.? That needed further research, but the PUSH, URGent, and such 
mechanisms were a way to start.

The ARPANET was the main source of experience at the time. Although it 
was a packet-switched network, it had a lot of internal mechanisms that 
created a "virtual circuit" service to the computers attached to it.? 
Everything that went in at a source came out at the destination intact, 
complete and in sequence.? In effect, the functionality provided by TCP 
for creating a reliable byte-stream was already also present inside the 
ARPANET, with mechanisms in the source and destination IMPs for each 
traffic flow.? Internal messages, such as ALLOcate, travelled between 
IMPs to implement that mechanism.? Data flow was also regulated to 
achieve a typical maximum latency of 250 milliseconds - dictated by the 
desire to have characters typed by the human user quickly processed by 
the app consuming them.? Scenarios such as "buffer bloat" were not a 
problem.

Those internal mechanisms weren't well known at the time, except by the 
ARPANET implementers at BBN.? The algorithms and protocols used also 
changed as the traffic patterns changed over time.?? Technology 
advances, such as the introduction of personal workstations and later 
PCs, altered the way people used the network.? The internal mechanisms 
similarly changed as needed.? I was never an ARPANET implementer, but 
that group was literally right down the hall so I was aware of a lot of 
the internal issues and mechanisms as I worked on TCP.

TCP made significant changes to how networks worked.?? Some of these may 
not be obvious even now.

For example, the internal mechanisms in the IMPs were largely invisible 
to the computers attached to IMPS.?? That included Internet-capable 
computers such as gateways and hosts running TCP. The IMP internal 
mechanisms could change without the need for TCP/IP code to change at 
all.?? Mechanisms in TCP and gateway implementations needed "rough 
consensus and running code" within a much larger and geographically 
scattered community.

TCP moved the mechanisms for creating virtual circuit behavior into the 
users' computers.?? That meant that the internal mechanisms operating in 
the ARPANET had to have some kind of analogous mechanism inside the 
users' computers' TCP implementations as well as the gateways.

Of course such mechanisms would have to be well documented so that all 
TCP implementations would behave correctly.?? The ARPANET approach of 
having all implementers in close proximity was not practical for The 
Internet.

We didn't know how to do that.?? It required further research. 
Meanwhile, PUSH and URGent and TOS and other such "placeholders" would 
hopefully be enlightening as The Internet Experiment continued.

It's 2025 now.? I still can't stop my printer when I accidentally send 
it the wrong document to print.

Hope this helps explain a bit of the History.

Jack Haverty




On 5/15/25 06:15, David Finnigan via Internet-history 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250516/7e766b6d/attachment.asc>

From jeanjour at comcast.net  Fri May 16 12:36:12 2025
From: jeanjour at comcast.net (John Day)
Date: Fri, 16 May 2025 15:36:12 -0400
Subject: [ih] TCP PUSH flag
In-Reply-To: <f6c0d089-db44-42dd-bf8e-de36b66c7a83@3kitty.org>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
 <f6c0d089-db44-42dd-bf8e-de36b66c7a83@3kitty.org>
Message-ID: <37BCC379-CEB0-4A39-A62D-4EA0142EB00E@comcast.net>

Jack,

Wasn?t earlier than the 80s?  I remember it being mixed up with trying to optimize the character-at-a-time nature of TENEX Telnet.  Mixed up with Remote Control Transmission and Echo (RCTE).

John

> On May 16, 2025, at 14:10, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> The "PUSH" mechanism was part of a larger issue that was discussed and debated in the early 1980s, while we had The Internet on the operating table to replace TCP V2 with TCP/IP V4.  I don't recall exactly what we called that issue - something like "Out-Of-Band Control" (OOBC).
> 
> OOBC was one of the items that the ICCB put on the "things we have to figure out" list, for more research to figure out exactly what to do and get it into the next release.
> 
> The basic issue of OOBC was the need for some mechanism to "interrupt" an ongoing interaction between the two end-users of a TCP connection.   When a connection was in progress, significant data might be buffered "in the pipe", and the apps communicating over TCP often were unwilling to accept more data from the pipe as they worked to complete a previous task.
> 
> This was a real practical problem.  One memorable example involved the simple use of printers, such as one that might be attached to a TAC port, printing a document arriving via TCP from some computer out on the 'net.
> 
> It was a common, and annoying, experience to accidentally send a document which wasn't a text file to be printed, such as some kind of graphics document, core dump, or other "data" file.  At the time, printers that could print diagrams or pictures were quite rare (the Xerox XGP being one example).   Most printers only printed characters, either very slowly (a mod 33 TTY or a TI700 terminal) or very quickly (any of the big high-speed printers attached to a PDP-10 or similar CPU).
> 
> If you accidentally sent a non-text file to such a printer, it tried to put it on paper.   But many of the bytes being "printed" would be control codes - e.g., octal 014 was "form feed".  That caused a printer to advance to the next page.   Octal 015 was "carriage-return".  Octal 012 was "line feed".
> 
> A graphics file with lots of 015s but few 012s would print lines of text on top of previous lines.  After a few such lines, the paper would shred at that line, and then create a huge mess inside the printer as it kept feeding paper.
> 
> Or a file with lots of 014 bytes could consume a thousand feet of paper in seconds.   Every 014 caused a new page to be rapidly ejected.
> 
> We were quite familiar with such disasters.  It had even been a problem at the demonstration of the ARPANET at the ICCC '72 conference.
> 
> So, the question was how to stop such chaos - what mechanisms would allow a user (or the user's app) to somehow stop such scenarios.
> 
> The PUSH mechanism provided one approach, telling the recipient TCP to stop waiting for more data.  It complemented the URGent mechanism which indicated that there was something important coming and the receiving app should do something about it.  Perhaps it was an ABORT command, which would stop that out-of-control printer.
> 
> For me at least, at the time I was remembering earlier experiences in the 70s implementing electronic mail, and even wrote up some "Thoughts on Interactions in Distributed Services" (see RFC722 if you're curious, especially the notion of "Request Reply Discipline").
> 
> The PUSH mechanism provided a way to tell a receiving TCP that it shouldn't wait for more data.   But that didn't mean the receiving app would be willing to accept it.   The URGent mechanism was intended to tell the app that it should accept more data as fast as possible, because there was something important coming.  But there was no way for the app to find out how that future data should be handled.    E.g., in that printer scenario, what would your app code do when it somehow got an URGent indication?   How would the human user stop a printout?
> 
> There were many discussions about how to provide some mechanisms for OOBC.  One idea was to simply advise apps to utilize a second TCP connection for "control" traffic (FTP did this on the ARPANET).   A Type-of-Service (TOS) setting of "Priority" might cause the underlying Internet to deliver such "control" traffic more quickly than the bulk data being transferred through the main TCP connection - once someone figured out how to implement TOS in the datagram infrastructure.
> 
> Using multiple connections would be of course more complicated to implement and coordinate in the app code, so a simpler solution was desired.  That needed further research, but the PUSH, URGent, and such mechanisms were a way to start.
> 
> The ARPANET was the main source of experience at the time. Although it was a packet-switched network, it had a lot of internal mechanisms that created a "virtual circuit" service to the computers attached to it.  Everything that went in at a source came out at the destination intact, complete and in sequence.  In effect, the functionality provided by TCP for creating a reliable byte-stream was already also present inside the ARPANET, with mechanisms in the source and destination IMPs for each traffic flow.  Internal messages, such as ALLOcate, travelled between IMPs to implement that mechanism.  Data flow was also regulated to achieve a typical maximum latency of 250 milliseconds - dictated by the desire to have characters typed by the human user quickly processed by the app consuming them.  Scenarios such as "buffer bloat" were not a problem.
> 
> Those internal mechanisms weren't well known at the time, except by the ARPANET implementers at BBN.  The algorithms and protocols used also changed as the traffic patterns changed over time.   Technology advances, such as the introduction of personal workstations and later PCs, altered the way people used the network.  The internal mechanisms similarly changed as needed.  I was never an ARPANET implementer, but that group was literally right down the hall so I was aware of a lot of the internal issues and mechanisms as I worked on TCP.
> 
> TCP made significant changes to how networks worked.   Some of these may not be obvious even now.
> 
> For example, the internal mechanisms in the IMPs were largely invisible to the computers attached to IMPS.   That included Internet-capable computers such as gateways and hosts running TCP. The IMP internal mechanisms could change without the need for TCP/IP code to change at all.   Mechanisms in TCP and gateway implementations needed "rough consensus and running code" within a much larger and geographically scattered community.
> 
> TCP moved the mechanisms for creating virtual circuit behavior into the users' computers.   That meant that the internal mechanisms operating in the ARPANET had to have some kind of analogous mechanism inside the users' computers' TCP implementations as well as the gateways.
> 
> Of course such mechanisms would have to be well documented so that all TCP implementations would behave correctly.   The ARPANET approach of having all implementers in close proximity was not practical for The Internet.
> 
> We didn't know how to do that.   It required further research. Meanwhile, PUSH and URGent and TOS and other such "placeholders" would hopefully be enlightening as The Internet Experiment continued.
> 
> It's 2025 now.  I still can't stop my printer when I accidentally send it the wrong document to print.
> 
> Hope this helps explain a bit of the History.
> 
> Jack Haverty
> 
> 
> 
> 
> On 5/15/25 06:15, David Finnigan via Internet-history 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



From vint at google.com  Fri May 16 13:23:38 2025
From: vint at google.com (Vint Cerf)
Date: Fri, 16 May 2025 16:23:38 -0400
Subject: [ih] TCP PUSH flag
In-Reply-To: <37BCC379-CEB0-4A39-A62D-4EA0142EB00E@comcast.net>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
 <f6c0d089-db44-42dd-bf8e-de36b66c7a83@3kitty.org>
 <37BCC379-CEB0-4A39-A62D-4EA0142EB00E@comcast.net>
Message-ID: <CAHxHggcw_-45Lvfz5FDDvPVGjo-7LvLs7Y4JYRSbjjywWLKPsQ@mail.gmail.com>

I would have thought this debate was over by 1978 or so.

v


On Fri, May 16, 2025 at 3:38?PM John Day via Internet-history <
internet-history at elists.isoc.org> wrote:

> Jack,
>
> Wasn?t earlier than the 80s?  I remember it being mixed up with trying to
> optimize the character-at-a-time nature of TENEX Telnet.  Mixed up with
> Remote Control Transmission and Echo (RCTE).
>
> John
>
> > On May 16, 2025, at 14:10, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > The "PUSH" mechanism was part of a larger issue that was discussed and
> debated in the early 1980s, while we had The Internet on the operating
> table to replace TCP V2 with TCP/IP V4.  I don't recall exactly what we
> called that issue - something like "Out-Of-Band Control" (OOBC).
> >
> > OOBC was one of the items that the ICCB put on the "things we have to
> figure out" list, for more research to figure out exactly what to do and
> get it into the next release.
> >
> > The basic issue of OOBC was the need for some mechanism to "interrupt"
> an ongoing interaction between the two end-users of a TCP connection.
>  When a connection was in progress, significant data might be buffered "in
> the pipe", and the apps communicating over TCP often were unwilling to
> accept more data from the pipe as they worked to complete a previous task.
> >
> > This was a real practical problem.  One memorable example involved the
> simple use of printers, such as one that might be attached to a TAC port,
> printing a document arriving via TCP from some computer out on the 'net.
> >
> > It was a common, and annoying, experience to accidentally send a
> document which wasn't a text file to be printed, such as some kind of
> graphics document, core dump, or other "data" file.  At the time, printers
> that could print diagrams or pictures were quite rare (the Xerox XGP being
> one example).   Most printers only printed characters, either very slowly
> (a mod 33 TTY or a TI700 terminal) or very quickly (any of the big
> high-speed printers attached to a PDP-10 or similar CPU).
> >
> > If you accidentally sent a non-text file to such a printer, it tried to
> put it on paper.   But many of the bytes being "printed" would be control
> codes - e.g., octal 014 was "form feed".  That caused a printer to advance
> to the next page.   Octal 015 was "carriage-return".  Octal 012 was "line
> feed".
> >
> > A graphics file with lots of 015s but few 012s would print lines of text
> on top of previous lines.  After a few such lines, the paper would shred at
> that line, and then create a huge mess inside the printer as it kept
> feeding paper.
> >
> > Or a file with lots of 014 bytes could consume a thousand feet of paper
> in seconds.   Every 014 caused a new page to be rapidly ejected.
> >
> > We were quite familiar with such disasters.  It had even been a problem
> at the demonstration of the ARPANET at the ICCC '72 conference.
> >
> > So, the question was how to stop such chaos - what mechanisms would
> allow a user (or the user's app) to somehow stop such scenarios.
> >
> > The PUSH mechanism provided one approach, telling the recipient TCP to
> stop waiting for more data.  It complemented the URGent mechanism which
> indicated that there was something important coming and the receiving app
> should do something about it.  Perhaps it was an ABORT command, which would
> stop that out-of-control printer.
> >
> > For me at least, at the time I was remembering earlier experiences in
> the 70s implementing electronic mail, and even wrote up some "Thoughts on
> Interactions in Distributed Services" (see RFC722 if you're curious,
> especially the notion of "Request Reply Discipline").
> >
> > The PUSH mechanism provided a way to tell a receiving TCP that it
> shouldn't wait for more data.   But that didn't mean the receiving app
> would be willing to accept it.   The URGent mechanism was intended to tell
> the app that it should accept more data as fast as possible, because there
> was something important coming.  But there was no way for the app to find
> out how that future data should be handled.    E.g., in that printer
> scenario, what would your app code do when it somehow got an URGent
> indication?   How would the human user stop a printout?
> >
> > There were many discussions about how to provide some mechanisms for
> OOBC.  One idea was to simply advise apps to utilize a second TCP
> connection for "control" traffic (FTP did this on the ARPANET).   A
> Type-of-Service (TOS) setting of "Priority" might cause the underlying
> Internet to deliver such "control" traffic more quickly than the bulk data
> being transferred through the main TCP connection - once someone figured
> out how to implement TOS in the datagram infrastructure.
> >
> > Using multiple connections would be of course more complicated to
> implement and coordinate in the app code, so a simpler solution was
> desired.  That needed further research, but the PUSH, URGent, and such
> mechanisms were a way to start.
> >
> > The ARPANET was the main source of experience at the time. Although it
> was a packet-switched network, it had a lot of internal mechanisms that
> created a "virtual circuit" service to the computers attached to it.
> Everything that went in at a source came out at the destination intact,
> complete and in sequence.  In effect, the functionality provided by TCP for
> creating a reliable byte-stream was already also present inside the
> ARPANET, with mechanisms in the source and destination IMPs for each
> traffic flow.  Internal messages, such as ALLOcate, travelled between IMPs
> to implement that mechanism.  Data flow was also regulated to achieve a
> typical maximum latency of 250 milliseconds - dictated by the desire to
> have characters typed by the human user quickly processed by the app
> consuming them.  Scenarios such as "buffer bloat" were not a problem.
> >
> > Those internal mechanisms weren't well known at the time, except by the
> ARPANET implementers at BBN.  The algorithms and protocols used also
> changed as the traffic patterns changed over time.   Technology advances,
> such as the introduction of personal workstations and later PCs, altered
> the way people used the network.  The internal mechanisms similarly changed
> as needed.  I was never an ARPANET implementer, but that group was
> literally right down the hall so I was aware of a lot of the internal
> issues and mechanisms as I worked on TCP.
> >
> > TCP made significant changes to how networks worked.   Some of these may
> not be obvious even now.
> >
> > For example, the internal mechanisms in the IMPs were largely invisible
> to the computers attached to IMPS.   That included Internet-capable
> computers such as gateways and hosts running TCP. The IMP internal
> mechanisms could change without the need for TCP/IP code to change at all.
>  Mechanisms in TCP and gateway implementations needed "rough consensus and
> running code" within a much larger and geographically scattered community.
> >
> > TCP moved the mechanisms for creating virtual circuit behavior into the
> users' computers.   That meant that the internal mechanisms operating in
> the ARPANET had to have some kind of analogous mechanism inside the users'
> computers' TCP implementations as well as the gateways.
> >
> > Of course such mechanisms would have to be well documented so that all
> TCP implementations would behave correctly.   The ARPANET approach of
> having all implementers in close proximity was not practical for The
> Internet.
> >
> > We didn't know how to do that.   It required further research.
> Meanwhile, PUSH and URGent and TOS and other such "placeholders" would
> hopefully be enlightening as The Internet Experiment continued.
> >
> > It's 2025 now.  I still can't stop my printer when I accidentally send
> it the wrong document to print.
> >
> > Hope this helps explain a bit of the History.
> >
> > Jack Haverty
> >
> >
> >
> >
> > On 5/15/25 06:15, David Finnigan via Internet-history 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
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From jeanjour at comcast.net  Fri May 16 13:32:32 2025
From: jeanjour at comcast.net (John Day)
Date: Fri, 16 May 2025 16:32:32 -0400
Subject: [ih] TCP PUSH flag
In-Reply-To: <CAHxHggcw_-45Lvfz5FDDvPVGjo-7LvLs7Y4JYRSbjjywWLKPsQ@mail.gmail.com>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
 <f6c0d089-db44-42dd-bf8e-de36b66c7a83@3kitty.org>
 <37BCC379-CEB0-4A39-A62D-4EA0142EB00E@comcast.net>
 <CAHxHggcw_-45Lvfz5FDDvPVGjo-7LvLs7Y4JYRSbjjywWLKPsQ@mail.gmail.com>
Message-ID: <EDD3CF4F-FB9B-47D5-8BBB-9B208E3657C5@comcast.net>

;-) Yea me too!

> On May 16, 2025, at 16:23, Vint Cerf <vint at google.com> wrote:
> 
> I would have thought this debate was over by 1978 or so.
> 
> v
> 
> 
> On Fri, May 16, 2025 at 3:38?PM John Day via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> Jack,
>> 
>> Wasn?t earlier than the 80s?  I remember it being mixed up with trying to optimize the character-at-a-time nature of TENEX Telnet.  Mixed up with Remote Control Transmission and Echo (RCTE).
>> 
>> John
>> 
>> > On May 16, 2025, at 14:10, Jack Haverty via Internet-history <internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>> wrote:
>> > 
>> > The "PUSH" mechanism was part of a larger issue that was discussed and debated in the early 1980s, while we had The Internet on the operating table to replace TCP V2 with TCP/IP V4.  I don't recall exactly what we called that issue - something like "Out-Of-Band Control" (OOBC).
>> > 
>> > OOBC was one of the items that the ICCB put on the "things we have to figure out" list, for more research to figure out exactly what to do and get it into the next release.
>> > 
>> > The basic issue of OOBC was the need for some mechanism to "interrupt" an ongoing interaction between the two end-users of a TCP connection.   When a connection was in progress, significant data might be buffered "in the pipe", and the apps communicating over TCP often were unwilling to accept more data from the pipe as they worked to complete a previous task.
>> > 
>> > This was a real practical problem.  One memorable example involved the simple use of printers, such as one that might be attached to a TAC port, printing a document arriving via TCP from some computer out on the 'net.
>> > 
>> > It was a common, and annoying, experience to accidentally send a document which wasn't a text file to be printed, such as some kind of graphics document, core dump, or other "data" file.  At the time, printers that could print diagrams or pictures were quite rare (the Xerox XGP being one example).   Most printers only printed characters, either very slowly (a mod 33 TTY or a TI700 terminal) or very quickly (any of the big high-speed printers attached to a PDP-10 or similar CPU).
>> > 
>> > If you accidentally sent a non-text file to such a printer, it tried to put it on paper.   But many of the bytes being "printed" would be control codes - e.g., octal 014 was "form feed".  That caused a printer to advance to the next page.   Octal 015 was "carriage-return".  Octal 012 was "line feed".
>> > 
>> > A graphics file with lots of 015s but few 012s would print lines of text on top of previous lines.  After a few such lines, the paper would shred at that line, and then create a huge mess inside the printer as it kept feeding paper.
>> > 
>> > Or a file with lots of 014 bytes could consume a thousand feet of paper in seconds.   Every 014 caused a new page to be rapidly ejected.
>> > 
>> > We were quite familiar with such disasters.  It had even been a problem at the demonstration of the ARPANET at the ICCC '72 conference.
>> > 
>> > So, the question was how to stop such chaos - what mechanisms would allow a user (or the user's app) to somehow stop such scenarios.
>> > 
>> > The PUSH mechanism provided one approach, telling the recipient TCP to stop waiting for more data.  It complemented the URGent mechanism which indicated that there was something important coming and the receiving app should do something about it.  Perhaps it was an ABORT command, which would stop that out-of-control printer.
>> > 
>> > For me at least, at the time I was remembering earlier experiences in the 70s implementing electronic mail, and even wrote up some "Thoughts on Interactions in Distributed Services" (see RFC722 if you're curious, especially the notion of "Request Reply Discipline").
>> > 
>> > The PUSH mechanism provided a way to tell a receiving TCP that it shouldn't wait for more data.   But that didn't mean the receiving app would be willing to accept it.   The URGent mechanism was intended to tell the app that it should accept more data as fast as possible, because there was something important coming.  But there was no way for the app to find out how that future data should be handled.    E.g., in that printer scenario, what would your app code do when it somehow got an URGent indication?   How would the human user stop a printout?
>> > 
>> > There were many discussions about how to provide some mechanisms for OOBC.  One idea was to simply advise apps to utilize a second TCP connection for "control" traffic (FTP did this on the ARPANET).   A Type-of-Service (TOS) setting of "Priority" might cause the underlying Internet to deliver such "control" traffic more quickly than the bulk data being transferred through the main TCP connection - once someone figured out how to implement TOS in the datagram infrastructure.
>> > 
>> > Using multiple connections would be of course more complicated to implement and coordinate in the app code, so a simpler solution was desired.  That needed further research, but the PUSH, URGent, and such mechanisms were a way to start.
>> > 
>> > The ARPANET was the main source of experience at the time. Although it was a packet-switched network, it had a lot of internal mechanisms that created a "virtual circuit" service to the computers attached to it.  Everything that went in at a source came out at the destination intact, complete and in sequence.  In effect, the functionality provided by TCP for creating a reliable byte-stream was already also present inside the ARPANET, with mechanisms in the source and destination IMPs for each traffic flow.  Internal messages, such as ALLOcate, travelled between IMPs to implement that mechanism.  Data flow was also regulated to achieve a typical maximum latency of 250 milliseconds - dictated by the desire to have characters typed by the human user quickly processed by the app consuming them.  Scenarios such as "buffer bloat" were not a problem.
>> > 
>> > Those internal mechanisms weren't well known at the time, except by the ARPANET implementers at BBN.  The algorithms and protocols used also changed as the traffic patterns changed over time.   Technology advances, such as the introduction of personal workstations and later PCs, altered the way people used the network.  The internal mechanisms similarly changed as needed.  I was never an ARPANET implementer, but that group was literally right down the hall so I was aware of a lot of the internal issues and mechanisms as I worked on TCP.
>> > 
>> > TCP made significant changes to how networks worked.   Some of these may not be obvious even now.
>> > 
>> > For example, the internal mechanisms in the IMPs were largely invisible to the computers attached to IMPS.   That included Internet-capable computers such as gateways and hosts running TCP. The IMP internal mechanisms could change without the need for TCP/IP code to change at all.   Mechanisms in TCP and gateway implementations needed "rough consensus and running code" within a much larger and geographically scattered community.
>> > 
>> > TCP moved the mechanisms for creating virtual circuit behavior into the users' computers.   That meant that the internal mechanisms operating in the ARPANET had to have some kind of analogous mechanism inside the users' computers' TCP implementations as well as the gateways.
>> > 
>> > Of course such mechanisms would have to be well documented so that all TCP implementations would behave correctly.   The ARPANET approach of having all implementers in close proximity was not practical for The Internet.
>> > 
>> > We didn't know how to do that.   It required further research. Meanwhile, PUSH and URGent and TOS and other such "placeholders" would hopefully be enlightening as The Internet Experiment continued.
>> > 
>> > It's 2025 now.  I still can't stop my printer when I accidentally send it the wrong document to print.
>> > 
>> > Hope this helps explain a bit of the History.
>> > 
>> > Jack Haverty
>> > 
>> > 
>> > 
>> > 
>> > On 5/15/25 06:15, David Finnigan via Internet-history 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 <mailto: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 <mailto: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
> 
> 
> 
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
> 
> 
> until further notice
> 
> 
> 



From steve at shinkuro.com  Fri May 16 14:14:23 2025
From: steve at shinkuro.com (Steve Crocker)
Date: Fri, 16 May 2025 17:14:23 -0400
Subject: [ih] TCP PUSH flag
In-Reply-To: <EDD3CF4F-FB9B-47D5-8BBB-9B208E3657C5@comcast.net>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
 <f6c0d089-db44-42dd-bf8e-de36b66c7a83@3kitty.org>
 <37BCC379-CEB0-4A39-A62D-4EA0142EB00E@comcast.net>
 <CAHxHggcw_-45Lvfz5FDDvPVGjo-7LvLs7Y4JYRSbjjywWLKPsQ@mail.gmail.com>
 <EDD3CF4F-FB9B-47D5-8BBB-9B208E3657C5@comcast.net>
Message-ID: <CABf5zvJi315S073y9tGBkvz=DL8uftOcSGVZKcGQ5uTg=3Xb9g@mail.gmail.com>

Writing in first person singular to explicitly take some blame, not credit.

When we began to think about host level protocols, I focused immediately on
designing a basic circuit emulation protocol with the assumption that both
a remote terminal protocol and a file transfer protocol would be
relatively easy to implement on top.  I blandly called the basic circuit
emulation protocol the Host-Host protocol.  (Eventually this was renamed
the Network Control Protocol, repurposing the abbreviation NCP from its
original meaning of Network Control Program.  By "Network Control Program"
I meant the software added to the operating system that served as the
device driver for the IMP and provided service to user level processes.
I'll use HH here to refer to the protocol and NCP to refer to the program.)

HH featured simplex connections, so you needed a pair for
bidirectional communication.  The unit of transmission was a bit, not a
byte, because bytes had not yet become the standard.  And there was a
control connection between each pair of NCPs.  Creating a connection
between two processes running at the user level was done by having each NCP
send a request for connection to the other NCP.

Later, when I turned my attention to implementing a remote terminal
protocol I realized we needed a way to send an interrupt to the remote
operating system.  I had overlooked the crucial distinction between the HH
simulation of a virtual circuit compared to a real world circuit.  Real
circuits did not have any storage.  One a bit or character left the sending
end, it showed on the receiving side without delay.  Any buffering that
might happen would take place after the bit or or character had entered and
been processed by the receiving operating system.

As I mentioned, each pair of NCPs had an always open virtual connection.  I
had expected this would be used to create and close connections between
processes, but when I realized we needed a way to implement interrupts I
quickly added some functionality to the control connections.  This felt
like a kludge, but I didn't see a better way to provide the needed
functionality.  That said, I wanted to keep the design as general as
possible.  I used the control connection to signal that there was an
"event" in the user connection, thereby instructing the receiving side to
process its stream until it reached the event.

I stopped working on the details of the protocols when I moved from UCLA to
(D)ARPA in June 1971, and I only lightly followed the evolution of HH to
TCP.  The evolution to bi-directional bitstreams with checksums and
retransmission reflected both experience and general evolution in computer
architectures.

Steve




On Fri, May 16, 2025 at 4:32?PM John Day via Internet-history <
internet-history at elists.isoc.org> wrote:

> ;-) Yea me too!
>
> > On May 16, 2025, at 16:23, Vint Cerf <vint at google.com> wrote:
> >
> > I would have thought this debate was over by 1978 or so.
> >
> > v
> >
> >
> > On Fri, May 16, 2025 at 3:38?PM John Day via Internet-history <
> internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>>
> wrote:
> >> Jack,
> >>
> >> Wasn?t earlier than the 80s?  I remember it being mixed up with trying
> to optimize the character-at-a-time nature of TENEX Telnet.  Mixed up with
> Remote Control Transmission and Echo (RCTE).
> >>
> >> John
> >>
> >> > On May 16, 2025, at 14:10, Jack Haverty via Internet-history <
> internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>>
> wrote:
> >> >
> >> > The "PUSH" mechanism was part of a larger issue that was discussed
> and debated in the early 1980s, while we had The Internet on the operating
> table to replace TCP V2 with TCP/IP V4.  I don't recall exactly what we
> called that issue - something like "Out-Of-Band Control" (OOBC).
> >> >
> >> > OOBC was one of the items that the ICCB put on the "things we have to
> figure out" list, for more research to figure out exactly what to do and
> get it into the next release.
> >> >
> >> > The basic issue of OOBC was the need for some mechanism to
> "interrupt" an ongoing interaction between the two end-users of a TCP
> connection.   When a connection was in progress, significant data might be
> buffered "in the pipe", and the apps communicating over TCP often were
> unwilling to accept more data from the pipe as they worked to complete a
> previous task.
> >> >
> >> > This was a real practical problem.  One memorable example involved
> the simple use of printers, such as one that might be attached to a TAC
> port, printing a document arriving via TCP from some computer out on the
> 'net.
> >> >
> >> > It was a common, and annoying, experience to accidentally send a
> document which wasn't a text file to be printed, such as some kind of
> graphics document, core dump, or other "data" file.  At the time, printers
> that could print diagrams or pictures were quite rare (the Xerox XGP being
> one example).   Most printers only printed characters, either very slowly
> (a mod 33 TTY or a TI700 terminal) or very quickly (any of the big
> high-speed printers attached to a PDP-10 or similar CPU).
> >> >
> >> > If you accidentally sent a non-text file to such a printer, it tried
> to put it on paper.   But many of the bytes being "printed" would be
> control codes - e.g., octal 014 was "form feed".  That caused a printer to
> advance to the next page.   Octal 015 was "carriage-return".  Octal 012 was
> "line feed".
> >> >
> >> > A graphics file with lots of 015s but few 012s would print lines of
> text on top of previous lines.  After a few such lines, the paper would
> shred at that line, and then create a huge mess inside the printer as it
> kept feeding paper.
> >> >
> >> > Or a file with lots of 014 bytes could consume a thousand feet of
> paper in seconds.   Every 014 caused a new page to be rapidly ejected.
> >> >
> >> > We were quite familiar with such disasters.  It had even been a
> problem at the demonstration of the ARPANET at the ICCC '72 conference.
> >> >
> >> > So, the question was how to stop such chaos - what mechanisms would
> allow a user (or the user's app) to somehow stop such scenarios.
> >> >
> >> > The PUSH mechanism provided one approach, telling the recipient TCP
> to stop waiting for more data.  It complemented the URGent mechanism which
> indicated that there was something important coming and the receiving app
> should do something about it.  Perhaps it was an ABORT command, which would
> stop that out-of-control printer.
> >> >
> >> > For me at least, at the time I was remembering earlier experiences in
> the 70s implementing electronic mail, and even wrote up some "Thoughts on
> Interactions in Distributed Services" (see RFC722 if you're curious,
> especially the notion of "Request Reply Discipline").
> >> >
> >> > The PUSH mechanism provided a way to tell a receiving TCP that it
> shouldn't wait for more data.   But that didn't mean the receiving app
> would be willing to accept it.   The URGent mechanism was intended to tell
> the app that it should accept more data as fast as possible, because there
> was something important coming.  But there was no way for the app to find
> out how that future data should be handled.    E.g., in that printer
> scenario, what would your app code do when it somehow got an URGent
> indication?   How would the human user stop a printout?
> >> >
> >> > There were many discussions about how to provide some mechanisms for
> OOBC.  One idea was to simply advise apps to utilize a second TCP
> connection for "control" traffic (FTP did this on the ARPANET).   A
> Type-of-Service (TOS) setting of "Priority" might cause the underlying
> Internet to deliver such "control" traffic more quickly than the bulk data
> being transferred through the main TCP connection - once someone figured
> out how to implement TOS in the datagram infrastructure.
> >> >
> >> > Using multiple connections would be of course more complicated to
> implement and coordinate in the app code, so a simpler solution was
> desired.  That needed further research, but the PUSH, URGent, and such
> mechanisms were a way to start.
> >> >
> >> > The ARPANET was the main source of experience at the time. Although
> it was a packet-switched network, it had a lot of internal mechanisms that
> created a "virtual circuit" service to the computers attached to it.
> Everything that went in at a source came out at the destination intact,
> complete and in sequence.  In effect, the functionality provided by TCP for
> creating a reliable byte-stream was already also present inside the
> ARPANET, with mechanisms in the source and destination IMPs for each
> traffic flow.  Internal messages, such as ALLOcate, travelled between IMPs
> to implement that mechanism.  Data flow was also regulated to achieve a
> typical maximum latency of 250 milliseconds - dictated by the desire to
> have characters typed by the human user quickly processed by the app
> consuming them.  Scenarios such as "buffer bloat" were not a problem.
> >> >
> >> > Those internal mechanisms weren't well known at the time, except by
> the ARPANET implementers at BBN.  The algorithms and protocols used also
> changed as the traffic patterns changed over time.   Technology advances,
> such as the introduction of personal workstations and later PCs, altered
> the way people used the network.  The internal mechanisms similarly changed
> as needed.  I was never an ARPANET implementer, but that group was
> literally right down the hall so I was aware of a lot of the internal
> issues and mechanisms as I worked on TCP.
> >> >
> >> > TCP made significant changes to how networks worked.   Some of these
> may not be obvious even now.
> >> >
> >> > For example, the internal mechanisms in the IMPs were largely
> invisible to the computers attached to IMPS.   That included
> Internet-capable computers such as gateways and hosts running TCP. The IMP
> internal mechanisms could change without the need for TCP/IP code to change
> at all.   Mechanisms in TCP and gateway implementations needed "rough
> consensus and running code" within a much larger and geographically
> scattered community.
> >> >
> >> > TCP moved the mechanisms for creating virtual circuit behavior into
> the users' computers.   That meant that the internal mechanisms operating
> in the ARPANET had to have some kind of analogous mechanism inside the
> users' computers' TCP implementations as well as the gateways.
> >> >
> >> > Of course such mechanisms would have to be well documented so that
> all TCP implementations would behave correctly.   The ARPANET approach of
> having all implementers in close proximity was not practical for The
> Internet.
> >> >
> >> > We didn't know how to do that.   It required further research.
> Meanwhile, PUSH and URGent and TOS and other such "placeholders" would
> hopefully be enlightening as The Internet Experiment continued.
> >> >
> >> > It's 2025 now.  I still can't stop my printer when I accidentally
> send it the wrong document to print.
> >> >
> >> > Hope this helps explain a bit of the History.
> >> >
> >> > Jack Haverty
> >> >
> >> >
> >> >
> >> >
> >> > On 5/15/25 06:15, David Finnigan via Internet-history 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 <mailto:
> 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 <mailto:
> 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
> >
> >
> >
> > --
> > Please send any postal/overnight deliveries to:
> > Vint Cerf
> > Google, LLC
> > 1900 Reston Metro Plaza, 16th Floor
> > Reston, VA 20190
> > +1 (571) 213 1346
> >
> >
> > until further notice
> >
> >
> >
>
> --
> 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
>


-- 
Sent by a Verified

sender


From jack at 3kitty.org  Fri May 16 15:35:29 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Fri, 16 May 2025 15:35:29 -0700
Subject: [ih] TCP PUSH flag
In-Reply-To: <CABf5zvJi315S073y9tGBkvz=DL8uftOcSGVZKcGQ5uTg=3Xb9g@mail.gmail.com>
References: <900bc1ba18fed96a4cf0c6b531e4e063@macgui.com>
 <f6c0d089-db44-42dd-bf8e-de36b66c7a83@3kitty.org>
 <37BCC379-CEB0-4A39-A62D-4EA0142EB00E@comcast.net>
 <CAHxHggcw_-45Lvfz5FDDvPVGjo-7LvLs7Y4JYRSbjjywWLKPsQ@mail.gmail.com>
 <EDD3CF4F-FB9B-47D5-8BBB-9B208E3657C5@comcast.net>
 <CABf5zvJi315S073y9tGBkvz=DL8uftOcSGVZKcGQ5uTg=3Xb9g@mail.gmail.com>
Message-ID: <98573fbc-2df3-4f2d-8b4e-681f8897ede0@3kitty.org>

No blame involved.? Your recollections capture the "ARPANET experiences" 
that we all had before diving into TCP.? Admitting you don't know how to 
do something and further research is needed was a good thing!? Putting 
in some "placeholder" mechanism, even if known to be a kludge, is a way 
to keep the experimentation going.

To answer John's and Vint's comments - Yes, the discussions and 
implementation leading to TCP/IP V4 started in the late 1970s.?? But 
they were motivated by the desire to move The Internet into an 
operational mode, leading to the establishment of a DoD Standard and the 
"Flag Day" in January 1983 when all ARPANET computers had to use only TCP.

The "debate" had two aspects.? We did reach "consensus and running code" 
on the contents and formats for the TCP/IP new headers and protocol 
exchanges.? But we did not reach consensus on whether or not those 
mechanisms would actually work in the deployed system. Some people, such 
as me, didn't think mechanisms such as PUSH and URGent would be 
sufficient.? Some mechanisms, such as the algorithms and protocols to 
implement multiple Types Of Service, hadn't even been defined yet.

At the time, before the "Flag Day", there simply hadn't been much 
operational experience with TCP, old or new, in situations we needed to 
support.? Most systems were using the ARPANET for long-haul 
connectivity, and its internal virtual circuit mechanisms insulated TCP 
implementations from the chaos of the real world.? The exception to this 
was some of the projects in Europe, e.g., at UCL and RSRE, which had 
been forced to use multiple-network paths for their experiments.

There had also been some experimentation with applications such as 
Packet Voice, which motivated the introduction of UDP and addition of 
Type-Of-Service as a component of The Internet, so that it could support 
real-time interactive users.? TOS had been defined in the Headers, but 
not yet implemented, so there was no experience with it.

There were still a lot of questions about TCP/IP V4, and a list of 
things needing further research.?? In the late 70s and early 80s, we had 
many changes to the TCP formats and protocols.? It seemed like every 
quarterly meeting resulted in some changes that everyone had to 
implement.?? That wasn't too much of a problem when the community of 
implementers could be counted on your fingers.?? Most of those changes 
were captured only in email exchanges so the history is probably lost.

In any case, the expectation was that research would continue, find 
appropriate mechanisms for the list of "to do in the next release", test 
them out on the fledgling Internet, and incorporate them into the next 
version of the DoD Standards.

There's some quote about "best laid plans" that should go here. Perhaps 
an AI will add one.

One of the other innovations inherent to networking didn't occur to me 
for decades.? At the time of the ARPANET, computers typically had a 
single CPU.? There was some work on "multiprocessors", where the 
complexities of coordinating the activities of several CPUs were being 
researched and techniques tried.?? More research was needed.

What I finally realized is that when you join a network, you immediately 
are now in a multiprocessor environment, with at least 2 CPUs, yours and 
the one at the other side of the network.

Traditional multi-CPU computers have their CPUs physically close and 
interconnected by some powerful communications "buss".? Making that all 
work is a hard problem.? But in a network environment, your multiple 
CPUs are now scattered geographically, and interconnected with a lossy 
and highly variable communications infrastructure. Seems like that makes 
the problems even harder - not just for some kind of "interrupt" mechanism.

Fortunately, my networked printer, with oodles of internal memory that 
can hold large documents delivered by a Gigabit LAN, has a plug in the 
wall outlet.?? Pulling it out still effectively interrupts whatever 
silly thing it's doing.

Jack Haverty


On 5/16/25 14:14, Steve Crocker via Internet-history wrote:
> Writing in first person singular to explicitly take some blame, not credit.
>
> When we began to think about host level protocols, I focused immediately on
> designing a basic circuit emulation protocol with the assumption that both
> a remote terminal protocol and a file transfer protocol would be
> relatively easy to implement on top.  I blandly called the basic circuit
> emulation protocol the Host-Host protocol.  (Eventually this was renamed
> the Network Control Protocol, repurposing the abbreviation NCP from its
> original meaning of Network Control Program.  By "Network Control Program"
> I meant the software added to the operating system that served as the
> device driver for the IMP and provided service to user level processes.
> I'll use HH here to refer to the protocol and NCP to refer to the program.)
>
> HH featured simplex connections, so you needed a pair for
> bidirectional communication.  The unit of transmission was a bit, not a
> byte, because bytes had not yet become the standard.  And there was a
> control connection between each pair of NCPs.  Creating a connection
> between two processes running at the user level was done by having each NCP
> send a request for connection to the other NCP.
>
> Later, when I turned my attention to implementing a remote terminal
> protocol I realized we needed a way to send an interrupt to the remote
> operating system.  I had overlooked the crucial distinction between the HH
> simulation of a virtual circuit compared to a real world circuit.  Real
> circuits did not have any storage.  One a bit or character left the sending
> end, it showed on the receiving side without delay.  Any buffering that
> might happen would take place after the bit or or character had entered and
> been processed by the receiving operating system.
>
> As I mentioned, each pair of NCPs had an always open virtual connection.  I
> had expected this would be used to create and close connections between
> processes, but when I realized we needed a way to implement interrupts I
> quickly added some functionality to the control connections.  This felt
> like a kludge, but I didn't see a better way to provide the needed
> functionality.  That said, I wanted to keep the design as general as
> possible.  I used the control connection to signal that there was an
> "event" in the user connection, thereby instructing the receiving side to
> process its stream until it reached the event.
>
> I stopped working on the details of the protocols when I moved from UCLA to
> (D)ARPA in June 1971, and I only lightly followed the evolution of HH to
> TCP.  The evolution to bi-directional bitstreams with checksums and
> retransmission reflected both experience and general evolution in computer
> architectures.
>
> Steve
>
>
>
>
> On Fri, May 16, 2025 at 4:32?PM John Day via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> ;-) Yea me too!
>>
>>> On May 16, 2025, at 16:23, Vint Cerf<vint at google.com> wrote:
>>>
>>> I would have thought this debate was over by 1978 or so.
>>>
>>> v
>>>
>>>
>>> On Fri, May 16, 2025 at 3:38?PM John Day via Internet-history <
>> internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>>
>> wrote:
>>>> Jack,
>>>>
>>>> Wasn?t earlier than the 80s?  I remember it being mixed up with trying
>> to optimize the character-at-a-time nature of TENEX Telnet.  Mixed up with
>> Remote Control Transmission and Echo (RCTE).
>>>> John
>>>>
>>>>> On May 16, 2025, at 14:10, Jack Haverty via Internet-history <
>> internet-history at elists.isoc.org <mailto:internet-history at elists.isoc.org>>
>> wrote:
>>>>> The "PUSH" mechanism was part of a larger issue that was discussed
>> and debated in the early 1980s, while we had The Internet on the operating
>> table to replace TCP V2 with TCP/IP V4.  I don't recall exactly what we
>> called that issue - something like "Out-Of-Band Control" (OOBC).
>>>>> OOBC was one of the items that the ICCB put on the "things we have to
>> figure out" list, for more research to figure out exactly what to do and
>> get it into the next release.
>>>>> The basic issue of OOBC was the need for some mechanism to
>> "interrupt" an ongoing interaction between the two end-users of a TCP
>> connection.   When a connection was in progress, significant data might be
>> buffered "in the pipe", and the apps communicating over TCP often were
>> unwilling to accept more data from the pipe as they worked to complete a
>> previous task.
>>>>> This was a real practical problem.  One memorable example involved
>> the simple use of printers, such as one that might be attached to a TAC
>> port, printing a document arriving via TCP from some computer out on the
>> 'net.
>>>>> It was a common, and annoying, experience to accidentally send a
>> document which wasn't a text file to be printed, such as some kind of
>> graphics document, core dump, or other "data" file.  At the time, printers
>> that could print diagrams or pictures were quite rare (the Xerox XGP being
>> one example).   Most printers only printed characters, either very slowly
>> (a mod 33 TTY or a TI700 terminal) or very quickly (any of the big
>> high-speed printers attached to a PDP-10 or similar CPU).
>>>>> If you accidentally sent a non-text file to such a printer, it tried
>> to put it on paper.   But many of the bytes being "printed" would be
>> control codes - e.g., octal 014 was "form feed".  That caused a printer to
>> advance to the next page.   Octal 015 was "carriage-return".  Octal 012 was
>> "line feed".
>>>>> A graphics file with lots of 015s but few 012s would print lines of
>> text on top of previous lines.  After a few such lines, the paper would
>> shred at that line, and then create a huge mess inside the printer as it
>> kept feeding paper.
>>>>> Or a file with lots of 014 bytes could consume a thousand feet of
>> paper in seconds.   Every 014 caused a new page to be rapidly ejected.
>>>>> We were quite familiar with such disasters.  It had even been a
>> problem at the demonstration of the ARPANET at the ICCC '72 conference.
>>>>> So, the question was how to stop such chaos - what mechanisms would
>> allow a user (or the user's app) to somehow stop such scenarios.
>>>>> The PUSH mechanism provided one approach, telling the recipient TCP
>> to stop waiting for more data.  It complemented the URGent mechanism which
>> indicated that there was something important coming and the receiving app
>> should do something about it.  Perhaps it was an ABORT command, which would
>> stop that out-of-control printer.
>>>>> For me at least, at the time I was remembering earlier experiences in
>> the 70s implementing electronic mail, and even wrote up some "Thoughts on
>> Interactions in Distributed Services" (see RFC722 if you're curious,
>> especially the notion of "Request Reply Discipline").
>>>>> The PUSH mechanism provided a way to tell a receiving TCP that it
>> shouldn't wait for more data.   But that didn't mean the receiving app
>> would be willing to accept it.   The URGent mechanism was intended to tell
>> the app that it should accept more data as fast as possible, because there
>> was something important coming.  But there was no way for the app to find
>> out how that future data should be handled.    E.g., in that printer
>> scenario, what would your app code do when it somehow got an URGent
>> indication?   How would the human user stop a printout?
>>>>> There were many discussions about how to provide some mechanisms for
>> OOBC.  One idea was to simply advise apps to utilize a second TCP
>> connection for "control" traffic (FTP did this on the ARPANET).   A
>> Type-of-Service (TOS) setting of "Priority" might cause the underlying
>> Internet to deliver such "control" traffic more quickly than the bulk data
>> being transferred through the main TCP connection - once someone figured
>> out how to implement TOS in the datagram infrastructure.
>>>>> Using multiple connections would be of course more complicated to
>> implement and coordinate in the app code, so a simpler solution was
>> desired.  That needed further research, but the PUSH, URGent, and such
>> mechanisms were a way to start.
>>>>> The ARPANET was the main source of experience at the time. Although
>> it was a packet-switched network, it had a lot of internal mechanisms that
>> created a "virtual circuit" service to the computers attached to it.
>> Everything that went in at a source came out at the destination intact,
>> complete and in sequence.  In effect, the functionality provided by TCP for
>> creating a reliable byte-stream was already also present inside the
>> ARPANET, with mechanisms in the source and destination IMPs for each
>> traffic flow.  Internal messages, such as ALLOcate, travelled between IMPs
>> to implement that mechanism.  Data flow was also regulated to achieve a
>> typical maximum latency of 250 milliseconds - dictated by the desire to
>> have characters typed by the human user quickly processed by the app
>> consuming them.  Scenarios such as "buffer bloat" were not a problem.
>>>>> Those internal mechanisms weren't well known at the time, except by
>> the ARPANET implementers at BBN.  The algorithms and protocols used also
>> changed as the traffic patterns changed over time.   Technology advances,
>> such as the introduction of personal workstations and later PCs, altered
>> the way people used the network.  The internal mechanisms similarly changed
>> as needed.  I was never an ARPANET implementer, but that group was
>> literally right down the hall so I was aware of a lot of the internal
>> issues and mechanisms as I worked on TCP.
>>>>> TCP made significant changes to how networks worked.   Some of these
>> may not be obvious even now.
>>>>> For example, the internal mechanisms in the IMPs were largely
>> invisible to the computers attached to IMPS.   That included
>> Internet-capable computers such as gateways and hosts running TCP. The IMP
>> internal mechanisms could change without the need for TCP/IP code to change
>> at all.   Mechanisms in TCP and gateway implementations needed "rough
>> consensus and running code" within a much larger and geographically
>> scattered community.
>>>>> TCP moved the mechanisms for creating virtual circuit behavior into
>> the users' computers.   That meant that the internal mechanisms operating
>> in the ARPANET had to have some kind of analogous mechanism inside the
>> users' computers' TCP implementations as well as the gateways.
>>>>> Of course such mechanisms would have to be well documented so that
>> all TCP implementations would behave correctly.   The ARPANET approach of
>> having all implementers in close proximity was not practical for The
>> Internet.
>>>>> We didn't know how to do that.   It required further research.
>> Meanwhile, PUSH and URGent and TOS and other such "placeholders" would
>> hopefully be enlightening as The Internet Experiment continued.
>>>>> It's 2025 now.  I still can't stop my printer when I accidentally
>> send it the wrong document to print.
>>>>> Hope this helps explain a bit of the History.
>>>>>
>>>>> Jack Haverty
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 5/15/25 06:15, David Finnigan via Internet-history 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 <mailto:
>> 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 <mailto:
>> 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
>>>
>>>
>>> --
>>> Please send any postal/overnight deliveries to:
>>> Vint Cerf
>>> Google, LLC
>>> 1900 Reston Metro Plaza, 16th Floor
>>> Reston, VA 20190
>>> +1 (571) 213 1346
>>>
>>>
>>> until further notice
>>>
>>>
>>>
>> --
>> 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
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250516/2e3107a5/attachment.asc>

From matt.mathis at gmail.com  Tue May 27 11:31:36 2025
From: matt.mathis at gmail.com (Matt Mathis)
Date: Tue, 27 May 2025 11:31:36 -0700
Subject: [ih] Large scale BGP failure in early 90's
Message-ID: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>

Is there a writeup (or does anybody recall) a large-scale BGP failure in
the early 90s, when one ventor was testing a feature to make routes less
preferred (AS prepending or doubling) which caused all gated based BGP
implementation to lock up?   Unfortunately the processing order was: parse
the test route, forward test route, and then lockup.  So the test route
successfully flooded the entire routing system before locking up all of the
NSFnet and many other networks.

I am looking for a more complete and accurate description of this event.

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.


From frantisek.borsik at gmail.com  Tue May 27 13:47:29 2025
From: frantisek.borsik at gmail.com (Frantisek Borsik)
Date: Tue, 27 May 2025 22:47:29 +0200
Subject: [ih] Large scale BGP failure in early 90's
In-Reply-To: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
References: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
Message-ID: <CAJUtOOiqeUybhu5293cdor4jvFLLrHV+6ALRt+EqTDEZYwKEgQ@mail.gmail.com>

Hey Matt,

Not sure if this is it, but it's the best I remember:
https://www.researchgate.net/publication/220195198_Beware_of_BGP_attacks


All the best,

Frank

Frantisek (Frank) Borsik


*In loving memory of Dave T?ht: *1965-2025

https://libreqos.io/2025/04/01/in-loving-memory-of-dave/


https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik at gmail.com


On Tue, May 27, 2025 at 8:32?PM Matt Mathis via Internet-history <
internet-history at elists.isoc.org> wrote:

> Is there a writeup (or does anybody recall) a large-scale BGP failure in
> the early 90s, when one ventor was testing a feature to make routes less
> preferred (AS prepending or doubling) which caused all gated based BGP
> implementation to lock up?   Unfortunately the processing order was: parse
> the test route, forward test route, and then lockup.  So the test route
> successfully flooded the entire routing system before locking up all of the
> NSFnet and many other networks.
>
> I am looking for a more complete and accurate description of this event.
>
> 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.
> --
> 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
>


From matt.mathis at gmail.com  Tue May 27 15:51:12 2025
From: matt.mathis at gmail.com (Matt Mathis)
Date: Tue, 27 May 2025 15:51:12 -0700
Subject: [ih] Large scale BGP failure in early 90's
In-Reply-To: <A4282F1B-C93F-487D-A79C-69B594299B4D@tony.li>
References: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
 <A4282F1B-C93F-487D-A79C-69B594299B4D@tony.li>
Message-ID: <CA+s1KQEYEa46RbnCQoUj24vNFwpjT7osMoXYG93sokhCD8QsCw@mail.gmail.com>

I vaguely remember that you had a hand in it, but I didn't want to say
anything.

Well, I want to consider contributing part of that story to a draft paper
about other types of centralized failures in otherwise properly
de-centralized systems.    People don't think about standards and
replicated implementations as being non-decentralized resources, but that
story makes the point.

First step, correct some of the details and language in my 2 sentences.
This might be sufficient to enable searching.

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 Tue, May 27, 2025 at 11:37?AM Tony Li <tony.li at tony.li> wrote:

>
> I am the perp.  What would you like to know?
>
> T
>
>
> > On May 27, 2025, at 11:31?AM, Matt Mathis via Internet-history <
> internet-history at elists.isoc.org> wrote:
> >
> > Is there a writeup (or does anybody recall) a large-scale BGP failure in
> > the early 90s, when one ventor was testing a feature to make routes less
> > preferred (AS prepending or doubling) which caused all gated based BGP
> > implementation to lock up?   Unfortunately the processing order was:
> parse
> > the test route, forward test route, and then lockup.  So the test route
> > successfully flooded the entire routing system before locking up all of
> the
> > NSFnet and many other networks.
> >
> > I am looking for a more complete and accurate description of this event.
> >
> > 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.
> > --
> > 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
>
>


From matt.mathis at gmail.com  Tue May 27 15:55:34 2025
From: matt.mathis at gmail.com (Matt Mathis)
Date: Tue, 27 May 2025 15:55:34 -0700
Subject: [ih] Large scale BGP failure in early 90's
In-Reply-To: <CAJUtOOiqeUybhu5293cdor4jvFLLrHV+6ALRt+EqTDEZYwKEgQ@mail.gmail.com>
References: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
 <CAJUtOOiqeUybhu5293cdor4jvFLLrHV+6ALRt+EqTDEZYwKEgQ@mail.gmail.com>
Message-ID: <CA+s1KQHpnQ7Cvz-PtV9uU_LbETYvCC6BeAF4Vvup6SKmArjMdw@mail.gmail.com>

No, that paper was perhaps 10 years later.  The perp reached out to me, so
details might be forthcoming.   (To be clear, the bug was not his at all,
and the technique in question became standard practice for many years).

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 Tue, May 27, 2025 at 1:46?PM Frantisek Borsik <frantisek.borsik at gmail.com>
wrote:

> Hey Matt,
>
> Not sure if this is it, but it's the best I remember:
> https://www.researchgate.net/publication/220195198_Beware_of_BGP_attacks
>
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
> *In loving memory of Dave T?ht: *1965-2025
>
> https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
>
>
> https://www.linkedin.com/in/frantisekborsik
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.borsik at gmail.com
>
>
> On Tue, May 27, 2025 at 8:32?PM Matt Mathis via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> Is there a writeup (or does anybody recall) a large-scale BGP failure in
>> the early 90s, when one ventor was testing a feature to make routes less
>> preferred (AS prepending or doubling) which caused all gated based BGP
>> implementation to lock up?   Unfortunately the processing order was: parse
>> the test route, forward test route, and then lockup.  So the test route
>> successfully flooded the entire routing system before locking up all of
>> the
>> NSFnet and many other networks.
>>
>> I am looking for a more complete and accurate description of this event.
>>
>> 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.
>> --
>> 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
>>
>


From craig at tereschau.net  Wed May 28 00:16:21 2025
From: craig at tereschau.net (Craig Partridge)
Date: Wed, 28 May 2025 03:16:21 -0400
Subject: [ih] Large scale BGP failure in early 90's
In-Reply-To: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
References: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
Message-ID: <CAHQj4CeL50k-L2PpaxUXqErBJskqtgvJX1LW=YkutKwO_S-iTA@mail.gmail.com>

Wasn't that the same pattern that took down the AT&T network c. 1990 (a
busted update that was propagated before being fully processed)?

I seem to recall Dave Mills actually triggered a similar issue in the early
Internet (I do recall he talked about some bug in his code and that some
authority figure, Vint?, was mad at him at the time).

Craig

On Tue, May 27, 2025 at 2:32?PM Matt Mathis via Internet-history <
internet-history at elists.isoc.org> wrote:

> Is there a writeup (or does anybody recall) a large-scale BGP failure in
> the early 90s, when one ventor was testing a feature to make routes less
> preferred (AS prepending or doubling) which caused all gated based BGP
> implementation to lock up?   Unfortunately the processing order was: parse
> the test route, forward test route, and then lockup.  So the test route
> successfully flooded the entire routing system before locking up all of the
> NSFnet and many other networks.
>
> I am looking for a more complete and accurate description of this event.
>
> 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.
> --
> 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
>


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.


From vint at google.com  Wed May 28 02:13:53 2025
From: vint at google.com (Vint Cerf)
Date: Wed, 28 May 2025 05:13:53 -0400
Subject: [ih] Large scale BGP failure in early 90's
In-Reply-To: <CAHQj4CeL50k-L2PpaxUXqErBJskqtgvJX1LW=YkutKwO_S-iTA@mail.gmail.com>
References: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
 <CAHQj4CeL50k-L2PpaxUXqErBJskqtgvJX1LW=YkutKwO_S-iTA@mail.gmail.com>
Message-ID: <CAHxHggc2mQvZ8qMeVOZ9_HnE07ej6i3VCxKi3cgf37YQ=egVsw@mail.gmail.com>

there was a Mother's Day meltdown at AT&T - that might be what you remember.
As to a Mills bug, you might be thinking of the early NSF Fuzzball backbone
that was only 50 Kb/s and instantly congested.
The next version, built by MERIT, IBM and MCI ran on 1.5 Mb/s optical fiber
or wireline using IBM routers (RS series machines??)

I will check with Hans-Werner Braun.

v


On Wed, May 28, 2025 at 3:16?AM Craig Partridge via Internet-history <
internet-history at elists.isoc.org> wrote:

> Wasn't that the same pattern that took down the AT&T network c. 1990 (a
> busted update that was propagated before being fully processed)?
>
> I seem to recall Dave Mills actually triggered a similar issue in the early
> Internet (I do recall he talked about some bug in his code and that some
> authority figure, Vint?, was mad at him at the time).
>
> Craig
>
> On Tue, May 27, 2025 at 2:32?PM Matt Mathis via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
> > Is there a writeup (or does anybody recall) a large-scale BGP failure in
> > the early 90s, when one ventor was testing a feature to make routes less
> > preferred (AS prepending or doubling) which caused all gated based BGP
> > implementation to lock up?   Unfortunately the processing order was:
> parse
> > the test route, forward test route, and then lockup.  So the test route
> > successfully flooded the entire routing system before locking up all of
> the
> > NSFnet and many other networks.
> >
> > I am looking for a more complete and accurate description of this event.
> >
> > 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 <(412)%20654-7529> please leave a message
> if you must call.
> > --
> > 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
> >
>
>
> --
> *****
> Craig Partridge's email account for professional society activities and
> mailing lists.
> --
> 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
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From vint at google.com  Wed May 28 02:15:36 2025
From: vint at google.com (Vint Cerf)
Date: Wed, 28 May 2025 05:15:36 -0400
Subject: [ih] Large scale BGP failure in early 90's
In-Reply-To: <CAHxHggc2mQvZ8qMeVOZ9_HnE07ej6i3VCxKi3cgf37YQ=egVsw@mail.gmail.com>
References: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
 <CAHQj4CeL50k-L2PpaxUXqErBJskqtgvJX1LW=YkutKwO_S-iTA@mail.gmail.com>
 <CAHxHggc2mQvZ8qMeVOZ9_HnE07ej6i3VCxKi3cgf37YQ=egVsw@mail.gmail.com>
Message-ID: <CAHxHggf33wt=WTU0GuBYNbPO_29=msuNbbuTKC3WL-ArYtqf0A@mail.gmail.com>

Gemini:

The early routers of the NSFNET's T1 backbone (starting in 1988) were built
using *IBM RT PC* (RISC Technology Personal Computer) systems.

Specifically, each "backbone node" of the NSFNET T1 network consisted of a
collection of *nine IBM RT systems* working in parallel. These systems ran
*AOS*, which was IBM's version of Berkeley UNIX.

Later, as the NSFNET upgraded to the T3 backbone, the routers were based on
the more powerful *IBM RS/6000* workstations.

On Wed, May 28, 2025 at 5:13?AM Vint Cerf <vint at google.com> wrote:

> there was a Mother's Day meltdown at AT&T - that might be what you
> remember.
> As to a Mills bug, you might be thinking of the early NSF Fuzzball
> backbone that was only 50 Kb/s and instantly congested.
> The next version, built by MERIT, IBM and MCI ran on 1.5 Mb/s optical
> fiber or wireline using IBM routers (RS series machines??)
>
> I will check with Hans-Werner Braun.
>
> v
>
>
> On Wed, May 28, 2025 at 3:16?AM Craig Partridge via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> Wasn't that the same pattern that took down the AT&T network c. 1990 (a
>> busted update that was propagated before being fully processed)?
>>
>> I seem to recall Dave Mills actually triggered a similar issue in the
>> early
>> Internet (I do recall he talked about some bug in his code and that some
>> authority figure, Vint?, was mad at him at the time).
>>
>> Craig
>>
>> On Tue, May 27, 2025 at 2:32?PM Matt Mathis via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>
>> > Is there a writeup (or does anybody recall) a large-scale BGP failure in
>> > the early 90s, when one ventor was testing a feature to make routes less
>> > preferred (AS prepending or doubling) which caused all gated based BGP
>> > implementation to lock up?   Unfortunately the processing order was:
>> parse
>> > the test route, forward test route, and then lockup.  So the test route
>> > successfully flooded the entire routing system before locking up all of
>> the
>> > NSFnet and many other networks.
>> >
>> > I am looking for a more complete and accurate description of this event.
>> >
>> > 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 <(412)%20654-7529> please leave a message
>> if you must call.
>> > --
>> > 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
>> >
>>
>>
>> --
>> *****
>> Craig Partridge's email account for professional society activities and
>> mailing lists.
>> --
>> 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
>>
>
>
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346 <(571)%20213-1346>
>
>
> until further notice
>
>
>
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice


From jack at 3kitty.org  Wed May 28 11:17:12 2025
From: jack at 3kitty.org (Jack Haverty)
Date: Wed, 28 May 2025 11:17:12 -0700
Subject: [ih] Large scale BGP failure in early 90's
In-Reply-To: <CAHQj4CeL50k-L2PpaxUXqErBJskqtgvJX1LW=YkutKwO_S-iTA@mail.gmail.com>
References: <CA+s1KQEwmQhEaEUZK9Vn-5b-O+bt0Az39-ynS1qSWbGsFM9Jbw@mail.gmail.com>
 <CAHQj4CeL50k-L2PpaxUXqErBJskqtgvJX1LW=YkutKwO_S-iTA@mail.gmail.com>
Message-ID: <be410b17-61f1-4588-9ab3-5d4ca42e5fd7@3kitty.org>

Dave Mills was the master researcher, always trying out new ideas on the 
early 80s Internet.?? Sometimes of course there were bugs.? At the same 
time, Vint had tasked my "Gateway Group" at BBN to make the "core 
gateways" into a reliable 24x7 network service, much as the ARPANET had 
become over the previous decade.

Those two goals - research and reliability - conflicted.? After yet 
another Internet disruption, I recruited Dr. Eric Rosen to help figure 
out a solution.? Eric was one of the "ARPANET gurus" and knew a lot 
about what had been done in the ARPANET IMP algorithms to transition it 
from research to operations.

We sat down for an afternoon of brainstorming.? That led to the 
invention of the concept of "Autonomous Systems" (AS), and the 
rudimentary "firewall" protocol of EGP, documented in RFC 827 in October 
1982.?? EGP and AS enabled the "core" gateways to insulate themselves 
from whatever bugs emerged from research activities.?? It was 
essentially a "firewall" mechanism.? Whatever Dave, or anyone else, did 
in their research was much less likely to affect the operation of the 
"core" part of The Internet after EGP was implemented as a "firewall" in 
the core machines.

The notion of AS and EGP was envisioned to be temporary.?? When research 
advanced to rough consensus and solutions, those algorithms and 
techniques would be included in the next version of TCP/IP.? We were 
rather naive in 1982; the 'net evolved quite differently.

The incidents I recall with Dave's Fuzzballs were mostly related to 
routing. ? There were two general kinds of incidents.? One involved 
"black hole" gateways, where some gateway somehow became the best route 
to everywhere.? Another kind was the "counting to infinity" scenario, 
where a routing change took sometimes 15 minutes to take effect, as the 
gateways involved slowly added one to their hop counts until reaching 
"infinity" (set to some number, perhaps 32?). ? While a 
count-to-infinity was in progress, datagrams tended to just "loop" 
around between gateways.?? Users saw that as a minutes-long outage of 
the Internet.

One incident I recall happened when two universities (can't remember 
which) were involved in some kind of joint project and needed to 
exchange lots of data.? Although the Internet worked for that, it was 
somewhat slow to transfer their files.?? So they decided to put in their 
own leased circuit (9.6kb IIRC) directly between their two sites, 
expecting traffic between them to utilize that line and transfers to 
complete more quickly.

They were surprised to see that their file transfers actually became 
much slower with the additional circuit.?? The culprit was the Internet 
routing scheme, which was (still is?) based on "hop counts" rather than 
on datagram transit time.

The ARPANET had been using transit time as the metric for routing for 
many years.? Transit time included time spent in buffers inside IMPs, 
using a real-time clock which had been added to the first IMP 
minicomputers.? Early gateways however lacked such hardware and couldn't 
measure transit time.? Hop counts were an interim approach until the 
hardware was replaced, when a time-based routing approach could be 
introduced.

In the universities scenario, the additional line reduced the "hop 
count" for all sorts of other data flows through the Internet, 
attracting such flows to their new "private" line between their sites.? 
So everything became slower.

Hope this helps explain some of the History.
Jack Haverty




On 5/28/25 00:16, Craig Partridge via Internet-history wrote:
> Wasn't that the same pattern that took down the AT&T network c. 1990 (a
> busted update that was propagated before being fully processed)?
>
> I seem to recall Dave Mills actually triggered a similar issue in the early
> Internet (I do recall he talked about some bug in his code and that some
> authority figure, Vint?, was mad at him at the time).
>
> Craig
>
> On Tue, May 27, 2025 at 2:32?PM Matt Mathis via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> Is there a writeup (or does anybody recall) a large-scale BGP failure in
>> the early 90s, when one ventor was testing a feature to make routes less
>> preferred (AS prepending or doubling) which caused all gated based BGP
>> implementation to lock up?   Unfortunately the processing order was: parse
>> the test route, forward test route, and then lockup.  So the test route
>> successfully flooded the entire routing system before locking up all of the
>> NSFnet and many other networks.
>>
>> I am looking for a more complete and accurate description of this event.
>>
>> 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.
>> --
>> 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
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250528/14674b45/attachment.asc>