On Network Design and Town Planning

Reading "End-to-end Arguments in System Design" [1] and "The Design Philosophy of the DARPA Internet Protocols" [2] was quite an enlightening experience for this author.

"End-to-end..." argued that "...functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level." After reading the several examples cited, one tends to agree with the paper, especially when it goes on at length about "careful file transfer." Implementing important network functions at low levels add overhead that is easily avoided because of the availability of these functions at higher levels.

"The Design..." "...attempts to capture some of the early reasoning which shaped the Internet protocols," as it states early on, and capture this reasoning it does. One feels as though he is part of history as the paper explains how the Internet came to be designed the way it is; why the datagram, for reasons of survivability and "fate sharing," became a core feature of its architecture; and why TCP and IP, originally one protocol, were split and respectively assigned to handle reliable end-to-end transfer and routing.

These papers remind the author of the days when he used to draw city layouts using Paintbrush in Windows 3.1 (don't laugh; he was young and had a lot of free time). Imagining himself to be the town planner of some distant place devoid of civilization, he would place roads with the line tool, color city blocks with the bucket tool, and occasionally indicate places of interest with the rectangle tool, eventually ending up with his ideal city (at least for that day) from scratch.

Network protocol designers, this author thinks, may feel something similar to his experience with town planning. Given computer systems completely devoid of networking, protocol designers set out to identify the layers needed by the system, design the packets that will bring data to and from these layers, and eventually come up with their ideal design--or at least, ideal in how closely it achieves its goals.

However, just like how this author sometimes wishes to rebuild his cities because of flaws in his design, network protocols may need revising because of flaws in their design. As stated in "End-to-end...," reinforcing the lower layers of a system to attempt to achieve the design's goals may actually counteract it, with the overhead of low-level robustness getting in the way of high-level efficiency. He is a lucky man who gets to design an entire network from the lowest layers up to the end applications; most designers have to build their designs around existing protocols--and their existing flaws.

The designers of the Internet were very lucky men indeed.

During their time, the large networks that already existed were not interconnected with each other, which meant that they got to design their protocols from scratch. Their goals allowed them to design protocols that provided just enough robustness for applications to function well and not get bogged down by irrelevant network traffic. This "good enough" architecture is indeed good enough that it persists today, more than twenty years later.

Sometimes, this author wonders what these initial designers felt as they laid out the foundations of the Internet. Though his forays into town planning are over, work continues on the Internet today, as designers continue to create new protocols for new applications and revise old ones to support this new work. Designing "good enough" protocols does not take more than a few years, but once implemented, they last--forever.

Reference:
[1] J.H. Saltzer et al., "End-to-End Arguments in System Design," ACM Transactions in Computer Systems, vol. 2, no. 4, pp. 277-288, November 1984.
[2] David D. Clark, "The Design Philosophy of the DARPA Internet Protocols," ACM SIGCOMM Computer Communication Review, vol. 18, issue 4, August 1988.