Extending TCP for Transactions -- Concepts
RFC 1379
| Document | Type |
RFC - Historic
(November 1992; No errata)
Obsoleted by RFC 6247
Updated by RFC 1644
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | Legacy | ||
| Formats | plain text pdf html 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
Show full document text