When TCP/IP was first developed, no one could have foreseen the extent to which the Internet is used today. New protocols are being developed all the time in order to cater for the ever growing needs of the Internet community. Protocols such as HTTP use the underlying transport protocols of TCP/IP which are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol), to establish connections and pass messages around the net. These two transport mechanisms are not necessarily best suited to all types of Internet applications. In particular they are not particularly efficient when dealing with types of client-server Internet architectures such as the web clients and browsers. An extension to TCP/IP, called T/TCP - TCP for transactions - addresses the need to have a specific protocol for client-server transactions. A transaction in this context means a client-server request-response. T/TCP provides all the reliability of TCP with almost as much speed as UDP. It is specifically designed to cater for multiple transactions between a client and a server.
In this article I examine the way in which the TCP protocol establishes and tears down connections. I then compare that with the way that the T/TCP protocol establishes and terminates connections. In doing so I hope to show that T/TCP is more suitable to certain types of Internet applications.
The Transport Layer of the TCP/IP protocol stack is where messages destined for the network are divided into smaller sized segments. The application programmer can choose which Transport Layer protocol they will use. This is the layer that can provide end to end error detection and correction for messages. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) are the transport layer protocols normally used.
TCP provides a reliable end to end connection. It ensures that messages reach their destination and are delivered in the correct sequence across the network. Application data is divided into smaller chunks called segments which are sent across the network. Every segment sent is marked with a sequence number and is acknowledged by the receiver using this sequence number.
UDP, on the other hand, provides an unreliable, connectionless service. This means that when the datagrams that make up a message are sent there is no verification that they have actually reached their destination. They may even arrive out of sequence. There are good reasons why programs would use such a service. UDP is less expensive than TCP. Sometimes the overhead of using TCP (the TCP header) is greater than the actual data being transmitted, the entire message could simply be re-transmitted. Domain Name System (DNS) resolvers (described in a previous article) mainly use UDP for name server queries.
T/TCP provides the reliability TCP, including sequence numbers and acknowledgments, without the overhead of TCP. It simplifies the connection mechanism and it shortens the waiting time at the end of each connection.
In order to establish a TCP connection the initiating application, usually the client, has to send a synchronisation segment (known as a SYN) to the server. This segment contains an initial sequence number. Subsequent segments between the client and the server are numbered starting at the initial sequence number and increasing. These sequence numbers are used to reassemble the segments in the correct order (sequence) to form a complete message. The server responds to this with an acknowledgment (an ACK of the SYN) and its own initial sequence number for synchronisation purposes (SYN). The client must then acknowledge the SYN from the server (an ACK of the SYN). This is known as the TCP three-way handshake.
Terminating a TCP connection requires four segments. This is because TCP supports a half-closed state. A half closed state is when one side of the connection sends a close (a FIN) which means that it will no longer send anything, but it is still listening for anything coming from the other side. The connection is completely terminated when the other side sends its FIN segment. Both of the FIN segments have to be acknowledged hence four segments. Furthermore, when the last of these acknowledgments has been sent, the sender has to keep their connection open for 4 minutes. This is known as the TIME_WAIT state.
There are two reasons for this four minute wait. The first is so that the final ACK can be resent if lost. The server will resend its FIN if it does not receive an ACK within a specified time (known as the retransmission timeout, RTO) and the client stays open long enough so that it will receive the retransmission if sent. The second reason is so that any duplicate segments that have been sent can time out before the port is used again for a new connection (all segments have a limited lifetime on the Internet, they will be simply discarded when this lifetime has expired).
There are two side effects to having a four minute wait. The first limits the number of transactions a client can process a second and the second is concerned with the amount of memory used by keeping a number of connections open.
There are only a finite number of ports available at any time. Since a port address is 16 bits the number of ports is 216 which is 65535. The number of reserved ports is 1023 (reserved for well known servers), so the number of ports available to a client at any time is 65535 - 1023 = 64512. The four minute wait combined with the finite number of available ports means that the number of transactions able to be processed by a client is limited to 64512 / 240 = 268 per second.
For each open connection, the operating system kernel of the host must maintain information about the connection in memory. In a typical Unix TCP/IP implementation each open connection requires 264 bytes of memory. If a host had to keep 64512 connections open at any time this equates to more than 17000000 bytes of memory!
The TCP protocol was designed to support full two-way communication between applications on the Internet. Many applications, however, follow the client server model. The client sends a short request to the server and the server returns a lengthy response. This is a transaction. In a protocol such as HTTP there are many such transactions for a single page. Each picture requires a separate transaction. TCP is used as the underlying protocol to HTTP because of the reliability, however the overhead of TCP causes HTTP to be slower and more network intensive than it needs to be. T/TCP, TCP for transactions, is designed specifically for the client-server architecture. It is ideally suited be an underlying protocol to HTTP and similar higher level protocols.
T/TCP eliminates the TCP three way handshake using a mechanism called TAO, TCP Accelerated Open. A unique identifier is assigned by T/TCP to each connection between itself and another T/TCP host. This identifier is called a connection count. Each time a new connection to the other host is made this connection count is incremented and is sent along with the synchronisation segment (SYN). T/TCP remembers the connection count from each other host for some period of time. When it receives a SYN it checks to see if the sent connection count is greater than the remembered one. If it is then the connection is allowed to proceed without the three way handshake. If not, then the three way handshake proceeds as per normal TCP. This is known as the TAO test.
There are three new options defined by T/TCP. These options can be sent in a T/TCP segment as part of the normal TCP header. They are:
T/TCP still requires 4 segments in order to terminate a connection. Each side has to be able to send a FIN segment and these segments must be acknowledged. As mentioned above, when the last of these acknowledgments has been sent, the sender has to keep their connection open for 4 minutes.
T/TCP speeds up the termination process by shortening this 4 minute wait to about 12 seconds.
The first of the two reasons for the 4 minute wait is so that if the client can wait for the server to resend its FIN in case the final ACK from the client is not received. The time that the server waits until resending the FIN is called the retransmission timeout (RTO). Currently the TIME_WAIT state length is twice the maximum segment lifetime (MSL), the lifetime of a segment on the Internet. T/TCP changes this to eight times the RTO which should be sufficient for retransmisson. There is a possible scenario whereby the final ACK is lost and the client initiates a new connection before it receives a retransmission. If this case occurs then once the TAO test has been passed, the server considers the new connection to acknowledge the previous one. This is an implicit acknowledgment of the final FIN.
The second of the two reasons for the 4 minute delay is so that old duplicate segments may expire. This is not a consideration with T/TCP as the connection count ensures old segments cannot be sent to new connections.
The following diagram compares the TCP and T/TCP time lines. It shows the establishment of a new connection, the termination of this connection and the establishment of a subsequent connection by the same application to the same server.
The following Internet sites run T/TCP:
The following operating systems have available implementations of T/TCP:
SunOS 4.1.4
FreeBSD 2.0.5 and later versions
BSD/OS 2.1
T/TCP optimises transactions after the first connection has been established between any two hosts. T/TCP is not necessarily suited to all Internet applications, consider the DNS. Clients make individual requests to a number of different DNS servers. T/TCP will not help a great deal in this case. T/TCP is best suited to applications where the client waits on some event, like user input, before sending a request to a server. In this case all connections after the first one are optimised. Since T/TCP is an extension to normal TCP, clients and servers that run T/TCP still support normal TCP.
Given the ever increasing number of client server architecture solutions found on the Internet, any sort of saving in terms of time or network traffic is a good saving. In particular HTTP, and similar protocols, would benefit from T/TCP immensely. Given the high percentage of Internet traffic made up by HTTP this would be a saving for everyone.