RFC 1644 (rfc1644) - Page 2 of 38

T/TCP -- TCP Extensions for Transactions Functional Specification

RFC 1644                    Transaction/TCP                    July 1994


 Security Considerations .......................................... 38
 Author's Address ................................................. 38

1. INTRODUCTION

   TCP was designed to around the virtual circuit model, to support
   streaming of data.  Another common mode of communication is a
   client-server interaction, a request message followed by a response
   message.  The request/response paradigm is used by application-layer
   protocols that implement transaction processing or remote procedure
   calls, as well as by a number of network control and management
   protocols (e.g., DNS and SNMP).  Currently, many Internet user
   programs that need request/response communication use UDP, and when
   they require transport protocol functions such as reliable delivery
   they must effectively build their own private transport protocol at
   the application layer.

   Request/response, or "transaction-oriented", communication has the
   following features:

   (a)  The fundamental interaction is a request followed by a response.

   (b)  An explicit open or close phase may impose excessive overhead.

   (c)  At-most-once semantics is required; that is, a transaction must
        not be "replayed" as the result of a duplicate request packet.

   (d)  The minimum transaction latency for a client should be RTT +
        SPT, where RTT is the round-trip time and SPT is the server
        processing time.

   (e)  In favorable circumstances, a reliable request/response
        handshake should be achievable with exactly one packet in each
        direction.

   This memo concerns T/TCP, an backwards-compatible extension of TCP to
   provide efficient transaction-oriented service in addition to
   virtual-circuit service.  T/TCP provides all the features listed
   above, except for (e); the minimum exchange for T/TCP is three
   segments.

   In this memo, we use the term "transaction" for an elementary
   request/response packet sequence.  This is not intended to imply any
   of the semantics often associated with application-layer transaction
   processing, like 3-phase commits.  It is expected that T/TCP can be
   used as the transport layer underlying such an application-layer
   service, but the semantics of T/TCP is limited to transport-layer
   services such as reliable, ordered delivery and at-most-once



Braden