RFC 955

Network Working Group 💖 R. Braden, UCLA OAC, September 1985 🦋

Towards a Transport Service for Transaction Processing Applications ✨

This is RFC 955 (filed under "Network Working Group") by R. Braden of UCLA OAC, dated September 1985. The copy I'm working from doesn't have a category, obsoletes, or updates line, so I'm not adding one. What it does say is in the Status section: this is not a standard, and it's not even a concrete protocol proposal. 🎀

Status of This Memo 📜

okay so bestie, this RFC is about possibly designing one or more new protocols for the ARPA-Internet to support kinds of apps that aren't well supported right now. 🌸 It's meant to get the Internet research community talking about new protocols and/or concepts that could meet these unmet application requirements. It's NOT a standard, and it isn't a concrete protocol proposal either 🙈. Distribution of this memo is unlimited 💅.

1. INTRODUCTION ✨

okay so the DoD Internet protocol suite has two alternative transport service [1] protocols, TCP and UDP 🦋. TCP gives you virtual circuit service and UDP gives you datagram service [RFC-793, RFC-768]. They're literally on opposite ends of the transport service spectrum 🌈. We want to look at a really important group of apps, the ones that do what people call "transaction processing" 💼. The vibe we'll see is that these apps' communication needs fall into the gap between TCP and UDP. Neither protocol is very appropriate for them 😭.

We'll then describe the attributes a possible new transport-level protocol would need, one that's designed for these ill-served transaction-processing apps 🧚.

While writing this memo, the author had a few assumptions about Internet protocol development in mind:

• Assumption 1: The Internet research community now understands a great deal about protocols, so if we're given a list of consistent attributes, we can probably generate a reasonable protocol to meet that spec ✨.

Designing good protocols is not easy, and this memo isn't claiming otherwise 🙃. It does reflect an assumption (maybe a wrong one) that the basic protocol techniques we've invented so far are enough to give a good solution at any point in the attribute space. It also assumes we can foresee, at least in a general way, many of the consequences of particular protocol design choices 🧠.

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

The labels "virtual circuit" and "datagram" instantly tell us the most important attributes of TCP and UDP 💜. For transaction processing, though, we don't have that same instant agreement about what services should be provided. The existing and proposed transaction-oriented protocols show a bunch of different choices [e.g., Cour81, BiNe84, Coop84, Cher85, Crow85, Gurw85, Mill85] 🌈.

Lots of these ideas aren't new 👑. Birrell and Nelson [BiNe84] and Watson [Wats81] already described transport-level protocols that are suited to transactions. The goal here is to push for solving this problem inside the Internet protocol family 💖.

2. TRANSACTION PROCESSING COMMUNICATIONS 🎀

First up, let's list the characteristics of the communication patterns that show up a lot in "transaction processing" apps 💅.

• Unsymmetrical Model

The two endpoints of the communication usually take different roles, typically called "client" and "server" 🫶. That makes the communication pattern unsymmetrical.

For example, the client always starts a communication sequence, aka a "transaction" 🚀. An important subclass of apps just uses a simple exchange of messages: a "request" goes to the server, then a "reply" goes back to the client 📨.

Other apps might need a continuing exchange of messages, which is called a dialog or "conversation" 💬. For example, a request to read a file from a file server might get back a series of messages in reply, one per file block 📂. More complex patterns can happen too 🌀.

• Simplex Transfers

No matter the pattern, it always comes down to a series of SIMPLEX data transfers. At no point is it necessary to send data in both directions at the same time 🙌.

• Short Duration

Transaction communication sequences usually have short duration, typically from 100's of milliseconds up to 10's of seconds, but never hours ⏱️💀.

• Low Delay

Some apps need minimal communication delay ⚡.

• Few Data Packets

In lots of apps, the data to send can be squished into one or a few IP packets 📦. Apps that were designed with LANs in mind are usually super careful to minimize the number of data packets for each request/reply sequence 🤏.

• Message Orientation

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

3. EXAMPLE: NAME SERVERS 🌸

To make our ideas concrete, let's look at a few specific types of distributed apps that the Internet research community is really worried about, and that need transaction-oriented communication 🧁.

First, check out the name server/name resolver system [RFC-882, RFC-883], which is currently being rolled out into the (research) Internet 🌐. Name servers have to use TCP and/or UDP as their transport protocol. TCP is a good fit for the bulk transfers needed to update a name server's database. In that case, reliability is essential, and virtual-circuit setup overhead is negligible compared to the data transfer itself 💪. The tricky part is picking a transport protocol for the transaction traffic, meaning queries and responses 😵‍💫.

• TCP would give you reliable, flow-controlled transfer of arbitrary-sized queries and responses ✅. The catch is that TCP has a high cost because of its circuit setup and teardown phases 😤.
• UDP skips the overhead of TCP connection setup 🏃. But UDP has two potentially serious problems: (1) it's unreliable, so packets may be lost, duplicated, and/or reordered; and (2) a data object (query/response) is limited to the 548-byte maximum in a single UDP packet 📏.

