▶ 12.1“Smart” Versus “Dumb” Networks
When engineers try to design and build more sophisticated systems, they divide the system into components and place different functions in different components. These decisions have far-reaching effects. The telephone system took one approach, and the designers of today’s internet protocols took a different approach.
The traditional analog telephone was a fairly simple device that did very little on its own. The telephone network accepted a dialed phone number, routed and established a connection to the called phone, and managed the conversation. The telephone system was a classic example of a “smart” network with “dumb” endpoints.
The Ethernet is a “dumb” network. It doesn’t tell hosts how to take turns on the network. It doesn’t check CRCs on packets. Network switches distinguish packets destined for different hosts on the network, but that is all they do. Hubs do even less work.
The original Ethernet had no circuitry of its own; it was simply a coaxial cable that carried signals between interfaces. Today’s low-cost hubs and switches are only slightly more sophisticated than that. The lion’s share of work is performed by “smart” endpoints: the hosts on the Ethernet.
When first introduced in the 1970s, the Ethernet was greeted with a great deal of skepticism. Some doubted that the collision detection strategy would work well as networks grew larger. Others doubted that the “dumb network” concept made sense.
The “dumb network” concept arose in part from the attempt in the late 1960s to make the ARPANET a “smart” network. The ARPANET was a mesh network of nodes, and the hosts connected to the nodes. The nodes were small computers that tried to provide a reliable packet delivery service. If the network accepted a message, the network would either deliver it reliably or send an error message indicating the failure. It should never lose a message without indication or deliver a duplicated message.
In practice, the ARPANET was never 100 percent reliable. Because of inevitable timing uncertainties with computer hardware, the host couldn’t be 100 percent sure that the network accepted a message. An error message likewise did not 100 percent guarantee that a message had not been delivered.
These shortcomings, though rare, occurred often enough to require special handling in the host’s protocol stack. The network could not provide high reliability by itself. Reliability depended on retransmission procedures performed by the endpoint hosts themselves.
The End-to-End Principle
The failure of network-based reliable transport influenced a central design principle of internet-oriented networks: the end-to-end principle. The concept embodies the notion of dumb networks by placing most network protocols in the connection’s endpoint hosts. The network itself simply transmits packets and possibly loses a few on occasion.
The basic concept was proposed in a 1981 paper by Saltzer, Reed, and Clark titled “End-to-End Arguments in System Design.” They argued that few mechanisms belonged in the networks themselves, unless justified as performance enhancements. Most mechanisms were more efficiently provided in the endpoint hosts. This approach already was being applied to network applications; all of them consist of services located on endpoint hosts, as discussed in Section 10.6.
Although this philosophy can be taken to extremes, internet designers apply it pragmatically. The internet remained a network of more-or-less autonomous routers until traffic grew sharply in the mid-1990s. Then backbone operators reorganized the structure to be “smarter” in order to make routing efficient and reliable.
Although end-to-end retransmissions may work in theory, timeout periods for lost internet packets are irritatingly long in practice. Lost packets often become visible to users. They become a significant problem if losses occur too often. This is one reason why wireless LANs include a retransmission feature even though TCP also performs retransmissions.