Evaluation of TCP for http/Web Transmissions

Evaluation of TCP as an End-to-End Protocol for http/Web Transmissions

By Adam Fields

This report evaluates TCP (Transmission Control Protocol) [RFC-793] in terms of an environment that consists only of HTTP (HyperText Transfer Protocol)/Web transactions. Web transactions (as they will heretofore be referred to) follow a client/server model, and usually involve a short client request and a longer server response.

When using HTTP, the majority of transmissions occur in short bursts of large bandwidth. A page is downloaded, via several connections, then the connection is dormant for a while. Since it would be silly to keep the connection open on the off chance that the user wants to retrieve more information from the same server, transmissions consist of a continual cycle of making a connection, transmitting a relatively small amount of information, and breaking the connection. Although the web is usable for real-time transmission of data, using extensions such as RealAudio, these extensions often utilize their own transport mechanisms, and real-time applications are swiftly shifting to client-based systems, such as Sun's Java. Therefore, the primary uses of HTTP can be considered to follow this "burst" pattern, and optimized for that.

Two major enhancements to TCP have surfaced to deal with this problem - TCP-KeepAlive [UNKNOWN], and T/TCP (TCP for Transactions) [RFC-1644]. Normally, when an HTTP connection is made, the transmission of the page from the server to client occurs along many different TCP connections (one per file on the page). The overhead that is associated with making and breaking all of these connections is enormous compared to the small amount of data being transmitted. TCP-KeepAlive gets around this problem by using one connection that is kept open until all parts of the page have been transmitted. This is, in my opinion, not a good solution. While it does reduce the total overhead of connection establishment and destruction, it does not take into account future connections, and there is a definite advantage to being able to open multiple connections at once. T/TCP is a better solution. By eliminating the 3-way handshake at connection establishment and reducing the time needed to fully break a connection, T/TCP works by reducing the overhead on each connection instead of the total number of connections.

Another solution, but one which does not provide backward compatibility with TCP, is VMTP (Versatile Message Transaction Protocol) [RFC-1045]. VMTP overcomes all of the perceived problems with TCP as a transaction-based transport protocol, providing additional services such as security, better naming, statelessness of transactions, and options for real-time data transfer. Although designed for use with RPC, VMTP applies well to web transactions, with a few very important caveats discussed in the "Overall Performance" section of this document.

Segmentation of Octet Stream

HTTP transmissions consist of files or request messages, not arbitrary byte streams. Ideally, each section of the request/response interaction would fit into one TCP segment, but this is not a realistic requirement, as file sizes for the response section can be arbitrarily large. T/TCP does not address this issue, but does show awareness of header overhead in relation to data size. VMTP takes the issue into account by formatting each connection as a request/response transmission and allowing packet groups which are dealt with as a unit. VMTP has the advantage of having been built from the ground up to assume that message transactions will follow the request/response pattern, while T/TCP is merely a set of enhancements to TCP, which was originally designed for long-term connection transactions.

Handling of Loss, Duplication & Reordering of Segments

Web transmissions do not need to be real-time. Consequently, reliability is more important than Quality of Service (QoS). TCP's sliding window mechanism is adequate for ensuring retransmission of lost segments, discarding of duplicates, and reordering of out-of-order segments in web transmissions. The main issue we are presented with when optimizing TCP for Web transactions lies in the overhead generated by opening multiple connections. Although TCP does provide adequate handling of these situations under normal circumstances, when enhancements are performed to optimize for the Web, additional care must be taken to distinguish between transaction connections.

T/TCP specifies a 32-bit connection number which is cached (the loss of cache leads only to fall-back to "regular" TCP and re-establishment of the cache). With this connection number, which increases monotonically globally at the client side, the server can distinguish among multiple connections in time from the same client. The primary effect of this connection number is to allow "graceless exit" from a connection, but it has the side-effect of preventing an out-dated segment from influencing a current connection.

