Transmission Control Protocol
The fundamental Internet end-to-end protocol for implementing reliable delivery is the Transmission Control Protocol (TCP).[1] 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.
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[2] [3] [4]
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". [5]
The concern is with the product of bandwidth and delay. 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.[6]
References
- ↑ Postel, J. (September 1981), Transmission Control Protocol, Internet Engineering Task Force, RFC0793
- ↑ Waitzman, D. (April 1 1990), Standard for the transmission of IP datagrams on avian carriers, Internet Engineering Task Force, RFC1149
- ↑ Waitzman, D. (April 1 1999), IP over Avian Carriers with Quality of Service, Internet Engineering Task Force, RFC2549
- ↑ Bergen Linux Users Group (April 28 2001, 12:00), The highly unofficial CPIP WG
- ↑ Jacobson, V.; R. Braden & D Borman (May 1992), TCP Extensions for High Performance, Internet Engineering Task Force, RFC1323
- ↑ Mathis, M.; J. Mahdavi & S. Floyd et al. (October 1996), TCP Selective Acknowledgment Options, Internet Engineering Task Force, RFC2018