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

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: Server 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