Summary

  • In RFC 794, Vint Cerf proposed that a terminal-host process could keep a TCP LISTEN open while serving existing users, then decide whether a higher-precedence arrival displaced a lower-precedence connection.
  • His flash-override FTP example made pre-emption an application decision at the receiving host; a saturated initiating host might also need operating-system action before the urgent request could even leave.

Host X is already moving a routine file to Host Y. From Host Z comes a flash-override request for an FTP connection to X. The SYN reaches the port. Who gets told to leave? A priority bit can announce the visitor, but it cannot tidy up the interrupted transfer. Vint Cerf's September 1981 RFC 794 put the awkward part of pre-emption exactly where work was underway: in the processes using TCP.

Cerf began outside the computer room. A telephone circuit, once taken, held its bandwidth even while idle; a higher-priority caller could cut off a lower-priority one in a saturated circuit system. A store-and-forward message switch could hurry an important message and even interrupt a printer. Packet switches offered a different bottleneck: when full, they could sort traffic waiting to enter. These were three ways of rationing scarce resources. Precedence mattered when the system was crowded; the scarce thing changed from circuit to processor to entry into the packet network.

At a terminal in AUTODIN II, the scarce resource was more personal. Cerf imagined the terminal-host process, or THP, keeping a LISTEN posted on a terminal's port while one or more connections were already active. A new connection could arrive and reveal its precedence. The THP would compare it with the live sessions, close or abort the lowest-ranked one if necessary, switch the user to the newcomer, and post another LISTEN. The machine could receive the knock without promising every caller a seat.

That design asked for the precedence of an incoming connection to be visible to the process. Cerf did not propose a grand new TCP eviction engine. TCP generally served processes; it did not create a terminal-serving process merely because a new request arrived. A disconnected or switched-off terminal would make such a creation particularly silly. The process facing the user knew whether there was a user to switch, which work would be interrupted and what cleanup the interruption required. Cerf also noted the security limits on letting one terminal juggle several connections. The doorman needed a view of the room.

The FTP case made the cost concrete. Host X's FTP service could keep an extra LISTEN available while handling routine transfers. When Z's flash-override SYN arrived, FTP could serve it by displacing a lower-precedence user if it could not accommodate another one. FTP, rather than a bare transport flag, could start the cleanup. A process that kept no pending LISTEN while serving its current users was, under this strategy, non-pre-emptable. The extra open door was a design choice, not a magic property of every TCP session.

There was a second door. Suppose Z's own FTP or TCP resources were already saturated. The urgent user could have priority at X and still be unable to start a request. Cerf moved the decision to Z's operating system: it might have to free local resources, even by logging out lower-precedence users. He left room for precedence to attach to a user or a terminal, and for the operating system or a TCP implementation to make different local choices. The caller could be a VIP; the lobby still needed space.

The two-page memo is a neat piece of architectural restraint. It does not ask one packet field to perform a social act that only a running service can perform. It shows an arriving connection, an occupied host, a process with an extra LISTEN, and a possible cleanup bill. The person losing a file transfer would experience pre-emption as an interruption. Cerf located the decision with the software able to account for that interruption.