Transaction TCP

27
Transactional Transmission Control Protocol (T/TCP) CS425A - Computer Networks Srijan Shetty Amardeep Singh Tomar Vikram Rathi

description

Computer networks - Transaction TCP

Transcript of Transaction TCP

Page 1: Transaction TCP

Transactional Transmission Control Protocol (T/TCP)

CS425A - Computer NetworksSrijan ShettyAmardeep Singh TomarVikram Rathi

Page 2: Transaction TCP

What is a Transaction?

Transaction :- REQUEST - Client -> Server , REPLY - Client <- ServerRFC955 (T/TCP) lists some of the common characteristics of transaction processing applications:

● Asymmetrical Model: the two end points take different roles; this is a typical client-server role where the client requests the data and the server responds.

● Short Duration: normally, a transaction runs for a short time span.● Few Data Packets: each transaction is a request for a small piece of information, rather than a

large transfer of information both ways.

Page 3: Transaction TCP

Background to T/TCP● Growth in internet - strain on networks - Efficient data transfer required● Min. packets for transaction = 2 (1 request + 1 response)● UDP allows this but unreliable● T/TCP uses TCP model + Allows reduction in packets

● 3 packets sent using T/TCP = 2 for carrying data + 1 for ACK to server

Allows apps to see data with same

speed as UDP TCP reliability

Page 4: Transaction TCP

Basic operation

● Very similar to a UDP request with a saving of 66% in packets transferred compared to TCP except in cases of large amount of data

Mechanism explained in the next slide.

Page 5: Transaction TCP

TCP Accelerated Open

● TAO - Mechanism by T/TCP to cut down on the number of packets needed to establish a connection with a host.

● Connection Count (CC) - 32-bit incarnation number● Distinct CC value is assigned to each direction of an open connection● Incremental CC values assigned to each connection established, actively or passively● Method to bypass 3-way handshake -

○ Last valid CC value received from each different client cached by server○ CC value is sent with the initial SYN segment to server○ If (Initial CC value for a client) > (Corresponding cached value), CC options (the

increasing numbers) ensures that the SYN is new and can be accepted immediately.

○ If (Initial CC value for a client) < (Corresponding cached value), TAO test fails -> 3-way handshake by server in normal TCP/IP

Page 6: Transaction TCP

Packet Structure

Page 7: Transaction TCP

TIME WAIT in TCP connections● The TIME-WAIT state is a state entered by all TCP connections when the connection has been closed.● The length of time for this state is 240 seconds to allow any duplicate segments still in the network from the

previous connection to expire.

.

Page 8: Transaction TCP

Truncation of TIME WAIT

● The introduction of the CC option in T/TCP allows for the truncation of the TIME-WAIT state.

● The CC option provides protection against old duplicates being delivered to the wrong incarnation of a given connection.

● In the case of short connections (e.g., transactions) that last shorter than MSL, these CC values allow TIME-WAIT state delay to be safely truncated. So as a rule, the truncation can only be performed whenever the duration of the connection is less than the maximum segment lifetime (MSL).

● As with the original TCP, the host that sends the first FIN is required to remain in the TIME-WAIT state for twice the MSL once the connection is completely closed at both ends. This implies that the TIME-WAIT state with the original TCP is 240 seconds as the recommended value for the MSL is 120 seconds

Page 9: Transaction TCP

Practical ApplicationsTransaction-based rather than connection-based, but still must rely on TCP along with the overhead. UDP is the other alternative has no time-outs and retransmissions built inT/TCP being transaction-based, no set-up and shutdown time, data can be passed with minimal delay.

Page 10: Transaction TCP

HTTP ➔ HTTP is the classic transaction style application. ➔ The number of round trips used by this protocol is more than necessary. ➔ With TCP, the transaction is accomplished by connecting to the server (3-

way handshake), requesting the file (GET file), then closing the connection (sending a FIN segment).

➔ T/TCP operates by connecting to the server, requesting the document and closing the connection all in one segment (TAO). It is obvious that bandwidth has been saved.

➔ But with interactive applications that abound HTTP these days, this might prove to be a problem.

Page 11: Transaction TCP

RPC➔ Remote Procedure Calls also adhere to the transaction style paradigm. ➔ A client sends a request to a server for the server to run a function. ➔ The results of are then returned in the reply to the client.

