RFC 794

PRE-EMPTION ✨

Network Working Group 🎀 Request for Comments: 794 💅

Okay bestie, here's the deal with this one: it was written by V. Cerf from ARPA, dated September 1981. It's RFC 794, it replaces IEN 125 🦋, and the title is PRE-EMPTION. That's the whole header, and now you know who wrote it and when. 🌸

In circuit-switching systems, once a user grabs a circuit, that circuit's bandwidth is dedicated to them, even when they're not actually using it 🙈. When the system is saturated, any new circuit set-up requests just get blocked. 💀 So to let high precedence users still get through, systems like AUTOVON attach a precedence to each telephone instrument. High precedence instruments can pre-empt circuit resources, and that cuts off the lower precedence users. Harsh, but iconic 👑.

In message switching systems like AUTODIN I, incoming traffic gets stored on disks (or drums or tape) and processed in order of precedence ✨. If a high precedence message comes in, it gets processed and forwarded as fast as humanly possible 🚀. When that message reaches the destination message switch, it can pre-empt the output devices on the switch and interrupt the printing of a lower precedence message. Rude! 😭

In packet switching systems, there's little or no storage in the transport system, so precedence doesn't really change how long it takes to process a packet 🧚. But when a packet switching system hits saturation, it rejects offered traffic. Precedence can still be used in saturated packet switched systems to sort the traffic queued up for entry into the system 🍓.

Overall, precedence is basically a tool for deciding how to hand out resources when systems are saturated. In circuit switched systems the resource is circuits. In message switched systems the resource is the message switch processor. And in packet switching the resource is the packet switching system itself. It's giving "decide who gets the last slice of cake" 🎂💜.

This capability can be realized in AUTODIN II without adding any new mechanisms to TCP, except to make the precedence of incoming connection requests visible to the processes that use TCP 🌈. To allow pre-emptive access to a particular terminal, the software (i.e., THP) that supports terminal access to the TAC can be configured to always have a LISTEN posted for that terminal, even if the terminal already has a connection in operation 🫶. For example, in the ARPANET TENEX systems, the user TELNET lets a user keep many connections open at once, and they can switch between them whenever they want 🦋. To the extent that this can be done without violating security requirements, you could imagine a multi-connection THP that always leaves a LISTEN pending for incoming connection requests 👀. If a connection gets established, the THP can decide, based on its precedence, whether to pre-empt any existing connection and switch the user over to the high precedence one 💖.

If the user is juggling several connections of different precedence at the same time, the THP would close or abort the lowest precedence connection in favor of the higher precedence one that's pre-empting it 💅. Then the THP would do a new LISTEN on that terminal's port, just in case a higher precedence connection is attempted 🔥.

One reason for suggesting this model is that processes are (in general) the users of TCP, and TCP itself can't make processes get created on behalf of an incoming connection request 🙈. You could build implementations where TCPs accept incoming connection requests and, based on the destination port number, create the appropriate server processes 🌸. But when it comes to pre-empting access to a remote terminal, it seems more sensible to let the process that interfaces the terminal with the system do the mediating 🧚. If the terminal isn't connected or is turned off, there's no point in creating a process to serve the incoming high precedence connection request 💀.

For example, say a routine FTP is running between Host X and Host Y. Host Z decides to do a flash-override FTP to Host X 😤. It opens a high precedence connection through its TCP, and the SYN goes out to the FTP port on Host X 🚀.

FTP always leaves one LISTEN pending so it can pre-empt lower precedence remote users if it can't serve one more user (and still keep a LISTEN pending) 🫶. That way, FTP is naturally in a state where the high precedence connection request can be properly served, and FTP can start any cleaning up that's needed to deal with the pre-emption 🦋.

In general, this strategy lets the processes using TCP accommodate pre-emption within the context of the applications they support 👑.

A non-pre-emptable process is one that does not have a LISTEN pending while it's serving one (or more) users 🙅‍♀️.

The actions taken to deal with pre-emption of TCP connections will be specific to each application process, and this strategy of a second (or N+1st) LISTEN is well suited to that situation ✨.

Pre-emption may also be necessary at the site that starts a high precedence connection request 🌈. Suppose there's a high precedence user who wants to open an FTP connection request from Host Z to Host X. But all FTP and/or TCP resources are saturated when this user tries to start the user FTP process 😭. In that case, the operating system would have to know the precedence of the user, and it would have to locally pre-empt resources on their behalf (e.g., by logging out lower precedence users) 💅. This is a system issue, not something specific only to TCP 🔥. How you implement pre-emption at the source could vary a lot 🎀. Precedence may be associated with a user or with a terminal. The TCP implementation may locally pre-empt resources to serve high precedence users, or the operating system may make all of the pre-emption decisions 💜.