TCP for Transactions LG #47 (2024)

"Linux Gazette...making Linux just a little more fun!"

T/TCP is an experimental extension for the TCP protocol. It was designed toaddress the need for a transaction-based transport protocol in the TCP/IPstack. TCP and UDP are the current choices available for transaction-basedapplications. Both of these protocols have their advantages and disadvantages.TCP is reliable but inefficient for transactions whereas UDP is unreliable buthighly efficient. T/TCP sits between these two protocols making it analternative for certain applications.

Currently, a number of flavours of UNIX support T/TCP. SunOS 4.1.3 (aBerkeley-derived kernel) was the very first implementation of T/TCP andmade available in September 1994. The next implementation was for FreeBSD2.0 and released in March 1995. For my final year project, I implementedT/TCP for Linux for the University of Limerick in April 1998. The sourcecode is available at http://www.csn.ul.ie/~heathclf/fyp/.

In this article, I discuss the operation, advantages and flaws ofT/TCP. This will allow application developers to decide when T/TCP isappropriate for networking applications. I present my results of a comparativeanalysis between T/TCP and TCP based on the number of packets per session foreach transaction, as well as my conclusions on a case study into the possibleimpact of T/TCP on the World Wide Web.

1 Introduction

The most popular implementation of the transport layer in thereference model is the Transmission Control Protocol (TCP). This is aconnection-oriented protocol. Another popular implementation is the UserDatagram Protocol (UDP), which is a connectionless protocol.

Both of these protocols have advantages and disadvantages. The two mainaspects of the protocols make them useful in different areas. UDP is aconnectionless protocol. UDP always assumes that the destination hostreceived the data correctly. The application layer above it looks aftererror detection and recovery. Even though UDP is unreliable, it is quitefast and useful for applications, such as DNS (Domain Name System)where speed is preferred over reliability. TCP, on the other hand, is areliable, connection-oriented protocol. It looks after error detection andrecovery. Data is retransmitted automatically if a problem is detected. Asa result of being more reliable, TCP is a slower protocol than UDP.

In recent years, with the explosion of the Internet, a need for a newspecification arose. The current transport protocols were either tooverbose or not reliable enough. A protocol was needed that was faster thanTCP but more reliable than UDP. These protocols lie at either end of thescale in taking into account speed and reliability. TCP has reliabilityat the cost of speed, whereas UDP has speed at the cost of reliability. Astandard was needed, that would allow the reliable transmission of dataat a faster rate than the current TCP standard. This new protocol couldreduce bandwidth and increase the transmission speed of data.

TCP for Transactions (T/TCP) is envisioned as the successor to bothTCP and UDP in certain applications. T/TCP is a transaction-orientedprotocol based on a minimum transfer of segments, so it doesnot have the speed problems associated with TCP. By building on TCP,it does not have the unreliability problems associated with UDP. Withthis in mind, RFC1379 was published in November 1992. It discussedthe concepts involved in extending the TCP protocol to allow for atransaction-oriented service, as opposed to a connection-oriented servicefor TCP and a connectionless service for UDP. Some of the main pointsthat the RFC discussed were the bypassing of the 3-way handshake and theshortening of the TIME-WAIT state from 240 seconds to 12 seconds. T/TCPcuts out much of the unnecessary handshaking and error detection of thecurrent TCP protocol and as a result increases the speed of connectionand reduces the necessary bandwidth. Eighteen months later, RFC1644 waspublished, with the specification for Transaction TCP.

2 Transaction Transmission Control Protocol

2.1 What is a Transaction?

• Unsymmetrical model: the two end points take different roles, this isa typical client-server role where the client requests the data and theserver responds.
• Short duration: normally a transaction runs for a short time span.
• Few data packets: each transaction is a request for a small piece ofinformation rather than a large transfer of information both ways.

2.2 Background to T/TCP

The growth of the Internet has put a strain on the bandwidth and speedof networks. With more users than ever, the need for a moreefficient form of data transfer is needed.

The absolute minimum number of packets required for a transactionis two: one request followed by one response. UDP is the one protocol inthe TCP/IP protocol stack that allows this, the problem here being theunreliability of the transmission.

T/TCP solves these problems to a large degree. It has thereliability of TCP and comes very close to realizing the two-packetexchange (three in fact). T/TCP uses the TCP state model for its timingand retransmission of data, but introduces a new concept to allow thereduction in packets.