Page 12: Transaction TCP

DNSTypical DNS queries➔ client sends a request with the IP address or a hostname to the server. ➔ The server responds with the hostname or IP address where appropriate. ➔ UDP is the underlying protocol

Advantages of using T/TCP

➔ UDP, makes the process is fast but not reliable. ➔ Furthermore, if the response by the server exceeds 512 bytes of data, data is sent

back to the client with the first 512 bytes and a truncated flag and the client has to resubmit using TCP, because there are no guarantees

➔ T/TCP is the perfect candidate for the DNS protocol, because of its speed and reliability.

Page 13: Transaction TCP

Application Summary➔ T/TCP provides a simple mechanism that allows the number of segments

involved in a data transmission to be reduced--the TAO. ➔ This allows a client to open a connection, send data and close a

connection all in one segment unlike TCP➔ The highest savings result, with small data transfers. ➔ For applications using UDP, it provides speed - lesser than UDP - and

reliability which is a huge win.➔ Best for HTTP, RPCs and DNS are protocols that require the exchange of

small amounts of data.

Page 14: Transaction TCP

Performance Analysis

Page 15: Transaction TCP

Tests to investigate performance(Tests performed by some student researchers)

● Comparison of T/TCP with TCP/IP● A number of executables compiled that returned different sized data to the client● Hosts involved -

○ elendil.ul.ie (running Linux) ○ devilwood.ece.ul.ie (running FreeBSD 2.2.5)

● Tests for 10 different response sizes - to vary the number of segments required to return the full response

● Each request sent 50 times and the results averaged● Maximum segment size = 1460 bytes● Metric used for evaluation -> Number of segments per transaction● Used Tcpdump to examine the packets exchanged● Note - Tcpdump is not entirely accurate. During fast packet exchanges, it tends to drop some

packets to keep up. This accounts for some discrepancies in the results

Page 16: Transaction TCP

Number of Packets per TransactionFigure 3 - Results from testing for the number of segments for T/TCP versus the number of segments for normal TCP/IP.

● Savings of an average of five packets. ● These five packets accounted for in

○ 3-way handshake○ Packets sent to close a connection.

● Lost packets and retransmissions cause discrepancies in the path of the graph.

One interesting point about the average number of segments when using a TCP client and a T/TCP server is that there is still a saving of one segment. A normal TCP transaction requires nine segments, but because the server was using T/TCP, the FIN segment was piggybacked on the final data segment, reducing the number of segments by one. This demonstrates a reduction in segments, even if only one side is T/TCP-aware. Figure 3. Number of Segments versus Size of Data

Transfer

Page 17: Transaction TCP

Percentage savingsFigure 4 - Shows the percentage savings for the different packet sizes.

● The number of packets saved remains fairly constant

● But, Decrease in the overall savings. ● Because of the increase in the number

of packets being exchanged● => T/TCP is more beneficial to small

data exchanges

Figure 4. Percentage Savings per Size of Data Transfer

Page 18: Transaction TCP

Issues

Page 19: Transaction TCP

Memory Issues➔ The main memory drain - the routing table. ➔ For every host - direct connection and to a multi-hop route - an entry in the routing

table. The implementation of T/TCP adds two new fields to this structure, CCrecv and CCsent.

➔ The entire size of this structure is 56 bytes, - not a hog on a small stand-alone host. ➔ On a busy server - major strain on memory. ➔ Linux has a provision to periodically clean the routing table.

◆ next connection - the local host has to reinitiate the three-way handshake with a CCnew segment.

◆ Advantages of not clearing - server only talks to a limited number of hosts; in this case a permanent TAO cache ensures that 3-way TCP handshake is bypassed.

Page 20: Transaction TCP

Security Issues➔ T/TCP opens up the host to certain Denial of Service attacks.

◆ SYN flooding◆ A sock structure for each SYN which may result in the host crashing.◆ SYN cookies in the Linux kernel to combat this attack. SYN cookies cause problems with

T/TCP, as there are no TCP options sent in the cookie, and any data arriving in the initial SYN can't be used immediately.

➔ Attackers can bypass rlogin authentication. ◆ An attacker creates a packet with a false IP address - known to the destination host. ◆ CC options allow the packet to be accepted immediately and the data passed on. ◆ The destination sends a SYNACK to the original IP. When this SYNACK arrives, the original

