From: Lillie Kittredge (kittredl@u.washington.edu)
Date: Sun Oct 03 2004 - 22:06:52 PDT
"The Design Philosophy of the DARPA Internet Protocols"
David Clark
This paper describes the motivations and reasoning behind the development
of TCP/IP, with commentary on DARPA's success at reaching those goals.
The most interesting insight from my point of view was the observation
that, as a military organization, DARPA was more concerned that the
Internet fail gracefully (continue to mostly function even when part of it
is down) than that it have good resource accounting. I hadn't considered
before that if it had been designed by a commercial body, those priorities
would have been switched.
DARPA's foresight in allowing for multiple kinds of networks and services
is well-appreciated in light of the assortment of other services and kinds
of networks that have been developing - VoIP, WiFi, p2p etc. The
simplicity of the datagram layer of the protocol stack is essential to
this flexibility, and it is interesting to see that it took some time
before they realized this - if TCP/IP had remained at the same layer, such
flexibility would be nigh on impossible.
The author points out that the goals lowest on the prioritized list could
still use some work -- "some of the most significant problems with the
Internet today relate to a lack of sufficient tools for distributed
management". In the talk of distributed management, and the fact that not
all of the 'gateways' are managed by the same company, I'm reminded of the
most amusingly mind-blowing factoid from my undergrad networking class: if
you set up your own wad o' DNS servers and got enough people to listen to
them instead of the real ones, you could completely change the face of the
Internet. This idea is echoed in the paper's concerns for the fact that
host-resident mechanisms mean that hosts can damage the internet if they
misbehave.
The paper concludes that "there may be a better building block than the
datagram for the next generation of architecture." However, this assumes
that there will _be_ a next generation of the architecture. Though
otherwise insightful, I feel that the author in this respect fails to
appreciate the stunning inertia of human civilization - it ain't broke
enough, so the probability of fixin' it is incredibly low. The
assumption that someone will improve the system later can be a dangerous
one: witness the results of the assumption "I bet someone will fix this
date system before 2000".
This is relevant today in that understanding TCP/IP is fundamental to
understanding the Internet. Moreover, I found it interesting to gain
historical perspective on the development of the protocols -- it serves as
an interesting reminder that we must still take these issues into account
when designing new protocols, and that we must consider how the
environment has changed since the 70's.
This archive was generated by hypermail 2.1.6 : Sun Oct 03 2004 - 22:06:53 PDT