Transmission Control Protocol

The fundamental Internet end-to-end protocol for implementing reliable delivery that accounts for packet loss is the Transmission Control Protocol (TCP).

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, and can be somewhat "lossy." Video on demand over the Internet for example can afford to let packets be lost en route to gain a speed advantage.

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 the 16-bit window size field in TCP (without high performance enhancements), 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 size. For some environments, this may be effective, but it may break other ones; see TCP acceleration.

A good application for a large starting window is on a router-to-router link, when it is known that the first protocol that comes up will be Border Gateway Protocol, and the other router is transferring a full routing table. Until the routing table is transferred and the internal forwarding plane table converges, no other traffic will be competing with BGP. After routing converges, then normal dynamic window adjustment makes sense for regular flow; the implementation might restrict the large initial window to BGP at startup.

TCP over paths with specific performance characteristics

TCP was intended to be independent of the underlying transmission system, as is the Internet Protocol (IP).

Demonstrated independence of transmission medium

Indeed, IP's independence of the underlying medium has been demonstrated in some extreme cases

When consistency is more important than maximum throughput

In certain applications, such as voice or video over the Internet, a consistent delay value is more important to the user experience than occasionally bursting for maximum throughput. This can be done with the TCP Friendly Rate Control (TFRC) document simply specifies a congestion control mechanism. TFRC is not a new protocol, but a TCP implementation technique that would be appropriate for systems using mechanisms such as the Real Time Transport Protocol , applications that manage congestion at the application level, or in the endpoint-wide congestion control features of endpoints with a common congestion control policy.

High performance extensions

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.

Header compression

When there is very little change between TCP segments carrying a particular application protocol, such as telnet sending one character at a time and thus always incrementing counters by one, the header can be compressed. Header compression requires more processing, but can save significant bandwidth on slow links. Telnet gives the most dramatic results, but header compression can also be helpful for FTP and other protocols with an inherent order in their payloads.