T/TCP -- TCP Extensions for Transactions Functional Specification
RFC 1644

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

• Versions

Network Working Group                                          R. Braden
Request for Comments: 1644                                           ISI
Category: Experimental                                         July 1994

                T/TCP -- TCP Extensions for Transactions
                        Functional Specification

Status of this Memo

   This memo describes an Experimental Protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   It does not specify an Internet Standard.  Distribution is unlimited.

Abstract

   This memo specifies T/TCP, an experimental TCP extension for
   efficient transaction-oriented (request/response) service.  This
   backwards-compatible extension could fill the gap between the current
   connection-oriented TCP and the datagram-based UDP.

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

Table of Contents

 1. INTRODUCTION ..................................................  2
 2.  OVERVIEW .....................................................  3
    2.1  Bypassing the Three-Way Handshake ........................  4
    2.2  Transaction Sequences ....................................  6
    2.3  Protocol Correctness .....................................  8
    2.4  Truncating TIME-WAIT State ............................... 12
    2.5  Transition to Standard TCP Operation ..................... 14
 3.  FUNCTIONAL SPECIFICATION ..................................... 17
    3.1  Data Structures .......................................... 17
    3.2  New TCP Options .......................................... 17
    3.3  Connection States ........................................ 19
    3.4  T/TCP Processing Rules ................................... 25
    3.5  User Interface ........................................... 28
 4.  IMPLEMENTATION ISSUES ........................................ 30
    4.1  RFC-1323 Extensions ...................................... 30
    4.2  Minimal Packet Sequence .................................. 31
    4.3  RTT Measurement .......................................... 31
    4.4  Cache Implementation ..................................... 32
    4.5  CPU Performance .......................................... 32
    4.6  Pre-SYN Queue ............................................ 33
 6.  ACKNOWLEDGMENTS .............................................. 34
 7.  REFERENCES ................................................... 34
 APPENDIX A.  ALGORITHM SUMMARY ................................... 35

Braden                                                          [Page 1]
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