rfc955.txt

RFC 相关的技术文档

Network Working Group                                          R. Braden
Request for Comments: 955                                       UCLA OAC
                                                          September 1985

                    Towards a Transport Service for
                  Transaction Processing Applications


STATUS OF THIS MEMO

   This RFC is concerned with the possible design of one or more new
   protocols for the ARPA-Internet, to support kinds of applications
   which are not well supported at present.  The RFC is intended to spur
   discussion in the Internet research community towards the development
   of new protocols and/or concepts, in order to meet these unmet
   application requirements.  It does not represent a standard, nor even
   a concrete protocol proposal.  Distribution of this memo is
   unlimited.

1.  INTRODUCTION

   The DoD Internet protocol suite includes two alternative transport
   service [1] protocols, TCP and UDP, which provide virtual circuit and
   datagram service, respectively [RFC-793, RFC-768].  These two
   protocols represent points in the space of possible transport service
   attributes which are quite "far apart".  We want to examine an
   important class of applications, those which perform what is often
   called "transaction processing".  We will see that the communication
   needs for these applications fall into the gap "between" TCP and UDP
   -- neither protocol is very appropriate.

   We will then characterize the attributes of a possible new
   transport-level protocol, appropriate for these ill-served
   transaction-processing applications.

   In writing this memo, the author had in mind several assumptions
   about Internet protocol development.

      *  Assumption 1: The members of the Internet research community
         now understand a great deal about protocols, and given a list
         of consistent attributes we can probably generate a reasonable
         protocol to meet that specification.

         This is not to suggest that design of good protocols is easy.
         It does reflect an assumption (perhaps wrong) that the set of
         basic protocol techniques we have invented so far is sufficient
         to give a good solution for any point in the attribute space,
         and that we can forsee (at least in a general way) many of the
         consequences of particular protocol design choices.




Braden                                                          [Page 1]



RFC 955                                                   September 1985
Transaction Protocol


      *  Assumption 2: We need to develop appropriate service
         requirements for a "transaction processing protocol".

         The classifications "virtual circuit" and "datagram"
         immediately define in our minds the most important attributes
         of TCP and UDP.  We have no such immediate agreement about the
         services to be provided for transaction processing.  The
         existing and proposed transaction-oriented protocols show a
         number of alternative choices [e.g., Cour81, BiNe84, Coop84,
         Cher85, Crow85, Gurw85, Mill85].

   Many of the ideas discussed here are not new.  For example, Birrell
   and Nelson [BiNe84] and Watson [Wats81] have described
   transport-level protocols appropriate for transactions.  Our purpose
   here is to urge the solution of this problem within the Internet
   protocol family.

2.  TRANSACTION PROCESSING COMMUNICATIONS

   We begin by listing the characteristics of the communication patterns
   typical in "transaction processing" applications.

      *  Unsymmetrical Model

         The two end points of the communication typically take
         different roles, generally called "client" and "server".  This
         leads to an unsymmetrical communication pattern.

         For example, the client always initiates a communication
         sequence or "transaction".  Furthermore, an important subclass
         of applications uses only a simple exchange of messages, a
         "request" to the server followed by a "reply" to the client.

         Other applications may require a continuing exchange of
         messages, a dialog or "conversation".  For example, a request
         to read a file from a file server might result in a series of
         messages, one per file block, in reply. More complex patterns
         may occur.

      *  Simplex Transfers

         Regardless of the pattern, it always consists of a series of
         SIMPLEX data transfers; at no time is it necessary to send data
         in both directions simultaneously.





Braden                                                          [Page 2]



RFC 955                                                   September 1985
Transaction Protocol


      *  Short Duration

         Transaction communication sequences generally have short
         duration, typically 100's of milliseconds up to 10's of
         seconds, but never hours.

      *  Low Delay

         Some applications require minimal communication delay.

      *  Few Data Packets

         In many applications, the data to be sent can be compressed
         into one or a few IP packets.  Applications which have been
         designed with LAN's in mind are typically very careful to
         minimize the number of data packets for each request/reply
         sequence.

      *  Message Orientation

         The natural unit of data which is passed in a transaction is an
         entire message ("record"), not a stream of bytes.