Right now, name servers are operated with UDP for transaction communication 🤷‍♀️. Here's the thing: name server requests have a special property called idempotency 🔁. Because of that, lost, duplicated, or reordered queries don't stop the name-server system from working. This would seem to favor using UDP 💜.

BUT it seems pretty likely that UDP's defects will make it unusable for a growing fraction of queries 😬.

• The average size of individual replies will definitely increase 📈. That's because more esoteric mail lookup features are getting used, the host population is exploding (which causes a logarithmic increase in domain name sizes), and the number of alternate acceptable answers keeps going up. So a single response will more and more often overflow a single UDP packet 🫠.
• The average end-to-end reliability will go down as some of the flakier paths of the Internet get used by name resolvers 🌧️.

This leads to a serious problem in choosing an appropriate retransmission timeout ⏳. A name resolver using UDP can't tell packet loss in the Internet apart from queueing delay in the server 🤔. So the name servers we've seen have picked long fixed timeouts (e.g., 30 seconds or more). That means lost packets cause long delays in name resolution 🐢.

You might think delays in name resolution wouldn't matter much, since most name lookups are done by a mailer daemon 📬. But ARPANET experience with user mail interfaces has shown it's always desirable to verify the correctness of each host name as the user types in the "To:" and "CC:" addresses for a message 👀. So delays from lost UDP packets will be directly visible to users 😩.

More generally, using UDP breaks sound communication system design in two important ways 🚨:

• The name resolver/server apps have to provide timeouts and retransmissions to protect against "errors" (losses) in the communication system. This definitely breaks network transparency, and makes the app make decisions it isn't well-equipped for 🥴.

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

• The name resolver/server apps 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! 😱 That doesn't mean a message size limit can't exist. But any such limit should be imposed by the particular application-level protocol, not by the transport or internetwork level 🙅‍♀️.

So the TCP/UDP choice for name servers presents a super ugly dilemma 💀. We suggest the solution should be a new transaction-oriented transport protocol with these 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 🌙.

---

okay bestie, that's the first half of the tea ☕💅. The next part picks up from here, so stay tuned 🦋✨

4. ANOTHER EXAMPLE: DISTRIBUTED OPERATING SYSTEMS 🌸