Even though three packets are sent using T/TCP, the data is carriedon the first two; thus, the applications can see the data withthe same speed as UDP. The third packet is the acknowledgment to theserver by the client that it has received the data, which incorporates the TCPreliability.

2.3 Basic Operation

Figure 1. Time Line of T/TCP/Client-Server Transaction

Consider a DNS system, one where a client sends a request to aserver and expects a small amount of data in return. A diagram of thetransaction can be seen in Figure 1. This diagram is very similarto a UDP request. In comparison to the TCP 3-way handshake in Figure2 it can be seen that an equal number of packets arerequired for this transaction and the 3-way handshake. Whereas with TCPthree packet transmissions are associated with the establishmentof a connection alone (with nine altogether), a total of threepacket transmissions are associated with the whole process--a savings of66% in packets transferred compared to TCP. Obviously, in cases where alarge amount of data is being transferred, more packets will betransmitted, resulting in a decrease in the percentage saving. Timingexperiments have shown a slightly longer time is required forT/TCP than for UDP, but this is a result of the speed of the computerand not the network. As computers get more powerful, the performance ofT/TCP will approach that of UDP.

Figure 2. TCP 3-way handshake

2.4 TCP Accelerated Open

The TCP Accelerated Open (TAO) is a mechanism introduced by T/TCPdesigned to cut down the number of packets needed to establishconnection with a host.

T/TCP introduces a number of new options. Theseoptions allow the establishment of a connection with a host using theTAO. T/TCP uses a 32-bit incarnation number, called a connection count(CC). This option is carried in the options part of a T/TCP segment,Figure 3. A distinct CC value is assigned to each direction of anopen connection. Incremental CC values are assigned to each connectionthat a host establishes, either actively or passively.

Figure 3. TCP Header

The 3-way handshake is bypassed using the CC value. Each server hostcaches in memory (or in a file) the last valid CC value it received fromeach different client host. This CC value is sent with the initial SYNsegment to the server. If the initial CC value for a particular clienthost is larger than the corresponding cached value, the property of theCC options (the increasing numbers) ensures the SYN segment is newand can be accepted immediately.

The TAO test fails if the CC option that arrives in the SYN segment issmaller than the last CC value received and cached by the host or ifa CCnew option is sent. The server then initiates a 3-way handshake inthe normal TCP/IP fashion. Thus, the TAO test is anenhancement to TCP, with the normal 3-way handshake to fall back on forreliability and backward compatibility.

2.5 Truncation of TIME-WAIT

The TIME-WAIT state is a state entered by all TCP connectionswhen the connection has been closed. The length of time for this stateis 240 seconds to allow any duplicate segments still inthe network from the previous connection to expire. The introductionof the CC option in T/TCP allows for the truncation of the TIME-WAITstate. The CC option provides protection against old duplicates beingdelivered to the wrong incarnation of a given connection.

Time constraints are placed on this truncation, however. Because the CC value fromthe host is monotonically increasing, thenumbers may wrap around from the client host. A CC value that is thesame as some duplicate segments from the previous incarnation can beencountered. As a rule, the truncation can only be performed wheneverthe duration of the connection is less than the maximum segment lifetime(MSL). The recommended value for the MSL is 120 seconds. As with theoriginal TCP, the host that sends the first FIN is required to remain inthe TIME-WAIT state for twice the MSL once the connection is completelyclosed at both ends. This implies that the TIME-WAIT state with theoriginal TCP is 240 seconds, even though some implementations of TCPhave the TIME-WAIT set to 60 seconds. Stevens shows how the TIME-WAITstate for T/TCP may be shortened to 12 seconds.

CC options do have problems when used on networks with high-speedconnections. This is rarely a problem on older networks, but withFDDI and gigabit Ethernets becoming more frequent, the wrapping ofthe CC value will become more frequent. In this situation,the CC value may wrap around fast enough for problemsto occur. Whereas CC options are not sufficient in certain conditions,the PAWS (protection against wrapped sequences) option adds anotherlayer of security against this problem.

2.6 Examples

T/TCP can be beneficial to some of the applications which currentlyuse TCP or UDP. At the moment, many applications aretransaction-based rather than connection-based, but still must relyon TCP along with the overhead. UDP is the other alternative, but nothaving time-outs and retransmissions built into the protocol means theapplication programmers must supply the time outs and reliabilitychecking. Since T/TCP is transaction-based, there is noset-up and shutdown time, so the data can be passed to the processwith minimal delay.

2.6.1 HTTP and RPC