3.  EXAMPLE: NAME SERVERS

   To focus our ideas, we will now discuss several particular types of
   distributed applications which are of pressing concern to members of
   the Internet research community, and which require
   transaction-oriented communication.

   First, consider the name server/name resolver system [RFC-882,
   RFC-883] which is currently being introduced into the (research)
   Internet.  Name servers must use TCP and/or UDP as their transport
   protocol.  TCP is appropriate for the bulk transfers needed to update
   a name server's data base.  For this case, reliability is essential,
   and virtual-circuit setup overhead is negligible compared to the data
   transfer itself.  However, the choice of a transport protocol for the
   transaction traffic -- queries and responses -- is problematic.

      *  TCP would provide reliable and flow-controlled transfer of
         arbitrary-sized queries and responses.  However, TCP exacts a
         high cost as a result of its circuit setup and teardown phases.

      *  UDP avoids the overhead of TCP connection setup.  However, UDP
         has two potentially-serious problems -- (1) unreliable
         communication, so that packets may be lost, duplicated, and/or



Braden                                                          [Page 3]



RFC 955                                                   September 1985
Transaction Protocol


         reordered; and (2) the limitation of a data object
         (query/response) to the 548-byte maximum in a single UDP
         packet.

   At present, name servers are being operated using UDP for transaction
   communication.  Note that name server requests have a special
   property, idempotency; as a result, lost, duplicated, or reordered
   queries do not prevent the name-server system from working.  This
   would seem to favor the use of UDP.

   However, it seems quite likely that the defects of UDP will make it
   unusable for an increasing fraction of queries.

      *  The average size of individual replies will certainly increase,
         as the more esoteric mail lookup features are used, as the host
         population explodes (resulting in a logarithmic increase in
         domain name sizes), and as the number of alternate acceptable
         answers increases.  As a result, a single response will more
         often overflow a single UDP packet.

      *  The average end-to-end reliability will decrease as some of the
         flakier paths of the Internet are brought into use by name
         resolvers.

         This will lead to a serious problem of choosing an appropriate
         retransmission timeout.  A name resolver using UDP cannot
         distinguish packet loss in the Internet from queueing delay in
         the server.  As a result, name servers we have seen have chosen
         long fixed timeouts (e.g., 30 seconds or more).  This will
         result in long delays in name resolution when packets are lost.

         One might think that delays in name resolution might not be an
         issue since most name lookups are done by a mailer daemon.
         However, ARPANET experience with user mail interfaces has shown
         that it is always desirable to verify the correctness of each
         host name as the user enters the "To:" and "CC:" addresses for
         a message. Hence, delays due to lost UDP packets will be
         directly visible to users.

   More generally, the use of UDP violates sound communication system
   design in two important ways:

      *  The name resolver/server applications have to provide timeouts
         and retransmissions to protect against "errors" (losses) in the
         communication system.  This certainly violates network
         transparency, and requires the application to make decisions
         for which it is not well-equipped.


Braden                                                          [Page 4]



RFC 955                                                   September 1985
Transaction Protocol


         As a general design principle, it seems that (Inter-) network
         properties, especially bad properties, ought to a large extent
         to be hidden below the transport-service boundary [2].

      *  The name resolver/server applications must know the maximum
         size of a UDP datagram.

         It is clearly wrong for an application program to contain
         knowledge of the number 576 or 548!  This does not imply that
         there cannot be a limitation on the size of a message, but any
         such limitation should be imposed by the particular
         application-level protocol, not the transport or internetwork
         level.

   It seems that the TCP/UDP choice for name servers presents an ugly
   dilemma.  We suggest that the solution should be a new
   transaction-oriented transport protocol with the following features:

      *  Reliable ("at-least-once") Delivery of Data;

      *  No Explicit Connection Setup or Teardown Phases;

      *  Fragmentation and Reassembly of Messages;

      *  Minimal Idle State in both Client and Server.

4.  ANOTHER EXAMPLE: DISTRIBUTED OPERATING SYSTEMS

   Distributed operating systems represent another potential application
   for a transaction-oriented transport service.  A number of examples
   of distributed operating systems have been built using high-speed
   local area networks (LAN's) for communication (e.g, Cronus, Locus,
   V-System).  Typically, these systems use private communication
   protocols above the network layer, and the private transport-level
   protocol is carefully designed to minimize latency across the LAN.
   They make use of the inherent reliability of the LAN and of simple
   transactions using single-packet exchanges.

   Recently there have been efforts to extend these systems to operate
   across the Internet [Cher85, Shel85].  Since these are not "open"
   systems, there is no requirement that they use a standard transport
   protocol. However, the availability of a suitable transport protocol
   for transactions could considerably simplify development of future
   distributed systems.

   The essential requirement here seems to be packet economy.  The same



Braden                                                          [Page 5]