RFC 955 (rfc955) - Page 1 of 10

Towards a transport service for transaction processing applications

Alternative Format: Original Text Document
Next >
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
Next >