Hypertext Transfer Protocol is the protocol used by the World WideWeb to access web pages. The number of round trips used by this protocolis more than necessary. T/TCP can be used to reduce the number ofpackets required.

HTTP is the classic transaction style application. The client sendsa short request to the server requesting a document or an image andthen closes connection. The server then sends on the information to theclient. T/TCP can be used to improve this process and reduce the numberof packets on the network.

With TCP, the transaction is accomplished by connecting to the server(3-way handshake), requesting the file (GET file), then closing theconnection (sending a FIN segment). T/TCP operates by connectingto the server, requesting the document and closing the connection allin one segment (TAO). It is obvious that bandwidth has been saved.

Remote Procedure Calls also adhere to the transaction style paradigm. Aclient sends a request to a server for the server to run a function. Theresults of the function are then returned in the reply to theclient. Only a tiny amount of data is transferred with RPCs.

2.6.2 DNS

The Domain Name System is used to resolve host names into the IP addressesthat are used to locate the host.To resolve a domain name, the client sends a request with the IP addressor a host name to the server. The server responds with the host name orIP address where appropriate. This protocol uses UDP as its underlyingprocess.

As a result of using UDP, the process is fast but notreliable. Furthermore, if the response by the server exceeds 512 bytesof data, it sends the data back to the client with the first 512 bytesand a truncated flag. The client has to resubmit the request using TCP,since there is no guarantee that the receivinghost will be able to reassemble an IP datagram exceeding 576 bytes. Forsafety, many protocols limit the user data to 512 bytes.

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

2.7 Summary

T/TCP provides a simple mechanism that allows the number of segmentsinvolved in a data transmission to be reduced--the TAO. This test allowsa client to open a connection, send data and close a connection all inone segment. With TCP, opening a connection, transmission of dataand the closing of the connection are all completely separate processes.

The highest savings result with small data transfers. This leads to theconclusion that T/TCP favors situations with small amounts of data tobe transferred. HTTP, RPCs and DNS are protocols that requirethe exchange of small amounts of data.

3. Testing and Analysis

In order to investigate the benefits or drawbacks of thisimplementation of T/TCP, it is important to both test its operation andcompare it to the original TCP/IP operation. I performedthese tests using the Linux 2.0.32 kernel with T/TCP modifications andFreeBSD version 2.2.5 that already implements T/TCP.

3.1 Operation Examples

This section demonstrates the operation of the protocol under variousconditions.

3.1.1 Client Reboot

In this scenario, I rebooted the client and the TAO cache has beenreinitialized.

When the client attempts a connection with a server, it finds that thelatest CC value received from the server is undefined. Hence it sendsa CCnew option to indicate that a 3-way handshake is needed.

The sequence of segments below conforms to the protocol implementation.

elendil.ul.ie.2177 > devilwood.ece.ul.ie.8888: SFP 3066875000:3066875019(19) win 15928 <mss 1460,nop,nop,ccnew 10> (DF)devilwood.ece.ul.ie.8888 > elendil.ul.ie.2177: S 139872882:139872882(0) ack 3066875001 win 17424 <mss 1460,nop,nop,cc 3, nop,nop,ccecho 10> (DF)elendil.ul.ie.2177 > devilwood.ece.ul.ie.8888: F 20:20(0) ack 1 win 15928 <nop,nop,cc 10> (DF)devilwood.ece.ul.ie.8888 > elendil.ul.ie.2177: . ack 21 win 17405 <nop,nop,cc 3> (DF)devilwood.ece.ul.ie.8888 > elendil.ul.ie.2177: FP 1:31(30) ack 21 win 17424 <nop,nop,cc 3> (DF)elendil.ul.ie.2177 > devilwood.ece.ul.ie.8888: . ack 32 win 15928 <nop,nop,cc 10> (DF) 3.1.2 Normal T/TCP Transaction

The client and the server hold state information about the other host,so the TAO test succeeds and the minimal 3-segment exchange is possible.

elendil.ul.ie.2178 > devilwood.ece.ul.ie.8888: SFP 2021229800:2021229819(19) win 15928 <mss 1460,nop,nop,cc 11> (DF)devilwood.ece.ul.ie.8888 > elendil.ul.ie.2178: SFP 164103774:164103804(30) ack 2021229821 win 17424 <mss 1460,nop,nop,cc 4, nop,nop,ccecho 11>(DF)elendil.ul.ie.2178 > devilwood.ece.ul.ie.8888: . ack 32 win 15928 <nop,nop,cc 11> (DF)

