From: Seth Cooper (scooper@cs.washington.edu)
Date: Sun Oct 03 2004 - 22:02:30 PDT
The main purpose of this paper was to discuss what the goals that drove
the architecture of the Internet were, and how they led to the design
of the Internet as it is now. The primary goal of the Internet was to
come up with a multiplexing scheme that could take advantage of
networks that already existed. The multiplexing scheme that was decided
on was to create a packed switched network for sending datagrams,
where individual networks could be connected by gateways.
One of the strengths of this paper is that it states why the datagram
was a good choice as a building block of the Internet. For example,
datagrams allow the Internet to be built out of stateless packet
switches, using the idea of "fate-sharing" and placing connection state
information in the end hosts. This allows a connection to continue to
be established even in the case of failure. Also, because a datagram's
delivery is "best effort," it allows for a variety of services to be
built on top of it. Services could build reliability on top of the
datagram, or if they did not need reliability, they would not have to
pay the overhead for it.
Another strength of the paper is how it discusses how the design of the
Internet did not meet some of its lower-priority goals as well as its
higher-priority ones. For instance, the fact that the Internet is
composed of stateless switches makes accounting for resources
difficult. Also, placing a large burden of service implementation on
end hosts means that a poor implementation on a host may hurt no only
that host, but the rest of the network as well.
One problem with the paper is that it seems to confuse modeling of TCP
as a byte stream for applications and acknowledging bytes for flow
control. The paper gives many good reasons for acknowledging bytes
(rather than packets) in a flow, but does not say why the byte stream
is a useful conceptual model to present to higher-level applications. A
reliable datagram protocol may have been useful for users. The paper
even mentions that application designers often have to come up with "ad
hoc" methods for separating their high-level records when they are
inserted into the stream.
The work could be improved by discussing how a network that is not
packet switched (for instance, a circuit switched network) might have
failed to meet the goals for the Internet architecture. The paper does
a good job of saying why a packet switched network meets the goals, bu
does not fully explore how other alternatives might have fared.
The paper is relevant today because the decisions the paper talks about
are reflected in the design of the current Internet. Those decisions
allowed the Internet to scale and become as large and useful as it is.
If changes are to be made to the Internet infrastructure, or if it is
to be improved, it is important to understand why the original
decisions were made so that what made the initial design of the Internet
so successful can be preserved.
This archive was generated by hypermail 2.1.6 : Sun Oct 03 2004 - 22:02:27 PDT