Extending TCP for Transactions -- Concepts
RFC 1379

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

• Versions

Network Working Group                                          R. Braden
Request for Comments: 1379                                           ISI
                                                           November 1992

               Extending TCP for Transactions -- Concepts

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This memo discusses extension of TCP to provide transaction-oriented
   service, without altering its virtual-circuit operation.  This
   extension would fill the large gap between connection-oriented TCP
   and datagram-based UDP, allowing TCP to efficiently perform many
   applications for which UDP is currently used.  A separate memo
   contains a detailed functional specification for this proposed
   extension.

   This work was supported in part by the National Science Foundation
   under Grant Number NCR-8922231.

TABLE OF CONTENTS

   1. INTRODUCTION ..................................................  2
   2. TRANSACTIONS USING STANDARD TCP ...............................  3
   3. BYPASSING THE 3-WAY HANDSHAKE .................................  6
      3.1  Concept of TAO ...........................................  6
      3.2  Cache Initialization ..................................... 10
      3.3  Accepting <SYN,ACK> Segments ............................. 11
   4. SHORTENING TIME-WAIT STATE .................................... 13
   5. CHOOSING A MONOTONIC SEQUENCE ................................. 15
      5.1  Cached Timestamps ........................................ 16
      5.2  Current TCP Sequence Numbers ............................. 18
      5.3  64-bit Sequence Numbers .................................. 20
      5.4  Connection Counts ........................................ 20
      5.5  Conclusions .............................................. 21
   6. CONNECTION STATES ............................................. 24
   7. CONCLUSIONS AND ACKNOWLEDGMENTS ............................... 32
   APPENDIX A: TIME-WAIT STATE AND THE 2-PACKET EXCHANGE ............ 34
   REFERENCES ....................................................... 37
   Security Considerations .......................................... 38
   Author's Address ................................................. 38

Braden                                                          [Page 1]
RFC 1379              Transaction TCP -- Concepts          November 1992

1. INTRODUCTION

   The TCP protocol [STD-007] implements a virtual-circuit transport
   service that provides reliable and ordered data delivery over a
   full-duplex connection.  Under the virtual circuit model, the life of
   a connection is divided into three distinct phases: (1) opening the
   connection to create a full-duplex byte stream; (2) transferring data
   in one or both directions over this stream; and (3) closing the
   connection.  Remote login and file transfer are examples of
   applications that are well suited to virtual-circuit service.

   Distributed applications, which are becoming increasingly numerous
   and sophisticated in the Internet, tend to use a transaction-oriented
   rather than a virtual circuit style of communication.  Currently, a
   transaction-oriented Internet application must choose to suffer the
   overhead of opening and closing TCP connections or else build an
   application-specific transport mechanism on top of the connectionless
   transport protocol UDP.  Greater convenience, uniformity, and
   efficiency would result from widely-available kernel implementations
   of a transport protocol supporting a transaction service model [RFC-
   955].

   The transaction service model has the following features:

   *    The fundamental interaction is a request followed by a response.

   *    An explicit open or close phase would impose excessive overhead.

   *    At-most-once semantics is required; that is, a transaction must
        not be "replayed" by a duplicate request packet.

   *    In favorable circumstances, a reliable request/response
        handshake can be performed with exactly one packet in each
        direction.

   *    The minimum transaction latency for a client is RTT + SPT, where
        RTT is the round-trip time and SPT is the server processing
        time.

   We use the term "transaction transport protocol" for a transport-
   layer protocol that follows this model [RFC-955].

   The Internet architecture allows an arbitrary collection of transport
   protocols to be defined on top of the minimal end-to-end datagram
   service provided by IP [Clark88].  In practice, however, production
   systems implement only TCP and UDP at the transport layer.  It has
   proven difficult to leverage a new transport protocol into place, to
   be widely enough available to be useful for application builders.

Braden                                                          [Page 2]