Towards a transport service for transaction processing applications
RFC 955

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• rfc955

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.