VMTP seems to contain adequate safeguards against lost, duplicate, or reordered packets, but focuses more on the fact that transaction-based transmissions can be (and usually are, in a web environment) idempotent, so recognition of loss is more important than recovery. VMTP's selective retransmission policy is significantly more elegant than TCP's sliding window, but requires that the client do a little more work to determine what it actually needs/wants.

Timing Transmissions & Window Adaptation Mechanisms

TCP depends heavily on RTT timing to determine its flow control. In order to determine whether a segment needs to be retransmitted, the sender must calculate an expected Round-Trip Time, during which it should receive an acknowledgement. As its RFC notes, when using T/TCP, the elimination of the 3-way handshake complicates the calculation of the RTT. This is compensated for by caching RTT estimates across transactions, but this is a kludge at best. As the RFC states, "Further study in this issue is needed." VMTP utilizes several timers on the client and server sides to regulate transmissions, but does not seem to be a significant improvement over TCP. In Web transactions, flow control is not a comparatively large issue because individual transactions are small. Optimizations to flow control may become much more important in the future, as networks become more congested, but this is a larger issue not directly related to web transactions.

Support of Security Features

Ideally, security features should be incorporated into the lower levels of the protocol stack, preferably IP. The transport layer is responsible for throughput issues and recipient identification on the receiving machine (ports), not identity verification. If TCP (or any transport protocol, for that matter) is run over an encrypted IP layer, most security issues disappear. Several RFC's exist dealing with this issue [RFC-1852, RFC-1828].
VMTP contains provisions for encrypted packets (with checksum), but this is, in my opinion, simply unnecessary in a transport protocol. If the entire IP datagram is protected by encryption, any security features in the transport protocol become superfluous, except for protecting against assaults once the packet has been received at the host. Since an attack of this nature will often be performed by someone with root access who can do far worse things than look at and/or forge packets, it does not seem worth the extra trouble, overhead, and effort to put encryption into the transport protocol. T/TCP does not add any security features over TCP.

Overall Performance

TCP's main performance hit, as related to Web transactions, seems to be in the extreme overhead required for connection establishment and termination. In a situation where connections are long-lived and bi-directional, this overhead is small compared to the amount of data transmitted across the established connection. In a web environment, this overhead becomes much more significant, because connections are short-lived (used for only one file transfer), are uni-directional, and involve a small amount of data. T/TCP seems to be the best solution, because it directly addresses these problems while maintaining backward compatibility with TCP. In a world-wide network that can no longer handle a "Flag Day", backward compatibility is essential, at least until the majority has switched over. VMTP provides many enhancements over TCP for transaction-based transmissions, but it is perhaps better suited to "self-contained" transaction systems such as RPC, in which the server and client are probably maintained by the same organizational entity, rather than "open" systems such as the Web, where any arbitrary client can access any server. VMTP, while "less" than TCP in terms of connection overhead, takes on more responsibilities than it should. It provides security and naming features that are not in the domain of the transport protocol, and that should be dealt with at other levels of the protocol stack (either application or IP). Conversion to T/TCP (or something similar), would require almost no effort, increase performance dramatically, and still allow everyone who uses to to communicate with those who don't at the present level of performance.

Bibliography

TCP/IP Illustrated, Vol. 1
W. Richard Stevens, Addison-Wesley, 1994

TCP/IP Illustrated, Vol. 3
W. Richard Stevens, Addison-Wesley, 1996

Internetworking with TCP/IP, Vol. 1, 3rd Edition
Douglas E. Comer, Prentice Hall, 1995

Computer Networks, 2nd Edition
Andrew S. Tannenbaum, Prentice Hall, 1988

RFC-739 - Transmission Control Protocol
University of Souther California, Sept. 1981

RFC-1045 - Versatile Message Transaction Protocol
David Cheriton, Feb. 1988

RFC-1644 - T/TCP
R. Braden, Jul. 1994

RFC-1828 - IP Authentication using Keyed MD5
P. Metzger, W. Simpson, Aug.1995

RFC-1852 - IP Authentication using Keyed SHA
P. Metzger, W. Simpson, Sept. 1995