Transaction TCP

1,434 views
1,202 views

Published on

Computer networks - Transaction TCP

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,434
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
53
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transaction TCP

  1. 1. Transactional Transmission Control Protocol (T/TCP) CS425A - Computer Networks Srijan Shetty Amardeep Singh Tomar Vikram Rathi
  2. 2. What is a Transaction? Transaction :- REQUEST - Client -> Server , REPLY - Client <- Server RFC955 (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.
  3. 3. 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
  4. 4. 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.
  5. 5. 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 -> 3way handshake by server in normal TCP/IP
  6. 6. Packet Structure
  7. 7. 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.
  8. 8. 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
  9. 9. Practical Applications Transaction-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 in T/TCP being transaction-based, no set-up and shutdown time, data can be passed with minimal delay.
  10. 10. 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 (3way 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.
  11. 11. 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.
  12. 12. DNS Typical 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.
  13. 13. 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.
  14. 14. Performance Analysis
  15. 15. 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
  16. 16. Number of Packets per Transaction Figure 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
  17. 17. Percentage savings Figure 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
  18. 18. Issues
  19. 19. 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.
  20. 20. 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.
  21. 21. Operational Issues ➔ ➔ ➔ 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.
  22. 22. Use Cases ➔ 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
  23. 23. Socket Programming under T/TCP Programming 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.
  24. 24. 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.
  25. 25. ➔ ➔ ➔ ➔ ➔ ➔ 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.
  26. 26. Ending Note Failure 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
  27. 27. 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 (Mark.Stacey@icl.ie) 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

×