3.1.3 Server Reboot

If the server is rebooted after the previous two tests, all the stateinformation about the host will be lost.

When the client request arrives with a normal CC option, the serverforces a 3-way handshake since the CC value received from the clientis undefined. The SYNACK segment forces the 3-way handshake whenonly the client SYN and not the data are acknowledged.

elendil.ul.ie.2141 > devilwood.ece.ul.ie.8888: SFP 2623134527:2623134546(19) win 15928 <mss 1460,nop,nop,cc 9> (DF)arp who-has elendil.ul.ie tell devilwood.ece.ul.iearp reply elendil.ul.ie is-at 0:20:af:e1:41:4edevilwood.ece.ul.ie.8888 > elendil.ul.ie.2141: S 25337815:25337815(0) ack 2623134528 win 17424 <mss 1460,nop,nop,cc 2, nop,nop,ccecho 9> (DF)elendil.ul.ie.2141 > devilwood.ece.ul.ie.8888: F 20:20(0) ack 1 win 15928 <nop,nop,cc 9> (DF)devilwood.ece.ul.ie.8888 > elendil.ul.ie.2141: . ack 21 win 17405 <nop,nop,cc 2> (DF)devilwood.ece.ul.ie.8888 > elendil.ul.ie.2141: FP 1:31(30) ack 21 win 17424 <nop,nop,cc 2> (DF)elendil.ul.ie.2141 > devilwood.ece.ul.ie.8888: . ack 32 win 15928 <nop,nop,cc 9> (DF)

3.1.4 Request or Reply Exceeds MSS

If the initial request exceeds the maximum segment size allowed,the request will have to be fragmented.

When the server receives the initial SYN with just the data and no FIN,depending on the time outs, it either responds with a SYNACK immediatelyor waits for the FIN bit to arrive before responding with the SYNACKthat acknowledges all of the data. The server then proceeds to send themulti-packet response if required.

localhost.2123 > localhost.8888: S 2184275328:2184278860(3532) win 14128 <mss 3544,nop,nop,cc 5> (DF)localhost.2123 > localhost.8888: FP 2184278861:2184279329(468) win 14128 <nop,nop,cc 5&gt: (DF)localhost.8888 > localhost.2123: S 1279030185:1279030185(0) ack 2184278861 win 14096 <mss 3544,nop,nop,cc 6,nop,nop,ccecho 5>localhost.2123 > localhost.8888: F 469:469(0) ack 1 win 14128 <nop,nop,cc 5> (DF)localhost.8888 > localhost.2123: . ack 470 win 13627 <nop,nop,cc 6> (DF)localhost.8888 > localhost.2123: FP 1:31(30) ack 470 win 13627 <nop,nop,cc 6> (DF)localhost.2123 > localhost.8888: . ack 32 win 14128 <nop,nop,cc 5> (DF)

3.1.5 Backward Compatibility

Because T/TCP is a superset of TCP, it must be able to communicateseamlessly with other hosts not running T/TCP.

There are a couple of different scenarios in this situation. Someimplementations hold the data in the SYN until the 3-way handshakehas passed. In this situation the client only needs to resend the FINsegment to let the server know that all the data has been sent. Theserver then responds with normal TCP semantics.

In other implementations, the SYN segment is dumped once it has beenprocessed, including the data sent in the initial SYN. The server sendsa SYNACK acknowledging only the SYN sent. The client times out after aperiod and resends the data and FIN. The server then proceeds as normal.

When testing the implementation for backward compatibility, I found anunusual feature (bug?) of Linux. When a SYN is sent with the FIN bit set,the Linux host responds with the SYNACK segment but also with the FINbit turned on. This causes the client to mistakenly believe theserver has sent the reply back to the client.

This problem was traced to the way Linux constructs its SYNACK segment. Itcopies the header of the original SYN (and so all the flags), then setsall the flags except the FIN flag. This results in the Linux host sendinga FIN without knowing it. I pointed this out to the developers of theLinux kernel. Their reasoning was that T/TCP leaves hosts open to a SYNflood attack and as such should not be allowed into main stream protocols.As it turned out, it was only a small check that was needed to solvethis problem.

