Internet Networking Spring 2002 Tutorial 11 T/TCP (TCP extension for Transactions)

2 T/TCP - TCP for Transactions. Defined in RFC 1644 (and RFC 1379). Not a standard.

3 Transactions The current Internet protocol suit contains 2 alternative transport service protocols: –TCP - provides virtual circuit service. –UDP - provides datagram service. There is a gap between these two transport protocols and some applications like transactions fall into it. What is a transaction? –A transaction is a request sent by a client to a server along with the server reply.

4 Transactions (cont.) There are many transaction applications, where one side sends the question and the other side replies back with an answer. Some of them are as follows: –Domain Name Server (DNS). –World Wide Web: Hypertext Transfer Protocol. –Remote Procedure Call (RPC). There is the listing of the characteristics of the communication patterns typical in "transaction processing" applications: –Unsymmetrical Model –Simplex Transfers –Short Duration –Low Delay –Few Data Packets –Message Orientation

5 Transactions (cont.) IP was designed to support a variety of transport protocols. –Currently we mostly use TCP and UDP These two protocols provide very different kind of services –UDP provides unreliable datagrams –TCP provides reliable data stream –Applications using TCP are stream orientated. These applications need the ability to reliably send a stream of data between the two cooperating hosts. Telnet, FTP, Rlogin, SMTP are some examples. –Applications using UDP, many times have only a short term relationship between hosts. They send a short burst of data and require a short reply. They are transaction based. NFS,DNS,TFTP,BOOTP, SNMP are some examples.

6 Transactions with UDP A UDP transaction is a very simple transaction as seen in the figure. –The client sends a request datagram to server in 1/2 RTT time. –The server process the request in SPT time and sends back a reply datagram in 1/2 RTT time. The total transaction time is: –RTT + SPT The total number of packets for each transaction is: – 2 (request and reply). Figure: Time line of UDP Transaction

7 Transactions with UDP (cont.) Advantage: –The RTT+SPT transaction time and 2 number of packets are the possible minimum values for a transaction, in other words they are ideal and required properties for a transaction. Disadvantages: UDP has many disadvantages, which are not good for transactions –Datagrams can be lost –reordered –duplicated in other words UDP doesn't provide any reliability. Thus, each application running on UDP has to make a reliable UDP by providing sequence numbers, timeouts, retransmissions, etc. and this causes repetitions in application implementations and also it is as expensive as TCP.

8 Transactions with TCP (cont.) The total number of packets for each transaction is: 9 The transaction time is: 2*RTT+SPT. Figure: Time line for TCP transaction

9 Transactions with TCP (cont.) Advantages: TCP provides – reliable – connection-oriented –ordered –full-duplex byte stream service. Disadvantages: it has many overheads like three way handshake connection establishment (3WHS), four way handshake closing (4WHS), time-wait state and also it has to provide acknowledgments, which increases the number of packets, flow control and connection control.

10 Improved TCP To enhance the performance of TCP some alterations are done to TCP: –It is to piggyback the request with the control segments. As seen from the figure, in the first segment of the 3WHS the request and FIN are send with SYN and in the third segment the FIN is send with the ACK of SYN to the server and so on. However, although the total number of segments reduces to: 5 The total transaction time stays the same as the time for TCP. ( The reason is that still the 3WHS has to be done to prevent old duplicate segments and to initialize the SYN numbers. ) Figure: Time line for improved TCP

11 Transactions with T/TCP: T/TCP solves the problems by providing both a reliable and quick transport for transactions: As seen in the figure, –T/TCP Bypasses the 3WHS connection establishment in TCP by using the information of the old connection. –Requires only 3 segments for each transaction by piggybacking the SYN, FIN and data in the first segment and piggybacking the SYN, FIN, ACK and data in the second segment. –Bypasses the 4WHS closing in TCP (actually T/TCP does not close the connections and use the old connections). –Provides a reliable transfer only in RTT+SPT time. Figure. Time line of T/TCP transaction 1/2 RTP

12 How T/TCP establishes this improvements ? T/TCP bypasses the 3WHS by using the concept TCP Accelerated Open (TAO): –A TCP uses the cached information of the last established connection to immediately validate the new SYN segments. –If this validation fails, because there is no current cached state or the segment is an old duplicate, the 3WHS is done. Thus T/TCP does NOT eliminate the 3WHS, but does it when it is the first time when a connection is established between the hosts. –It uses 32-bit values (Connection Count), that increase monotonically with each transaction between given host pair, as the cached information.

13 New T/TCP Options T/TCP is implemented by adding three new options to the TCP header: –CC (Connection Count) – the CC option can be sent in an initial SYN segment or in other segments only if the other end send a CC or CCnew in its SYN. –Ccnew - the CCnew option can only appear in an initial SYN segment. It is sent when the client needs to perform the normal 3WHS. –Ccecho - the CCecho option can only appear in the second segment of a 3WHS. It echoes the client's CC or CCnew value and tells the client that it supports T/TCP.

14 TAO Test: For each connection, the cache contains the variables in the special tables: –CCsend = CC of data sent –CCrecv = CC of data received Each T/TCP segment carries CCsend value in CC option in TCP header Each T/TCP caches the largest valid CCrecv and CCsend for each connection. If SYN segment's CC > Cache.CCrecv, the segment is valid and accepted else normal 3WHS is done.

15 T/TCP Implementation Variables: T/TCP requires some new information to be maintained by the kernel. As seen before there is a list of variables stored by the kernel as the information of the old established connections. These variables are kept by the kernel: –tcp_ccgen: It is a 32-bit global integer containing the next CC value to use. –Per-host Cache (TAO Cache): tao_cc: Last CC received from this host in a valid SYN. tao_ccsent: The last CC sent to this host in a SYN tao_mssopt: The last MSS received from this host –Per-Connection: cc_send: CC to send with every segment on this connection. cc_recv: CC to receive from the other end in every segment t_duration: How long the connection is established (clock ticks).

16 T/TCP Implementation Variables There are three kind of tables as seen in the figure. The per-host table is kept in the cache, even if there is no current connection to that host, until the timer times out, namely they are permanent tables created when the first time a connection is established with that host. However, a per-connection table is kept as long as the connection is alive, namely they are temporary tables containing information related to the current connection. Figure: Implementation variables of T/TCP

17 T/TCP examples: Client Reboot Time line for transaction after Client Reboot

18 T/TCP examples: Next normal transaction Time line for normal T/TCP transaction

19 T/TCP examples: Server receives an old duplicate SYN Time line for a transaction where server receives an old duplicate SYN

20 T/TCP examples: Next Normal Transaction Time line for the next normal transaction after the server receives an old duplicate syn

21 T/TCP examples: S erver reboots Time line showing the transaction after the server reboots

22 Client forces a 3WHS by sending a CCnew option with its active open if –The client loses state information about the server like client reboot Server forces a 3WHS if –Server receives a SYN with a CC value that is less than the expected value - Old duplicates OR –Server loses state information about client - Server reboot OR –Server doesn't support T/TCP - backward compatibility Server echoes client's CC or CCnew option with CCecho only if the server wants to use T/TCP. Minimal T/TCP transaction of 3 segments and minimum latency RTT+SPT occurs if –Client and Server both support T/TCP AND –Have state information about each other Conclusions from the examples