Rewriting the History of TCP
A recent statement made in a Cable TV trade publication, from a bandwidth optimization vendor says this about the internet Transmission Control Protocol (TCP):
TCP was designed for Local Area Network (LAN) data transport, not the Wide Area Networks (WANs) used by service providers, and it can consume from 60 to 80 percent of the available bandwidth because of the overhead built into the protocol
This is unfair to the TCP designers, and the history of the internet in general, so let's look at the TCP definition (RFC761) from 1980 to see what it has to say about this. First, in section 1.1 (Motivation):Very few assumptions are made as to the reliability of the communication protocols below the TCP layer. TCP assumes it can obtain a simple, potentially unreliable datagram service from the lower level protocols. In principle, the TCP should be able to operate above a wide spectrum of communication systems ranging from hard-wired connections to packet-switched or circuit-switched networks.
No LAN bias in those words. Then, from section 2.1, where it discusses the underlying network:It is assumed here that the networks may be either local networks (e.g., the ETHERNET) or large networks (e.g., the ARPANET), but in any case are based on packet switching technology.
(ARPANET was a wide area network built mostly of leased lines, many of which were running at 56 Kbps). Again, no explicit design centered on LANs.
I think most would agree that TCP's flexible accommodation of a variety of underlying network types, ranging from slow packet radio networks to 10G ethernet is the reason it is still today's transport of choice. Hopefully, the history of TCP's elegant design and tradeoffs will not be lost to a marketing message.
Note that the internet community also recognized the TCP overhead problem for low-speed networks, and came out with a standard method of compressing TCP headers to a few bytes, in 1990.
Posted at 10:38AM Oct 20, 2008 by Peter Schow in Industry |