Name: Daniel Meredith
Course: CS125 Computer Networks
Commentary Due Date: 02/01/00
Submit Date: 02/29/00
Journal Ref: RFC1323


As suggested by the abstract's web page, I chose to read an RFC on the improvements that need to be made to the TCP protocol in order to make it more reliable and less error prone on high bandwidth networks. The introduction of fiber optics as a readily available medium of transmission has increased the overall bandwidth of the Internet to the point that the TCP protocol is reaching the point where it can no longer scale to handle the transfer rates.

The performance of TCP doesn't really depend on the transfer rate, but instead on the time it take for the message to transmit from point to point. The delay in the transmission of a message means that there is a certain amount of data still in the pipe after the transmission has stopped. This "bandwidth * delay" product is the main reason that TCP is now having difficulties scaling to the faster speeds available on the Internet. TCP has real issues when the "bandwidth * delay" product is very large.

These issue stem from the fact that the TCP protocol was built to only allow a maximum window ( this refers to the sliding window algorithm that is used to re-assemble the packets as they arrive out of order ) size of 65K, or 2^16. The small size of the window limits the amount of data that can be in the pipe at one time. The usable bandwidth is then limited to 2^16 / RTT. The new extensions to TCP that are defined in this document specify that a "window scaling factor" may now be added to the senders header in order to allow for larger window sizes on the receiver. This larger window size may only be used if both of the implementations involved in the transmission have the new extension enabled.

The second major issue in the current TCP implementation is that the recovery of loss packet data in a transmission can be arduous. Until recently the TCP definition called for the complete emptying of the pipe if any packets were lost. This was done to insure that the lost packet could be transmitted and received as soon as possible. As the size of the pipe has grown, the amount of data stuffed into it has also increased. This leads to a higher probability of packet loss over time.

The last major issue with the current TCP implementation on large bandwidth networks is the accurate calculation of Round Trip Transmission Times, or RTT's. One of the extensions to TCP that is proposed in this RFC is meant to deal with this issue directly. The concept of time stamps is introduced, which allow for timing of each segment of transmission at minimal computational costs. The issue of time stamps has come up before, and one of the largest problems with it to consider is the situation of multiple time stamp receipt by a server without ACK signals from the client. The dilemma then becomes which time stamp to keep and trust as the judgment on whether or not to timeout on a transmission. The basic rule is that the last time stamps received have a better picture of the recent and current state of the network, and therefore should have more bias than earlier time stamps in the calculation of the RTT.

The largest problem as I see it though is the issue of packet mis-assemble due to integer wrapping. In a 32 bit system the largest number possible is a little over 4 billion, but given the ability of today's systems to send huge numbers of packets in a short amount of time ( see the DDoS attacks of the past few weeks ) and the fact that their is the available bandwidth on the intern et to actually get the packets to a host in a reasonable amount of time, the possibility of wrapping the packet order numbers does become a possibility. If the number were to wrap, then as the packets continued to arrive they would be inserted in the front of the window, causing data corruption that is not detected in the current TCP system.

All in all, the extensions to TCP are helping to fix a very robust protocol, but the fact still remains that TCP is nearly 30 years old (2000 - 1970) and is in need of not only a re-write, but most likely a re-design. A blank paper re-design of TCP and a few of the other key intern et protocols will help them better allow for the current set of network externalities.