elendil.ul.ie.2127 > skynet.csn.ul.ie.http: SFP 520369398:520369417(19) win 15928 <mss 1460,nop,nop,ccnew 7> (DF)skynet.csn.ul.ie.http > elendil.ul.ie.2127: SF 2735307581:2735307581(0) ack 520369399 win 32736 <mss 1460>elendil.ul.ie.2127 > skynet.csn.ul.ie.http: F 20:20(0) ack 1 win 15928 (DF)<\n>skynet.csn.ul.ie.http > elendil.ul.ie.2127: . ack 1 win 32736 (DF)elendil.ul.ie.2127 > skynet.csn.ul.ie.http: FP 520369399:520369418(19) win 15928 <mss 1460,nop,nop,ccnew 7> (DF)<\n>skynet.csn.ul.ie.http > elendil.ul.ie.2127: . ack 21 win 32716 (DF)skynet.csn.ul.ie.http > elendil.ul.ie.2127: P 1:242(241) ack 21 win 32736 (DF)skynet.csn.ul.ie.http > elendil.ul.ie.2127: F 242:242(0) ack 21 win 32736elendil.ul.ie.2127 > skynet.csn.ul.ie.http: . ack 243 win 15928 (DF)

3.2 Performance Analysis

To investigate the performance of T/TCP in comparison to the originalTCP/IP, I compiled a number of executables that returned different sizeddata to the client. The two hosts involved were elendil.ul.ie (runningLinux) and devilwood.ece.ul.ie (running FreeBSD 2.2.5). The tests wereperformed for 10 different response sizes to vary the number of segmentsrequired to return the full response. Each request was sent 50 times andthe results averaged. The maximum segment size in each case is 1460 bytes.

The metric measured used for performance evaluation was the averagenumber of segments per transaction. I used Tcpdump to examine the packetsexchanged. Note that Tcpdump is not entirely accurate.During fast packet exchanges, it tends to drop some packets to keepup. This accounts for some discrepancies in the results.

3.2.1 Number of Packets per Transaction

Figure 4. Number of Segments versus Size of Data Transfer

Figure 4 shows the testing results for the number of segmentsfor T/TCP versus number of segments for normal TCP/IP. It is immediatelyobvious that there is a saving of an average five packets. These fivepackets are accounted for in the 3-way handshake and the packetssent to close a connection. Lost packets and retransmissions causediscrepancies in the path of the graph.

When using aTCP client and a T/TCP server, there is still a saving of one segment. Anormal TCP transaction requires nine segments, but because the server wasusing T/TCP, the FIN segment was piggybacked on the final data segment,reducing the number of segments by one. Thus,a reduction in segments results even if just one side is T/TCP aware.

Figure 5. Percentage Savings per Size of Data Transfer

Figure 5 shows the percentage savings for the different packetsizes. The number of packets saved remains fairly constant, but becausethe number of packets being exchanged increases,the overall savings decreases. This indicates T/TCP ismore beneficial to small data exchanges. These test results wereobtained from two hosts on the same intranet. For comparison purposes,the tests were repeated for a host on the Internet; www.elite.net waschosen as the host. Requests were sent to the web server for similarsized data. Figure 6 shows these results. This graph is not as smooth asthe graph seen in Figure 4 due to a higher percentage of packets beinglost and retransmitted.

Figure 6. Number of Segments versus Size of Data Transfer for Internet Host

3.3 Memory Issues

The main memory drain in the implementation is in the routing table. InLinux, for every computer that the host comes into contact with, anentry for the foreign host is made in the routing table. This appliesto a direct connection or along a multi-hop route. This routing tableis accessed through the rtable structure. The implementation of T/TCPadds in two new fields to this structure, CCrecv and CCsent.

The entire size of this structure is 56 bytes. This isn't a majormemory hog on a small stand-alone host. On a busy server though, wherethe host communicates with perhaps thousands of other hosts an hour, it canbe a major strain on memory. Linux has a mechanism where a route that isno longer in use can be removed from memory. A check is run periodicallyto clean out unused routes and those that have been idle for a time.

The problem here is the routing table holds the TAO cache. Thus, any timea route containing the last CC value from a host is deleted, thelocal host has to re-initiate the 3-way handshake with a CCnew segment.

A separate cache can be created to holdthe TAO values, but the route table is the handiest solution.Also, a check can be added when cleaning out the routing entriesfor a CC value other than zero (undefined). Inthis case, the route could either be left for a longer time spanor permanently.

The benefits of leaving the routing entries up permanently are clear. Themost likely use of this option would be a situation where a host only talksto a certain set of foreign hosts and denies access to unknown hosts. Inthis case, it is advantageous to keep a permanent record in memory sothat the 3-way handshake can be bypassed more often.