Okay, next up: distributed operating systems 🖥️ This is another place where a transaction-oriented transport service could be a total game changer. A bunch of these systems have been built on high-speed local area networks (LAN's) for communication (e.g, Cronus, Locus, V-System). Usually they use private communication protocols above the network layer, and the private transport-level protocol is carefully designed to minimize latency across the LAN. They lean on the inherent reliability of the LAN and on simple transactions using single-packet exchanges. Iconic, honestly. 💅

Recently people have been trying to get these systems to work across the Internet [Cher85, Shel85]. Since these are not "open" systems, there is no requirement that they use a standard transport protocol. 🫶 But a suitable transport protocol for transactions could seriously simplify development of future distributed systems. Think about how much easier life would be 🥹

The essential requirement here seems to be packet economy ✨ The same minimal two-packet exchange used over the LAN should be possible across the Internet. This leads to two requirements for supporting 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 implicit acknowledgment to the request packet (when timing makes this possible). Similarly, a new request (for the same pair of addressable entities) would implicitly acknowledge the previous response, if it came soon enough. Smart and efficient, no cap 🧚

The nature of the application imposes two other requirements:

• Reliable ("at-most-once"), Ordered Delivery

However, it should be possible to relax the reliability to take advantage of special cases like an idempotent request. 🍓

• Multicast Capability

The transport service should mesh cleanly with the proposed Internet multicast facility, using host groups [ChDe85]. 🌈

5. OBJECTIVES FOR A PROTOCOL 💜

We believe it's possible to design a new transport protocol for the Internet that's suitable for a wide variety of transaction-oriented applications. Such a transport protocol would have the following attributes, and honestly, the list is giving main character energy 👑

• Reliable Delivery

Data will be delivered reliably, i.e., exactly once, or the sender will be informed. The protocol must be able to handle loss, duplication, and reordering of request and response packets. In particular, old duplicate request packets must not cause erroneous actions. 🙈

It should also be possible for the application programs to request that the reliability be relaxed for particular transactions. This would allow communication economies in the case of idempotent requests or of notification without reply. ✨

• Minimum Number of Packets in Simple Cases

In the simplest case (small messages, no packet losses, and the interval between requests and replies between the same pair of addressable entities shorter than applicable timeouts), a simple two-packet exchange should result. Chef's kiss 🤌

• No Explicit Connection Setup or Teardown Phases

The protocol will not create virtual circuits, but will provide what is sometimes (confusingly) called "reliable datagram" service. Ugh, the naming 😭

However, in order to provide a minimum two-packet exchange, there must be some implicit state or "soft" virtual circuit between a pair of addressable entities. In recent discussions this has been dubbed a "conversation", to distinguish it from a connection. 💬

• Minimal Idle State

When a server is not processing a transaction, there will be no state kept (except enough to recognize old duplicate packets and to suppress unneeded ACK packets). Lowkey minimalist queen 🦋

• Fragmentation/Reassembly of Large Messages

There is a range of possible objectives here. The minimum requirement is that the application not have to know the number 576, 548, etc. For example, each application might establish its own "natural" upper limit on the size of a message, and always provide a buffer of that size [3].

At the other extreme, the protocol might allow very large messages (e.g., a megabyte or more). In this case, the proposed protocol would, in the large-message limit, be performing the bulk data transfer function of TCP. It would be interesting to know whether this is possible, although it is not necessarily a requirement. 🤔

The introduction of multi-packet messages leads to the complex issues of window sizes and flow control. The challenge is to handle these efficiently in the absence of connection setup. 😤

• Message Orientation

The basic unit of communication will be an entire message, not a stream of bytes. If a message has to be segmented, it will be delivered in units of segments or buffers, not bytes. 📦

• Multicast Capability

Based on this discussion, we can suggest some of the key issues and problems in design of this protocol. The tea is spilling 🫖

• Choice of Addressable Entity

What will be the addressable entity? It must be unique in space; must it be unique in time (even across system crashes)? 🤯

• Timeout Dynamics

Timeouts must be the key to operation of this protocol. Experience with TCP has shown the need for dynamic selection of an appropriate timeout, since Internet delays range over four decimal orders of magnitude. 📈

However, the absence of connection setup and the typically-short duration of a single interaction seem to preclude the dynamic measurement of delays. 🥲

• Multi-Packet Messages

How can flow control be provided for multi-packet messages, to provide reasonable throughput over long-delay paths without overrun with short-delay paths, when there is no virtual circuit setup? 🚦

• Implementation Efficiency

The protocol should lend itself to efficient (which probably implies simple) implementations, so that hosts will be willing to use it over LAN's as well as for general Internet communication. 🛠️

We believe further study is needed on these questions. Bestie, we are not done yet 🧐

The reader may wonder: how is the proposed protocol related to an RPC (Remote Procedure Call) facility? The intent is that RPC facilities and message-passing IPC facilities will be built on top of the proposed transport layer. These higher-level mechanisms will need to address a number of additional issues, which are not relevant to the communication substrate:

1. Application Interface

This includes binding and stub generators.

2. Structured Data Encoding
3. Server Location and Binding
4. Authentication and Access Control

6. CONCLUSION 🎀

Distributed processing and distributed data bases will underlie many of the future computer system research projects and applications based upon the Internet. As a result, transaction-based communication will be an increasingly important activity on the Internet. We claim that there is a pressing need for an appropriate transport protocol for transaction processing. In this memo, we have given examples to support this claim, and have outlined the service which such a new transport protocol would provide. So that's the whole case, bestie 🫶

This memo is based upon discussions within the New End-to-End Protocols taskforce, and it is a pleasure to acknowledge the participation and sagacity of the members of that group. The author wants to thank Dave Clark, an ex officio taskforce member, for his contribution to these discussions, and Robert Cole for very helpful suggestions. Gratitude energy 🌷

NOTES ✨

• [1] For the purposes of this RFC, in fact, the reader may consider "transport service" to be defined as that protocol layer which contains TCP and UDP, as in Figure 1 of RFC-791. Alternatively, we may use the ISO definition -- the transport service is the lowest layer providing end-to-end service which is essentially 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 transport service.
• [3] It would be reasonable for the name server definition to specify 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's that could be returned per response. If that limit is exceeded, we are doing something wrong! 🚨

REFERENCES 📚

• BiNe84 Birrell, Andrew D. and Nelson, Bruce Jay, "Implementing Remote Procedure Calls". ACM TOCS, Vol. 2, No. 1, February 1984.
• ChDe85 Cheriton, David R. and Deering, Steven, "Host Groups: a Multicast Extension for Datagram Networks". To be presented 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 Call Facility". Proc. 4th Symposium on Reliability in Distributed Software and Database Systems, October 1984.
• Crow85 Crowcroft, Jon, "A Sequential Exchange Protocol". Internal Note 1688, Computer Science Department, University College London, June 1985.
• Gurw85 Gurwitz, Robert F., "Object Oriented Interprocess Communication in the Internet". Private communication, April 1985.
• Mill85 Miller, Trudy, "Internet Reliable Transaction Protocol -- Functional and Interface Specification". RFC-938, February 1985.
• Shel85 Sheltzer, Alan B. , "Network Transparency in an Internetwork Environment", PhD Thesis, UCLA Department of Computer Science, July 1985.
• Wats81 Watson, Richard W., "Timer-based Mechanisms in Reliable Transport Protocol Connection Management". Computer Networks, Vol. 5, pp47-56, 1981 (also distributed as IEN-193).