Movatterモバイル変換

Network Working Group                                            V. CerfRequest for Comments:  794                                          ARPAReplaces: IEN 125                                         September 1981                              PRE-EMPTIONIn circuit-switching systems, once a user has acquired a circuit, thecommunication bandwidth of that circuit is dedicated, even if it is notused.  When the system saturates, additional circuit set-up requests areblocked.  To allow high precedence users to gain access to circuitresources, systems such as AUTOVON associate a precedence with eachtelephone instrument.  Those instruments with high precedence canpre-empt circuit resources, causing lower precedence users to be cutoff.In message switching systems such as AUTODIN I, incoming traffic isstored on disks  (or drums or tape) and processed in order ofprecedence.  If a high precedence message is entered into the system, itis processed and forwarded as quickly as possible.  When the highprecedence message arrives at the destination message switch, it maypre-empt the use of the output devices on the switch, interrupting theprinting of a lower precedence message.In packet switching systems, there is little or no storage in thetransport system so that precedence has little impact on delay forprocessing a packet.  However, when a packet switching system reachessaturation, it rejects offered traffic.  Precedence can be used insaturated packet switched systems to sort traffic queued for entry intothe system.In general, precedence is a tool for deciding how to allocate resourceswhen systems are saturated.  In circuit switched systems, the resourceis circuits; in message switched systems the resource is the messageswitch processor; and in packet switching the resource is the packetswitching system itself.This capability can be realized in AUTODIN II without adding any newmechanisms to TCP (except to make precedence of incoming connectionrequests visible to the processes which use TCP).  To allow pre-emptiveaccess to a particular terminal, the software (i.e., THP) which supportsterminal access to the TAC can be configured so as to always have aLISTEN posted for that terminal, even if the terminal has a connectionin operation.  For example in the ARPANET TENEX systems, the user TELNETpermits a user to have many connections open at one time - the user canswitch among them at will.  To the extent that this can be done withoutviolating security requirements, one could imagine a multi-connectionTHP which always leaves a LISTEN pending for incoming connectionrequests.  If a connection is established, the THP can decide, based onits precedence, whether to pre-empt any existing connection and toswitch the user to the high precedence one.If the user is working with several connections of different precedenceat the same time, the THP would close or abort the lowest precedenceCerf                                                            [Page 1]

                                                          September 1981Pre-Emptionconnection in favor of the higher precedence pre-empting one.  Then theTHP would do a new LISTEN on that terminal's port in case a higherprecedence connection is attempted.One of the reasons for suggesting this model is that processes are theusers of TCP (in general) and that TCP itself cannot cause processes tobe created on behalf of an incoming connection request.  Implementationscould be realized in which TCPs accept incoming connection requests and,based on the destination port number, create appropriate serverprocesses.  In terms of pre-empting access to a remote terminal,however, it seems more sensible to let the process which interfaces theterminal to the system mediate the pre-emption.  If the terminal is notconnected or is turned off, there is no point in creating a process toserve the incoming high precedence connection request.For example, suppose a routine FTP is in operation between Host X andHost Y.  Host Z decides to do a flash-override FTP to Host X.  It opensa high precedence connection via its TCP and the "SYN" goes out to theFTP port on Host X.FTP always leaves one LISTEN pending to pre-empt lower precedence remoteusers if it cannot serve one more user (and still keep a LISTENpending).  In this way, the FTP is naturally in a state permitting thehigh precedence connection request to be properly served, and the FTPcan initiate any cleaning up that is needed to deal with thepre-emption.In general, this strategy permits the processes using TCP to accommodatepre-emption in the context of the applications they support.A non-pre-emptable process is one that does not have a LISTEN pendingwhile it is serving one (or more) users.The actions taken to deal with pre-emption of TCP connections will beapplication-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 highprecedence connection request.  Suppose there is a high precedence userwho wants to open an FTP connection request from Host Z to Host X.  Butall FTP and/or TCP resources are saturated when this user tries to startthe user FTP process.  In this case, the operating system would have toknow about the precedence of the user and would have to locally pre-emptresources on his behalf (e.g., by logging out lower precedence users).This is a system issue, not specific only to TCP.  Implementation ofpre-emption at the source could vary greatly.  Precedence may beassociated with a user or with a terminal.  The TCP implementation maylocally pre-empt resources to serve high precedence users.  Theoperating system may make all pre-emption decisions.[Page 2]                                                            Cerf