Browse Prior Art Database

Towards a transport service for transaction processing applications (RFC0955)

IP.com Disclosure Number: IPCOM000004951D
Original Publication Date: 1985-Sep-01
Included in the Prior Art Database: 2001-Jul-12
Document File: 11 page(s) / 23K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.T. Braden: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 15% of the total text.

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...