T/TCP was originally designed to address the need for a more efficient protocol for transaction style applications. The original protocols defined in the TCP/IP reference model were either too verbose or not reliable enough.
T/TCP works by building on the TCP protocol and introducing a number of new options that allow the 3-Way Handshake to be bypassed in certain situations. When this occurs, the transaction can almost realise the minimum number of segments that are required for a data transfer. T/TCP can reduce the average number of segments involved in a transaction from 9 (TCP) to 3 using the TAO test. This has potential benefits to overloaded networks where there is a need to introduce a more efficient protocol.
Analysis of T/TCP shows that it benefits small transaction-oriented transfers more than large scale information transfer. Aspects of transactions can be seen in such cases as the World Wide Web, Remote Procedure Calls and DNS. These applications can benefit from the use of T/TCP in efficiency and speed. T/TCP reduces on average both the number of segments involved in a transaction and the time taken.
As T/TCP is still an experimental protocol, there are problems that need to be addressed. Security problems encountered include the vulnerability to SYN flood attacks and rlogin authentication bypassing. Operational problems include the possibility of duplicate transactions occurring. Problems that occur less frequently would be the wrapping of the CC values on high speed connections and thus opening up a destination host to accepting segments on the wrong connection.
Many people recognise the need for a protocol that favours transaction style processing and are willing to accept T/TCP as the answer. The security considerations lead to the conclusion that T/TCP would be more useful in a controlled environment, one where there is little danger from a would-be attacker who can exploit the weaknesses of the standard. Examples of enclosed environments would be company intranets and networks protected by firewalls. With a lot of companies seeing the web as the future of doing business, internal and external, a system employing T/TCP and some of the improvements to HTTP, such as compression and delta encoding, would result in a dramatic improvement in speed within a company intranet.
Where programmers are willing to accept T/TCP as a solution to their applications, there are only minor modifications needed for the application to become T/TCP aware. For client side programming, it involves the elimination of the connect() and shutdown() function calls, which can be replaced by adding the MSG_EOF flag to the sendto() command. Server side modifications involve simply adding the MSG_EOF flag to the send() function.
In conclusion, research into T/TCP suggests that it is a protocol that is nearly, but not quite, ready to take over transaction processing for general usage. For T/TCP alone, more work needs to be done to develop it further and solve the security and operational problems. Security problems can be solved using other authentication protocols such as kerberos and the authentication facilities of IPv6. Operational problems can be dealt with using greater transaction reliability built into the applications that will use T/TCP, such as two phase commits and transaction logs.
Future work in this area could involve the promotion of T/TCP as a viable alternative to the TCP and UDP protocols for certain applications. T/TCP has been slow to take off, FreeBSD is the most widespread implementation of T/TCP for PC computers. Now that Linux is T/TCP aware, it can push the use of the protocol more. Applications can be easily modified to use T/TCP when available, any applications that involve an open-close connection can use T/TCP efficiently, the more prominent examples would be web browsers, web servers and DNS client-server applications. To a smaller extent, applications such as time, finger and whois daemons can benefit from T/TCP as well. There are many networking utilities available that can take advantage of the efficiency of the protocol, all that is needed is the incentive to do it. Perhaps a more immediate task though, is to port the T/TCP code to the new Linux kernel series, 2.1.x.