As per Relevance of the word transport, we have this rfc below:
Network Working Group R.
Request for Comments: 955 UCLA
September 1985
Towards a Transport Service
Transaction Processing
STATUS OF THIS
This RFC is concerned with the possible design of one or more
protocols for the ARPA-Internet, to support kinds of
which are not well supported at present. The RFC is intended to
discussion in the Internet research community towards the
of new protocols and/or concepts, in order to meet these
application requirements. It does not represent a standard, nor
a concrete protocol proposal. Distribution of this memo
unlimited
1.
The DoD Internet protocol suite includes two alternative
service [1] protocols, TCP and UDP, which provide virtual circuit
datagram service, respectively [RFC-793, RFC-768]. These
protocols represent points in the space of possible transport
attributes which are quite "far apart". We want to examine
important class of applications, those which perform what is
called "transaction processing". We will see that the
needs for these applications fall into the gap "between" TCP and
-- neither protocol is very appropriate
We will then characterize the attributes of a possible
transport-level protocol, appropriate for these ill-
transaction-processing applications
In writing this memo, the author had in mind several
about Internet protocol development
* Assumption 1: The members of the Internet research
now understand a great deal about protocols, and given a
of consistent attributes we can probably generate a
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
basic protocol techniques we have invented so far is
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
consequences of particular protocol design choices
Braden [Page 1]
RFC 955 September 1985
Transaction
* Assumption 2: We need to develop appropriate
requirements for a "transaction processing protocol".
The classifications "virtual circuit" and "datagram
immediately define in our minds the most important
of TCP and UDP. We have no such immediate agreement about
services to be provided for transaction processing.
existing and proposed transaction-oriented protocols show
number of alternative choices [e.g., Cour81, BiNe84, Coop84,
Cher85, Crow85, Gurw85, Mill85].
Many of the ideas discussed here are not new. For example,
and Nelson [BiNe84] and Watson [Wats81] have
transport-level protocols appropriate for transactions. Our
here is to urge the solution of this problem within the
protocol family
2. TRANSACTION PROCESSING
We begin by listing the characteristics of the communication
typical in "transaction processing" applications
* Unsymmetrical
The two end points of the communication typically
different roles, generally called "client" and "server".
leads to an unsymmetrical communication pattern
For example, the client always initiates a
sequence or "transaction". Furthermore, an important
of applications uses only a simple exchange of messages,
"request" to the server followed by a "reply" to the client
Other applications may require a continuing exchange
messages, a dialog or "conversation". For example, a
to read a file from a file server might result in a series
messages, one per file block, in reply. More complex
may occur
* Simplex
Regardless of the pattern, it always consists of a series
SIMPLEX data transfers; at no time is it necessary to send
in both directions simultaneously
Braden [Page 2]
RFC 955 September 1985
Transaction
* Short
Transaction communication sequences generally have
duration, typically 100's of milliseconds up to 10's
seconds, but never hours
* Low
Some applications require minimal communication delay
* Few Data
In many applications, the data to be sent can be
into one or a few IP packets. Applications which have
designed with LAN's in mind are typically very careful
minimize the number of data packets for each request/
sequence
* Message
The natural unit of data which is passed in a transaction is
entire message ("record"), not a stream of bytes
3. EXAMPLE: NAME
To focus our ideas, we will now discuss several particular types
distributed applications which are of pressing concern to members
the Internet research community, and which
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
protocol. TCP is appropriate for the bulk transfers needed to
a name server's data base. For this case, reliability is essential
and virtual-circuit setup overhead is negligible compared to the
transfer itself. However, the choice of a transport protocol for
transaction traffic -- queries and responses -- is problematic
* TCP would provide reliable and flow-controlled transfer
arbitrary-sized queries and responses. However, TCP exacts
high cost as a result of its circuit setup and teardown phases
* UDP avoids the overhead of TCP connection setup. However,
has two potentially-serious problems -- (1)
communication, so that packets may be lost, duplicated, and/
Braden [Page 3]
RFC 955 September 1985
Transaction
reordered; and (2) the limitation of a data
(query/response) to the 548-byte maximum in a single
packet
At present, name servers are being operated using UDP for
communication. Note that name server requests have a
property, idempotency; as a result, lost, duplicated, or
queries do not prevent the name-server system from working.
would seem to favor the use of UDP
However, it seems quite likely that the defects of UDP will make
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
population explodes (resulting in a logarithmic increase
domain name sizes), and as the number of alternate
answers increases. As a result, a single response will
often overflow a single UDP packet
* The average end-to-end reliability will decrease as some of
flakier paths of the Internet are brought into use by
resolvers
This will lead to a serious problem of choosing an
retransmission timeout. A name resolver using UDP
distinguish packet loss in the Internet from queueing delay
the server. As a result, name servers we have seen have
long fixed timeouts (e.g., 30 seconds or more). This
result in long delays in name resolution when packets are lost
One might think that delays in name resolution might not be
issue since most name lookups are done by a mailer daemon
However, ARPANET experience with user mail interfaces has
that it is always desirable to verify the correctness of
host name as the user enters the "To:" and "CC:" addresses
a message. Hence, delays due to lost UDP packets will
directly visible to users
More generally, the use of UDP violates sound communication
design in two important ways
* The name resolver/server applications have to provide
and retransmissions to protect against "errors" (losses) in
communication system. This certainly violates
transparency, and requires the application to make
for which it is not well-equipped
Braden [Page 4]
RFC 955 September 1985
Transaction
As a general design principle, it seems that (Inter-)
properties, especially bad properties, ought to a large
to be hidden below the transport-service boundary [2].
* The name resolver/server applications must know the
size of a UDP datagram
It is clearly wrong for an application program to
knowledge of the number 576 or 548! This does not imply
there cannot be a limitation on the size of a message, but
such limitation should be imposed by the
application-level protocol, not the transport or
level
It seems that the TCP/UDP choice for name servers presents an
dilemma. We suggest that the solution should be a
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
Distributed operating systems represent another potential
for a transaction-oriented transport service. A number of
of distributed operating systems have been built using high-
local area networks (LAN's) for communication (e.g, Cronus, Locus
V-System). Typically, these systems use private
protocols above the network layer, and the private transport-
protocol is carefully designed to minimize latency across the LAN
They make use of the inherent reliability of the LAN and of
transactions using single-packet exchanges
Recently there have been efforts to extend these systems to
across the Internet [Cher85, Shel85]. Since these are not "open
systems, there is no requirement that they use a standard
protocol. However, the availability of a suitable transport
for transactions could considerably simplify development of
distributed systems
The essential requirement here seems to be packet economy. The
Braden [Page 5]
RFC 955 September 1985
Transaction
minimal two-packet exchange used over the LAN should be
across the Internet. This leads to two requirements for
distributed operating systems
* No Explicit Connection Setup or Teardown Phases
* Implicit ("piggy-backed") Acknowledgments Whenever Possible
This implies that the response packet will serve as an
acknowledgment to the request packet (when timing makes
possible). Similarly, a new request (for the same pair
addressable entities) would implicitly acknowledge the
response, if it came soon enough
The nature of the application imposes two other requirements
* Reliable ("at-most-once"), Ordered
However, it should be possible to relax the reliability to
advantage of special cases like an idempotent request
* Multicast
The transport service should mesh cleanly with the
Internet multicast facility, using host groups [ChDe85].
5. OBJECTIVES FOR A
We believe that it is possible to design a new transport protocol
the Internet which is suitable for a wide variety
transaction-oriented applications. Such a transport protocol
have the following attributes
* Reliable
Data will be delivered reliably, i.e., exactly once, or
sender will be informed. The protocol must be able to
loss, duplication, and reordering of request and
packets. In particular, old duplicate request packets must
cause erroneous actions
It should also be possible for the application programs
request that the reliability be relaxed for
transactions. This would allow communication economies in
case of idempotent requests or of notification without reply
Braden [Page 6]
RFC 955 September 1985
Transaction
* Minimum Number of Packets in Simple
In the simplest case (small messages, no packet losses, and
interval between requests and replies between the same pair
addressable entities shorter than applicable timeouts),
simple two-packet exchange should result
* No Explicit Connection Setup or Teardown
The protocol will not create virtual circuits, but will
what is sometimes (confusingly) called "reliable datagram
service
However, in order to provide a minimum two-packet exchange
there must be some implicit state or "soft" virtual
between a pair of addressable entities. In recent
this has been dubbed a "conversation", to distinguish it from
connection
* Minimal Idle
When a server is not processing a transaction, there will be
state kept (except enough to recognize old duplicate
and to suppress unneeded ACK packets).
* Fragmentation/Reassembly of Large
There is a range of possible objectives here. The
requirement is that the application not have to know the
576, 548, etc. For example, each application might
its own "natural" upper limit on the size of a message,
always provide a buffer of that size [3].
At the other extreme, the protocol might allow very
messages (e.g., a megabyte or more). In this case,
proposed protocol would, in the large-message limit,
performing the bulk data transfer function of TCP. It would
interesting to know whether this is possible, although it
not necessarily a requirement
The introduction of multi-packet messages leads to the
issues of window sizes and flow control. The challenge is
handle these efficiently in the absence of connection setup
* Message
Braden [Page 7]
RFC 955 September 1985
Transaction
The basic unit of communication will be an entire message,
a stream of bytes. If a message has to be segmented, it
be delivered in units of segments or buffers, not bytes
* Multicast
Based on this discussion, we can suggest some of the key issues
problems in design of this protocol
* Choice of Addressable
What will be the addressable entity? It must be unique
space; must it be unique in time (even across system crashes) ?
* Timeout
Timeouts must be the key to operation of this protocol
Experience with TCP has shown the need for dynamic selection
an appropriate timeout, since Internet delays range over
decimal orders of magnitude
However, the absence of connection setup and
typically-short duration of a single interaction seem
preclude the dynamic measurement of delays
* Multi-Packet
How can flow control be provided for multi-packet messages,
provide reasonable throughput over long-delay paths
overrun with short-delay paths, when there is no
circuit setup
* Implementation
The protocol should lend itself to efficient (which
implies simple) implementations, so that hosts will be
to use it over LAN's as well as for general
communication
We believe further study is needed on these questions
The reader may wonder: how is the proposed protocol related to an
(Remote Procedure Call) facility? The intent is that RPC
and message-passing IPC facilities will be built on top of
proposed transport layer. These higher-level mechanisms will need
address a number of additional issues, which are not relevant to
communication substrate
Braden [Page 8]
RFC 955 September 1985
Transaction
1. Application
This includes binding and stub generators
2. Structured Data
3. Server Location and
4. Authentication and Access
6.
Distributed processing and distributed data bases will underlie
of the future computer system research projects and
based upon the Internet. As a result, transaction-
communication will be an increasingly important activity on
Internet. We claim that there is a pressing need for an
transport protocol for transaction processing. In this memo, we
given examples to support this claim, and have outlined the
which such a new transport protocol would provide
This memo is based upon discussions within the New End-to-
Protocols taskforce, and it is a pleasure to acknowledge
participation and sagacity of the members of that group. I want
thank Dave Clark, an ex officio taskforce member, for
contribution to these discussions, and Robert Cole for very
suggestions
NOTES
[1] For the purposes of this RFC, in fact, the reader may
"transport service" to be defined as that protocol layer
contains TCP and UDP, as in Figure 1 of RFC-791. Alternatively
we may use the ISO definition -- the transport service is
lowest layer providing end-to-end service which is
independent of the characteristics of the particular (Inter-)
network used to support the communication
[2] This idea is implicit in the ISO definition of a
service
[3] It would be reasonable for the name server definition to
an upper bound on the size of a single query or response; e.g.,
2K bytes. This would imply (large) limits on the number of RR'
that could be returned per response. If that limit is exceeded
we are doing something wrong
Braden [Page 9]
RFC 955 September 1985
Transaction
BiNe84 Birrell, Andrew D. and Nelson, Bruce Jay, "
Remote Procedure Calls". ACM TOCS, Vol. 2, No. 1,
1984.
ChDe85 Cheriton, David R. and Deering, Steven, "Host Groups:
Multicast Extension for Datagram Networks". To be
to 9th Data Communication Symposium
Cher85 Cheriton, David R., "V Message Transaction Protocol".
Private communication, July 1985.
Cour81 Xerox Corp., "Courier: The Remote Procedure Call Protocol".
XSIS 038112, Xerox Corp., Stamford, Conn., December 1981.
Coop84 Cooper, Eric C., "Circus: a Replicated Procedure
Facility". Proc. 4th Symposium on Reliability
Distributed Software and Database Systems, October 1984.
Crow85 Crowcroft, Jon, "A Sequential Exchange Protocol".
Note 1688, Computer Science Department, University
London, June 1985.
Gurw85 Gurwitz, Robert F., "Object Oriented
Communication in the Internet". Private communication
April 1985.
Mill85 Miller, Trudy, "Internet Reliable Transaction Protocol --
Functional and Interface Specification". RFC-938,
1985.
Shel85 Sheltzer, Alan B. , "Network Transparency in an
Environment", PhD Thesis, UCLA Department of
Science, July 1985.
Wats81 Watson, Richard W., "Timer-based Mechanisms in
Transport Protocol Connection Management".
Networks, Vol. 5, pp47-56, 1981 (also distributed
IEN-193).
Braden [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
