The first benefit T/TCP can bring to TCP applications is the trucation of TIME_WAIT length. This way, the total number of TCBs is also reduced. For applications that reply on TCP connections short in time (typically under 2 minutes), supporting T/TCP on both sides can result in obvious improvement in overall performance.
The second benefit of T/TCP is the bypassing of 3-way handshake. For applications that exchange a small number of packets with remote servers, the reduction of total connection time by one RTT (round trip time) can be a significant improvement.
WWW
A typical HTTP client-server transaction is like this: The client does active open and sends a short request to the server. The server sends a response after receiving the request and processing the data. Then, the server does active close.
T/TCP is ideal for this transaction. The client can sends the request in its first SYN packet, thus reducing the overal time by one RTT and the number of packets exchanged. This way, both time and bandwidth are saved. The server can reduce the total number of TCBs by truncating TIME_WAIT length. This is especially useful for busy HTTP servers.
DNS
Nowadays, both DNS requests and responses are delivered with UDP. If a DNS response is longer than 512 bytes, only first 512 bytes are sent to the client with UDP, along with a "truncated" flag. Thereafter, the client retransmits the DNS request with TCP and the server transmits the entire DNS response with TCP.
The reason of this method is the possibility that certain hosts may not be able to reassembly IP datagrams longer than 576 bytes. (Actually, many UDP applications limit the length of user's data to 512 bytes.) Because TCP is stream-oriented, the same problem won't occur. During the 3-way handshake, both TCP sides get to know each other's MSS and agree to use the smaller one for the rest of the connection. Thereafter, the sender disassembles user's data into various packets shorter or equal to the negotiated MSS, thus avoiding IP fragmentations. The receiver simply reassembles all the received packets and delivers the received data to upper applications as required.
DNS clients and servers can make good use of T/TCP, which possesses both UDP's time-saving and TCP's reliability.
RPC
Nearly all the papers about applying transmition protocols to transaction processing nominate RPC as a choice. With RPC, the client sends a request to the server that has the procedure to be invoked. The client includes arguments in its request while the server includes in its response the result obtained by running the specified procedure.
Usually RPC packets are large in size, resulting in the necessity of reliability in delivering. T/TCP provides TCP's reliability and avoids TCP's huge overhead of 3-way handshake. All applications that reply on RPC, such as NFS, can use T/TCP for this reason.