WHY T/TCP

The TCP protocol implements a virtual-circuit transport service that provides reliable and ordered data delivery over a full-duplex connection.

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.

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.

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.

So we choose an alternative approach to providing a transaction transport protocol: extending TCP to implement the transaction service model, while continuing to support the virtual circuit model. Each transaction will then be a single instance of a TCP connection.

WHAT IS T/TCP

T/TCP is an extension for standard TCP. Its aim is to bypass 3-way handshake and reduce TIME_WAIT perild.

To bypass 3-way handshake, T/TCP introduces TAO (TCP Accelerated Open). Both TAO and the truncation of TIME_WAIT period depends on CC (connection count). CC increase monotonically with successive transactions (connections) between a given (client, server) host pair.

COMPARISON BETWEEN STANDARD TCP AND T/TCP

The first three segments in Figure 1 implement the standard TCP three-way handshake. The request data included on the initial SYN segment cannot be delivered to user B until segment #3 completes the 3-way handshake. Loading control bits onto the segments has reduced the total number of segments to 5, but the client still observes a transaction latency of 2*RTT + SPT. The 3-way handshake thus precludes high-performance transaction processing.

The TCP close sequence also poses a performance problem for transactions: one or both end(s) of a closed connection must remain in "TIME-WAIT" state until a 4 minute timeout has expired. The same connection (defined by the host and port numbers at both ends) cannot be reopened until this delay has expired. Because of TIME-WAIT state, a client program should choose a new local port number (i.e., a different connection) for each successive transaction. However, the TCP port field of 16 bits (less the "well-known" port space) provides only 64512 available user ports. This limits the total rate of transactions between any pair of hosts to a maximum of 64512/240 = 268 per second. This is much too low a rate for low-delay paths, e.g., high-speed LANs. A high rate of short connections (i.e., transactions) could also lead to excessive consumption of kernel memory by connection control blocks in TIME- WAIT state.

Figure 2 shows the simplest case for T/TCP: each side has cached the latest CC value of the other, and the CC value in the client's SYN segment is greater than the value in the cache at the server host. As a result, B can accept the client A's request data1 immediately and pass it to the server application. B's reply data2 is shown piggybacked on the segment. As a result of this 2-way exchange, the cached CC values are updated at both sites.

 

REFERENCE

R. Braden (ISI November 1992) Request for Comments: 1379 "Extending TCP for Transactions-Concepts"