3.4 Protocol Analysis

The original protocol specification (RFC1644) labeled T/TCP as anexperimental protocol. Since the RFC was published noupdates have been made to the protocol to fix some of the problems.The benefits are obvious compared to the original TCPprotocol, but is it a case of the disadvantages out-weighing the advantages?

One of the more serious problems with T/TCP is that it opensthe host to certain denial-of-service attacks. SYN flooding (seehttp://www.sun.ch/SunService/technology/bulletin/bulletin963.html formore information) is the term given to a form of denial of serviceattack where the attacker continually sends SYN packets to a host. Thehost creates a sock structure for each of the SYNs, thus reducingthe number of sock structures that can be made available to legitimateusers. This can eventually result in the host crashing if enough memoryis used up. SYN cookies were implemented in the Linux kernel to combatthis attack. It involves sending a cookie to the sender to verifythe connection is valid. SYN cookies cause problems with T/TCP asno TCP options are sent in the cookie and any data arriving in theinitial SYN can't be used immediately. The CC option in T/TCP doesprovide some protection on its own, but it is not secure enough.

Another serious problem was discovered during research was thatattackers can by-pass rlogin authentication. An attacker createsa packet with a false IP address in it, one that is known to thedestination host. When the packet is sent, the CC options allowthe packet to be accepted immediately, and the data passed on. Thedestination host then sends a SYNACK to the original IP address. Whenthis SYNACK arrives, the original host sends a reset, as it is not ina SYN-SENT state. This happens too late, as the command will alreadyhave been executed on the destination host. Any protocol that usesan IP address as authentication is open to this sort of attack. (Seehttp://geek-girl.com/bugtraq/1998_2/0020.html.) There are methods ofavoiding this security hole.

Kerberos is a third-party authenticationprotocol but requires the presence of a certification authority andan increase in the number of packets transferred. The IP layer hassecurity and authentication built into it. With the new IP version beingstandardized, IPv6, the authentication of IP packets will be possiblewithout third-party intervention. This is accomplished through the useof an authentication header that provides integrity and authenticationwithout confidentiality.

RFC1644 also has a duplicate transaction problem. This can be seriousfor non-idempotent applications (repeat transactions arevery undesirable). Requesting time from a timeserver can be consideredidempotent because there is no adverse effect results on either the client or theserver if the transaction is repeated. In the case of a banking systemhowever, if an account transaction were repeated accidentally, the ownerwould either gain or lose twice as much as anticipated. This error canoccur in T/TCP if a request is sent to a server and the server processesthe transaction, but before it sends back an acknowledgment the processcrashes. The client side times out and retransmits the request, if theserver process recovers in time, it can repeat the same transaction. Thisproblem occurs because the data in a SYN can be immediately passedonto the process, rather then in TCP where the 3-way handshake has tobe completed before data can be used. The use of two-phase commits andtransaction logging can keep this problem from occurring.

3.5 Summary

This chapter illustrates the required functionality of T/TCP forLinux. It also displays the advantages in speed and efficiency T/TCPhas over normal TCP.

T/TCP admittedly has some serious problems, but these problems are notrelevant to all situations. Where hosts have some form of protection(other than pure T/TCP semantics) and basic security precautions are taken,T/TCP can be used without any worries.

4. Case Study: T/TCP Performance over Suggested HTTP Improvements

With the World Wide Web being the prime example of a client-server transactionprocessing nowadays, this section will focus on the benefits of T/TCPto the performance of the Web.

Currently, the HTTP protocol sits in the application layer of theTCP/IP reference model. It uses the TCP protocol to carry out all itsoperations, UDP being too unreliable. There is a lot of latency involvedin the transfer of information, the 3-way handshake and the explicitshutdown exchanges being the examples. Using the criteria specified insection 2.1 it is apparent that the World Wide Web's operation isone of transactions.

4.1 Web Document Characteristics

In a survey of 2.6 million web documents searched by the Inktomi webcrawler search engine (see: http://inktomi.berkeley.edu) it was foundthat the mean document size on the world wide web was 4.4KB, the mediansize was 2.0KB and the maximum size that was encountered was 1.6MB.

Referring to figure 3.2 it can be seen that the lower the segment size,the better the performance of T/TCP over normal TCP/IP. With a meandocument size of 4.4KB, this results in an average saving of just over55% in the number of packets. When taking the median size into account,there is a saving of approximately 60%.

Time-wise there will be an improvement in speed, depending of course onthe reliability of the network.

4.2 Suggested Performance Improvements for HTTP

There have been a number of suggestions put forward to improve theoperation of HTTP and reduce the time and bandwidth required downloadinginformation. Most of these suggestions have as their basis compressionand/or delta encoding.

4.2.1 Compression

At the moment, all web pages are transferred in plaintext form, requiringlittle work from either the server side or the client side to displaythe pages.

In order to introduce compression into the HTTP protocol, a number ofissues would have to be resolved.

First and foremost would be the issue of backward compatibility, with theweb having reached so far across the world, switching to compression wouldtake a long time. Browsers need to be programmed to handle compressedweb pages and web servers also need to be configured to compress theinformation requested before sending it onto the user. It would be astraightforward task for the IETF (Internet Engineering Task Force) tointroduce a compression standard. It would then be up to the vendorsand application writers to modify the browsers and servers for thenew standard.

Another issue would be the load placed on the server when it is requestedto compress the information. Many busy servers would not have the powerto handle the extra workload. This holds to a lesser extent on the clientside, with a minimal overhead involved in decompressing a few pages ata time.

In their paper ôNetwork Performance Effects of HTTP/1.1, CSSI andPNGö, the authors investigated the effect of introducing compressionto the HTTP protocol. They found that the compression resulted in a 64%saving in the speed of downloading with a 68% decrease in the number ofpackets required. Over normal TCP/IP, this brings the packet exchangesand size of data down to the level where T/TCP becomes beneficial. Thusa strategy involving both compression and T/TCP can result in enormoussavings in time and bandwidth.

4.2.2 Delta Encoding

In this situation, a delta refers to the difference between twofiles. On UNIX systems, the diff command can be used to generatethe delta between two files. Using the changed file, and the delta,the original file can be regenerated again, and vice-versa.

For delta encoding on the web, the client initially requests a documentand the complete document is downloaded. This will result in about a55% benefit if using T/TCP and taking into account the mean size ofa document. Once the client has the page, it can be cached and storedindeterminately. When the client requests the document the next time,the browser will already have the original document cached. Using deltaencoding, the browser would present the web server with the last datethe cached document was modified. The server determines if the documenthas been updated since the cached copy was stored, and if so, a delta ofthe server side document is created. The delta, rather than the originaldocument are transferred.

Of course, there are quite a few difficulties that need to be considered.

1. The client needs to retain a cached copy of the document. This is notso much a hassle with more modern browsers, as this is already done. Infact the HTTP protocol defines a command that can be used to request thelast modified date from a document on a server. This is then compared tothe cached document and a decision made whether to download the new file,or display the original.
2. From the server side, multiple versions of the document have to becached to allow the server to create deltas. A decision has to be madeof how many changed versions are allowed. Should the older versions bekept in the user side, or should a separate database of old versions bekept? A more detailed study of the impact of caching documents can befound in Braun & Claffy's book (see Resources).
3. In the case where there have been a number of updates to the serverside document since the client side was cached, it should be decided howmany updates are allowed before the new document is sent, as opposed tosending a delta. The more changes applied to a document, the larger adelta is, hence, a loss in the savings by using delta encoding.
4. Again there is the question of the load placed on the serverby generating a delta for each document requested, similar to thecompression method.

If this method was used with T/TCP, there could be as much as a further66% saving in packets transferred. This is a total of 94% reduction inpacket transfer.

It should be noted however that this is a best case scenario. In thissituation, the document will already have been cached on both the serverand the client side, and the client and server will previously havecompleted the 3-way handshake in order to facilitate the TAO tests.

4.2.3 Persistent HTTP

RFC2068 describes a modification to HTTP that maintains a continuousconnection to an HTTP server for multiple requests, P-HTTP. Thisremoves the inefficiency of continually reconnecting to a web serverto download multiple images from the same page. The constant connectionand reconnection results in a lot of unnecessary overhead.

Some advantages over the original HTTP protocol are:

1. Opening and closing fewer TCP connections save CPU time and memory.
2. Multiple HTTP requests and responses can be sent without waiting fora response that would otherwise be necessary when opening and closingmultiple connections.
3. Network congestion is reduced since there are fewer packets.

4.3 Summary

Using the results obtained in section 3 and the characteristics ofdocuments available on the World Wide Web, a study is presented on howT/TCP can benefit, or otherwise, some of the suggestions for improvingthe HTTP protocol.

The main case for the introduction of compression and delta encoding isthe reduction in the size of the data that needs to be transferred. Theresults obtained from the performance analysis of T/TCP suggest thata greater benefit be obtained on small data transfers. The compressionand delta encoding ideas result in data small enough that can be sentin one packet. Under these conditions, T/TCP operates best.

P-HTTP puts forward the idea that a connection should be semi-permanent,unlike the current open-close operation HTTP currently employs. In thisscenario, T/TCP will not work at all because of its transaction-orientedstyle.

5. 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 wouldbe 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

• socket(): create a socket
• sendto(): connect, send data, and close connection

Programming under T/TCP is much like programming under UDP.

6. Conclusion

T/TCP was originally designed to address the need for a more efficientprotocol for transaction style applications. The original protocolsdefined in the TCP/IP reference model were either too verbose or notreliable enough.

T/TCP works by building on the TCP protocol and introducing a number ofnew options that allow the 3-way handshake to be bypassed in certainsituations. When this occurs, the transaction can almost realize theminimum number of segments that are required for a data transfer. T/TCPcan reduce the average number of segments involved in a transaction from 9(TCP) to 3 using the TAO test. This has potential benefits to overloadednetworks where there is a need to introduce a more efficient protocol.

Analysis of T/TCP shows that it benefits small transaction-orientedtransfers more than large-scale information transfer. Aspects oftransactions can be seen in such cases as the World Wide Web, RemoteProcedure Calls and DNS. These applications can benefit from the use ofT/TCP in efficiency and speed. T/TCP reduces on average both the numbersof segments involved in a transaction and the time taken.

As T/TCP is still an experimental protocol, there are problemsthat need to be addressed. Security problems encountered includethe vulnerability to SYN flood attacks and rlogin authenticationbypassing. Operational problems include the possibility of duplicatetransactions occurring. Problems that occur less frequently would be thewrapping of the CC values on high-speed connections and thus opening upa destination host to accepting segments on the wrong connection.

Many people recognize the need for a protocol that favors transactionstyle processing and are willing to accept T/TCP as the answer. Thesecurity considerations lead to the conclusion that T/TCP would bemore useful in a controlled environment, one where there is littledanger from a would-be attacker who can exploit the weaknesses of thestandard. Examples of enclosed environments would be company Intranetsand networks protected by firewalls. With a lot of companies seeingthe web as the future of doing business, internal and external, asystem employing T/TCP and some of the improvements to HTTP, such ascompression and delta encoding, would result in a dramatic improvementin speed within a company Intranet.

Where programmers are willing to accept T/TCP as a solution totheir applications, there are only minor modifications needed forthe application to become T/TCP aware. For client side programming,it involves the elimination of the connect() and shutdown() functioncalls, which can be replaced by adding the MSG_EOF flag to the sendto()command. Server side modifications involve simply adding the MSG_EOFflag to the send() function.

In conclusion, researches into T/TCP suggest that it is a protocol thatis nearly, but not quite, ready to take over transaction processing forgeneral usage. For T/TCP alone, more work needs to be done to develop itfurther and solve the security and operational problems. Security problemscan be solved using other authentication protocols such as Kerberos andthe authentication facilities of IPv6. Operational problems can be dealtwith using greater transaction reliability built into the applicationsthat will use T/TCP, such as two phase commits and transaction logs.

Future work in this area could involve the promotion of T/TCP as analternative to the TCP and UDP protocols for certain applications. T/TCPhas been slow to take off. FreeBSD is the most widespread implementationof T/TCP for PC computers. Now that Linux is T/TCP aware, it can pushthe use of the protocol more. Applications can be easily modified touse T/TCP when available, any applications that involve an open-closeconnection can use T/TCP efficiently, and the more prominent exampleswould be web browsers, web servers and DNS client-server applications. Toa smaller extent, applications such as time, finger and whois daemons canbenefit from T/TCP as well. There are many networking utilities availablethat can take advantage of the efficiency of the protocol, all that isneeded is the incentive to do it. Perhaps a more immediate task though,is to port the T/TCP code to the new Linux kernel series, 2.1.x.

Resources

Braun H W, Claffy K C, "Web Traffic Characterization: An Assessment of theImpact of Caching Documents from NCSA's Web Server", Proceedingsof the Second World Wide Web Conference '94: Mosaic and the Web,October 1994

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

Prud'Hommeaux E, Lie H W, Lilley C, "Network Performance Effectsof 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