The RFC Archive
 The RFC Archive   RFC 794   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 794

Pre-emption

Last modified on Thursday, October 15th, 1992

Permanent link to RFC 794
Search GitHub Wiki for RFC 794
Show other RFCs mentioning RFC 794



Network Working Group                                            V. Cerf
Request for Comments:  794                                          ARPA
Replaces: IEN 125                                         September 1981
                              PRE-EMPTION

In circuit-switching systems, once a user has acquired a circuit, the
communication bandwidth of that circuit is dedicated, even if it is not
used.  When the system saturates, additional circuit set-up requests are
blocked.  To allow high precedence users to gain access to circuit
resources, systems such as AUTOVON associate a precedence with each
telephone instrument.  Those instruments with high precedence can
pre-empt circuit resources, causing lower precedence users to be cut
off.

In message switching systems such as AUTODIN I, incoming traffic is
stored on disks  (or drums or tape) and processed in order of
precedence.  If a high precedence message is entered into the system, it
is processed and forwarded as quickly as possible.  When the high
precedence message arrives at the destination message switch, it may
pre-empt the use of the output devices on the switch, interrupting the
printing of a lower precedence message.

In packet switching systems, there is little or no storage in the
transport system so that precedence has little impact on delay for
processing a packet.  However, when a packet switching system reaches
saturation, it rejects offered traffic.  Precedence can be used in
saturated packet switched systems to sort traffic queued for entry into
the system.

In general, precedence is a tool for deciding how to allocate 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.

This capability can be realized in AUTODIN II without adding any new
mechanisms to TCP (except to make precedence of incoming connection
requests visible to the processes which use TCP).  To allow pre-emptive
access to a particular terminal, the software (i.e., THP) which supports
terminal access to the TAC can be configured so as to always have a
LISTEN posted for that terminal, even if the terminal has a connection
in operation.  For example in the ARPANET TENEX systems, the user TELNET
permits a user to have many connections open at one time - the user can
switch among them at will.  To the extent that this can be done without
violating security requirements, one could imagine a multi-connection
THP which always leaves a LISTEN pending for incoming connection
requests.  If a connection is established, the THP can decide, based on
its precedence, whether to pre-empt any existing connection and to
switch the user to the high precedence one.

If the user is working with several connections of different precedence
at the same time, the THP would close or abort the lowest precedence


Cerf                                                         PAGE 1 top


September 1981 Pre-Emption connection in favor of the higher precedence pre-empting one. Then the THP would do a new LISTEN on that terminal's port in case a higher precedence connection is attempted. One of the reasons for suggesting this model is that processes are the users of TCP (in general) and that TCP itself cannot cause processes to be created on behalf of an incoming connection request. Implementations could be realized in which TCPs accept incoming connection requests and, based on the destination port number, create appropriate server processes. In terms of pre-empting access to a remote terminal, however, it seems more sensible to let the process which interfaces the terminal to the system mediate the pre-emption. If the terminal is not connected or is turned off, there is no point in creating a process to serve the incoming high precedence connection request. For example, suppose a routine FTP is in operation between Host X and Host Y. Host Z decides to do a flash-override FTP to Host X. It opens a high precedence connection via its TCP and the "SYN" goes out to the FTP port on Host X. FTP always leaves one LISTEN pending to pre-empt lower precedence remote users if it cannot serve one more user (and still keep a LISTEN pending). In this way, the FTP is naturally in a state permitting the high precedence connection request to be properly served, and the FTP can initiate any cleaning up that is needed to deal with the pre-emption. In general, this strategy permits the processes using TCP to accommodate pre-emption in the context of the applications they support. A non-pre-emptable process is one that does not have a LISTEN pending while it is serving one (or more) users. The actions taken to deal with pre-emption of TCP connections will be application-process specific and this strategy of a second (or N+1st) LISTEN is well suited to the situation. Pre-emption may also be necessary at the site initiating a high precedence connection request. Suppose there is 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 this case, the operating system would have to know about the precedence of the user and would have to locally pre-empt resources on his behalf (e.g., by logging out lower precedence users). This is a system issue, not specific only to TCP. Implementation of pre-emption at the source could vary greatly. Precedence may be associated with a user or with a terminal. The TCP implementation may locally pre-empt resources to serve high precedence users. The operating system may make all pre-emption decisions. [Page 2] Cerf

Pre-emption RFC TOTAL SIZE: 5906 bytes PUBLICATION DATE: Thursday, October 15th, 1992 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 794: The IETF Trust, Thursday, October 15th, 1992
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement