T/TCP -- TCP Extensions for Transactions Functional Specification
RFC 1644
Document | Type |
RFC - Historic
(July 1994; No errata)
Obsoleted by RFC 6247
Updates RFC 1379
|
|
---|---|---|---|
Author | Robert Braden | ||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 1644 (Historic) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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-layerShow full document text