Transmission Control Protocol

The fundamental Internet end-to-end protocol for implementing reliable delivery is the Transmission Control Protocol (TCP). Yes, it is the "TCP" in "TCP/IP"; its role is that fundamental.

When the Internet was first designed, one of its basic axioms was the end-to-end assumption. Under this assumption, the transfer of information between Internet endpoints is the responsibility of the endpoints. As opposed to other network architectures such as X.25, the Internet did not guarantee reliable delivery. Not all Internet applications need guaranteed delivery.

At a general level, assume that TCP guarantees a stream of error-free bytes. If TCP is unable to correct errors by repeated retransmission, it shuts down the connection. TCP does not guarantee the rate, or the variability of rate, of delivery; see differentiated services.

TCP assumes that any loss is due to congestion, so it strives not to transmit more data than the network and destination can accept. This is done with flow control mechanisms, which also control retransmission of data lost in transmission.

Windowing

There are both implicit and explicit flow control mechanisms. In the conventional slow start mode, TCP starts with a window size of one byte. As long as the transmission stays up, and delay does not exceed certain parameters, TCP keeps doubling the window size until either reaches the 64K limit imposed by its 16-bit window size field, or a transmission is not acknowledged.

If there is no acknowledgement, TCP assumes that is due to congestion, although TCP really does not know if the problem is congestion or a transmission error. In either case, TCP sets the window back to 1 and starts increasing the window until it hits a limit. Individual TCP implementations may, for local reasons, limit the maximum window size, but this is nor part of the standard.

There are methods of WAN acceleration or TCP acceleration that may, in properly selected circumstances, improve performance, by initially using a large window wise. For some environments, this may be effective, but it may break other ones; see TCP acceleration.

TCP over paths with specific performance characteristics

TCP was intended to be independent of the underlying transmission system, as is the Internet Protocol (IP). Indeed, IP's independence of the underlying medium has been demonstrated in some extreme cases

Nevertheless, experience demonstrated that the original TCP design limited transfer rates over high-speed, long-delay paths, such as relays through geosynchronous communications satellites. Such channels have been called "Long Fat Networks", pronounced "elephant".

The concern is with the product of bandwidth and latency (i.e., delay in RFC1323). If its value becomes too large, the original sizes of the TCP window size and sequence numbers are too small; transmission has to stop until enough data is acknowledged to reuse those fields. Extensions in RFC1323 allow the window size to scale, and add timestamps to disambiguate sequence numbers.

Another problem is that traditional TCP, when retransmitting, will send all packets that were not acknowledged at when the error was detected. With high data rates, large packets, and low error rates, this can result in throughput reduction while the packets are retransmitted, and analyzed and acknowledged by the receiver. By using a feature called selective acknowledgement, only the actually errored packets need be retransmitted.