Extending TCP for Transactions -- Concepts
RFC 1379
Document | Type |
RFC - Historic
(November 1992; No errata)
Obsoleted by RFC 6247
Updated by RFC 1644
|
|
---|---|---|---|
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 1379 (Historic) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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]Show full document text