host sends a reset, as it is not in a SYN-SENT state. ◆ This happens too late, as the command will already have been executed on the destination

host. ◆ Any protocol that uses an IP address as authentication is open to this sort of attack.

Page 21: Transaction TCP

➔ Use of T/TCP in conjunction with protocols such as HTTP have fewer security problems, due to the inability to run any server commands with HTTP.

➔ Wrapping of CC values, on high speed connections.➔ RFC1644 also has a duplicate transaction problem.

◆ Serious for non-idempotent applications.◆ A request is sent to a server, the server process crashes. The client side times

out and retransmits; if the server process recovers in time, it can repeat the same transaction.

◆ Reason - data in a SYN can be immediately passed to the process, rather than in TCP where the three-way handshake takes place.

◆ The use of two-phase commits and transaction logging can eliminate this problem.

Operational Issues

Page 22: Transaction TCP

➔ 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:◆ company intranets◆ networks protected by firewalls.

➔ T/TCP and some of improvements to HTTP, such as compression and delta encoding, would result in a dramatic improvement in speed within a company intranet

Use Cases

Page 23: Transaction TCP

Socket Programming under T/TCPProgramming for T/TCP is slightly different using socket programming. As an example, the chain of system calls to implement a TCP client would be as follows:

● socket: create a socket.● connect: connect to the remote host.● write: write data to the remote host.● shutdown: close one side of the connection.

Whereas with T/TCP, the chain of commands would be:● socket: create a socket.● sendto: connect, send data and close connection. The sendto function must be able to use a

new flag MSG_EOF to indicate to the kernel that it has no more data to send on this connection.Programming under T/TCP is much like programming under UDP.

Page 24: Transaction TCP

Conclusion➔ T/TCP shows that it benefits small, transaction-oriented transfers more than large-scale

information transfers. Aspects of transactions can be seen in such cases: ◆ World Wide Web, ◆ Remote Procedure Calls◆ DNS

➔ T/TCP is still an experimental protocol, there are problems that need to be addressed. ➔ Security problems encountered include the vulnerability:

◆ SYN flood attacks◆ rlogin authentication bypassing.

➔ Operational problems include the possibility:◆ duplicate transactions occurring. ◆ wrapping of the CC values on high-speed connections, thus opening up a destination host

to accepting segments on the wrong connection..

Page 25: Transaction TCP

➔ Where programmers are willing to accept T/TCP as a solution to their applications, minor modifications are needed for the application to become T/TCP-aware.

➔ Research into T/TCP suggests 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 by building greater transaction reliability into the

applications that will use T/TCP, such as two-phase commits and transaction logs.➔ Applications can be easily modified to use T/TCP when available. ➔ To a smaller extent, applications such as time, finger and whois can benefit from T/TCP as well. ➔ Many networking utilities are available that can take advantage of the efficiency of the protocol.

Page 26: Transaction TCP

Ending NoteFailure of the protocol.➔ Most of the data available dates back to 2002.➔ Right about the time when Web 2.0 was released, AJAX took over.➔ Transactions were no more “the buzzword”.➔ Apart from that, you can never bet on a protocol

Page 27: Transaction TCP

Resources● Braun H W, Claffy K C, "Web Traffic Characterization: An Assessment of the Impact of Caching

Documents from NCSA's Web Server", Proceedings of the Second World Wide Web Conference '94: Mosaic and the Web, October 1994

● Mogul J C, Douglis F, Feldmann A, Krishnamurthy B, "Potential Benefits of Delta Encoding and Data Compression for HTTP", ACM SIGCOMM, September 1997

● Prud'Hommeaux E, Lie H W, Lilley C, "Network Performance Effects of HTTP/1.1, CSSI and PNG", ACM SIGCOMM, September 1997

● Stevens W R, TCP/IP Illustrated, Volume 3, TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols, Addison-Wesley, 1996

● Mark Stacey ([email protected]) graduated from the University of Limerick, Ireland, in 1998 with a first class honors degree in Computer Engineering. His interests include Java programming and Web development. He currently works for ICL in the Information Technology Center based in Dublin, Ireland.

● Ivan Griffin● John Nelson