netdev
[Top] [All Lists]

Benefits of a sound T/TCP

To: Netdev <netdev@xxxxxxxxxxx>
Subject: Benefits of a sound T/TCP
From: Laurence <laudney@xxxxxxxx>
Date: Thu, 14 Feb 2002 14:37:14 +0800
Organization: SJTU
Reply-to: laudney@xxxxxxxx
Sender: owner-netdev@xxxxxxxxxxx
        T/TCP is an extension for standard TCP to improve performance. I've 
established "T/TCP for Linux" at http://sourceforge.net/projects/ttcplinux. 
Besides, our website at http://ttcplinux.sourceforge.net is ready. You can 
click the "Overview" tab on the left side to see a succinct description about 
T/TCP. But let me talk about it here first.

        In one scenario, say, "Transaction", will you see most performance 
improvement. The so-called "transaction" means the client connects to the 
server by TCP to send one packet of request and expects one packet of response. 
Then, the client closes the connection. But within seconds, the client has to 
send another packet of request to the same server and expects another packet of 
response. In one word, the connection between one client and one server is 
short in time but quite frequent. Using standard TCP, the brief connection 
requires at least 8 packets of exchange. Using T/TCP, it can be reduced to 3. 
The whole time is reduced by nearly half. Besides, in standard TCP, after 
actively closing the connection, the client is in "TIME_WAIT" state usually for 
240 seconds. During this period, the socket (client.port, client.ip, 
server.port, server.ip) can't be used. Therefore, to start another connection 
immediately, the client must change its port. But, there are limited ports 
(say, 65535) available, which means you can start at most 65535 connections in 
240 seconds. It's a serious limitation. In T/TCP, by introducing special 
mechanism, the TIME_WAIT period is reduced to 12 seconds. You can easily 
calculate the gain.

        When the client or the server needs to send multiple packets of data 
(request or response), T/TCP causes the side to send multiple packets 
continously, instead of sending each one and waiting for the acknowledgement 
before going on, as in standard TCP. Performance gain is also obvious.

        On http://souceforge.net/projects/ttcplinux, there are patch for 2.0.32 
and 2.2.14 finished by two other people in 1997 and 1999 respectively. You may 
need quite a lot of tests.

        I'm writing the patch for 2.4.2, which can be easily transplanted to 
2.4.x in the future. I haven't finished the basic version and therefore haven't 
uploaded the codes into CVS. But if anyone is interested, I can send them by 
email.

--Laudney



<Prev in Thread] Current Thread [Next in Thread>