===================================================

From takhoa@owlnet.rice.edu Wed Jan 21 17:56:47 2004

===================================================
This is not a controversal paper because it only re-tells history.
It's interesting to see how early decisions fit well within the end-to-end
argument. For example, according to the paper, building a network that
assumes too much (such as reliable delivery) is not a good idea since it
cannot support different types of service. It's also interesting to know
that TCP and IP were originally a single protocol and later split to
support a more modular and end-to-end structure, and that UDP was
introduced to complement the purpose of TCP.
The author also gives answers to why some of the the pressing issues with
the Internet, such as accountability and performance, were not addressed
in the original design. Due to the fact that the Internet were originally
designed for the military, it makes sense that a circuit switched network
is not acceptable. For those who criticize the design of the Internet, a
historical look back at its intial purpose shows that the Internet was
very well designed to the original specification and requirements. The
need to retain state information was cleverly answered by making end hosts
and individual packets responsible, thus alleviating the need to rely on
the stability of the underlying links.
Regardless of the difficulty in understand and simulating the behaviors of
the Internet, I am impressed with how insightful "back-of-envelop"
analyses were. However, since ideas shaping the Internet today have been
refined and morphed (sometimes akwardly) from those original analyses, it
is easy for us to relate the original analyses to the sucess of the
Internet and credit their insightfulness. Different analyses might have
been more insightful and offer a better evolution of the Internet.
However, since there are no other "Internet"s today to compare with, it is
difficult to gauge the insightfulness of those original analyses.
===================================================
From gulati@cs.rice.edu Wed Jan 21 21:20:38 2004
===================================================
The design philosophy of DARPA internet protocols
This paper talks about the original properties that were desired from
protocols like IP and TCP with major focus on IP. The IP was designed
primarily for military use and internetworking diverse networks used by
defence
agencies. So survivabilty and ability to support heterogeous networks were
given
importance over accountability of resources and cost effectiveness.
Ability to
route around failures required
hosts to maintain all the state associated with a flow and network to just
store and forward the
packets. This put all the complexity and decision power in hosts
rather than
network. TCP was integrated with IP to add reliability to the
network.
Later on with the advent of new applications like XNET, multimedia and
voice transfers,
it was realized that TCP can't support all services and it

was separated from IP to coexists with UDP(it provides fast, but

unreliable transport over IP) in a higher layer.
Hence IP was defined just as a means to route packets by acting as a glue
to
connect heterogenous networks and thus minimal set of features required by
all the services above IP were included in IP.
This allows multiple applications to use IP according to
their own characteristics and usage requirements. Although both TCP/IP are
in both military and
commercial use today, some of the design choices that were made earlier
doesn't match the needs of users today. So active research in areas of
accounting, performance improvement, cost minimization is required to make
TCP/IP work for future applications.

===================================================
From twngan@cs.rice.edu Thu Jan 22 06:23:55 2004
===================================================
After 15 years of development of the IP protocol and related packet
switched networking, this paper tries to provide the rationale and the
design philosophy behind the decision choices. It was mostly influenced
by DARPA's goal of providing "effective" techniques, which emphasizes on
survivability and interoperability. As a result, many other desirable
features are not incorporated into the design, such as accounting and
resource management. The author suggests a more virtual circuit-like
building block instead of pure datagram; the basic idea is to have
"flows" of data and soft states.
===================================================
From animesh@cs.rice.edu Thu Jan 22 15:00:25 2004
===================================================
Review ( The Design of the DARPA Internet Protocols)
-----This paper describes the design rationales behind the development of
the TCP/IP architecture. The main goal was to design an architecture
that would allow to interconnect the diverse existing networks. They
proposed packet switching as a technique multiplexing these diverse
networks and the datagram was would thus serve as an
entity which is transported across the underlying networks. The
other goal of the architecture was to recover from transient
failures of intermediate gateways/ networks and for this purpose
they decided to keep all state related to the connection at the
endpoints. They called this technique fate-sharing. The other design
goal was to support varied services with different requirements of
latency/bandwidth/reliability. Providing some or all of these
guarantees at lower layers would imply overhead for applications
that might not need them. It was decided therefore that the
architecture be layered into IP layer which dealt nly with the
transmission of the datagrams with 'best effort' and a higher TCP
layer whcih could provide the reliability guarantees to applications
that might need it. There were other requirements from the
architecture like distributed management of resources which figured
low in the priorities and incorporating these goals into the design
are still ongoing research. Ieas of using notion of flows for
accounting and mananging resources have been suggested.

===================================================
From anwis@cs.rice.edu Thu Jan 22 15:15:49 2004
===================================================
The Design Philosophy of the DARPA Internet Protocols
This paper discusses the motivation behind why the TCP/IP suite is how it
is at present. The main design goal was to interconnect
heteregenous networks into a large internetwork efficiently. Since packet
switching was well understood, and the individual networks
were packet switched, the decision was made to create an internetwork via
gateways that were simply packet switching processors. A
wide variety of networks are supported by requiring that the network
simply provide a best effort service and have the ability to send
a single packet to the correct destination. More complex needs, such as
reliable delivery or provision of multiple levels of service
could be provided by higher layers. Otherwise, these services would have
to reimplemented for every network and for every host
interface to the network.
Two other important design goals were also to survive in case some portion
of the network failed and to provide a variety of service.
To protect against network failure, the designers decided to implement all
state information in the end-hosts rather than the
intermediate nodes. Thus, the intermediate routers are purely packet
switched and the complexity of implementation is put upon the
end hosts. Of course, the advantage here is that information for a host
will be lost only if the host dies when it is not needed in
any case. The original TCP protocol was meant to provide a service for
different requirements such as speed, latency, and reliability.
However, it was quickly realized that the needs of applications
outstripped the service that could be provided by one transport layer.
This realization forced the separation of TCP and IP into two separate
layers. IP would provide best-effort service and would form
the building block upon which more demanding transport protocols could be
built, such as those requiring reliable in order delivery.
The author clarifies that datagrams were not designed simply because
applications require them, but because they were to form the
building blocks of higher layers as mentioned above. In fact, most
applications require more service than a pure datagram can provide.
The designers of the original TCP/IP suite did not wish to constrain the
implementors with irrelevant details because they realized
that the implementation would be different for 1200 bps phone lines and
1Gbps optical links. Therefore, the designers were only concerned with
forcing logical correctness of the implementation. However, they soon
realized that performance was just as important as
logical correctness, but unfortunately, there were not any formal tools
to describe performance.
Finally, the author discusses the rationale behind some of the important
developments of TCP. For example, the designers decided
to acknowledge bytes instead of packets to eliminate the problem of
packets will a small number of data bytes. In other words,
retransmissions of packets with one byte each would cause a flood of
packet retransmissions. On the other hand, if bytes were acknowledged,

then all the bytes could be gathered into one single packet for
retransmission.
===================================================
From mittal@cs.rice.edu Thu Jan 22 15:22:30 2004
===================================================
Paper 2 - The Design Philosophy of the DARPA Internet Protocols
This paper seeks to explain some of the historical perspectives that have
influenced the design philosophies behind the TCP/IP architecture. TCP/IP
was basically developed by DARPA around 15 years ago. When TCP/IP was
first proposed, the motivation was to have a technique that could utilize
the existing interconnected networks. Since most of the applications being
supported were served by packet switching technique, packet switching was
accepted as the fundamental component of the architecture. Besides the
primary goal, there were a number of subsidiary goals as well, which
included network communication despite loss of networks, supporting
multiple types of services and network architectures, distributing
management of resources, cost-effectiveness, accountability of service use
etc. TCP owes its evolution to the order in which these goals were
assigned importance. For example, survivability was put as the first goal
since the protocol was designed to operate in a military context.
Similary, accountability was put as the last goal since it mattered the
least.
Also, the author feels that the relationship between architecture and
performance is complex. However, there is no definite way of formalizing
performance constraints within an architecture.
The original ARPANET host-to-host protocol had flow control on basis of
both bytes and packets. In TCP however, regulation of byte delivery was
chosen, for several reasons : ability to permit insertion of control
information, ability to break TCP packet into smaller packets if required
and for acknowledging bytes rather than packets. Also, datagram is the
basic entity tranported over the network. Datagram is a building block
over which services should be built.
In short, the paper highlights some of the decisions that contribute to
the present architecture of TCP/IP. It has met with the goals that it was
specifically designed for, those related to defense and military operations. It
remains to be seen what modifications these protocols would undergo when
the major objectives would be accountability, real-time communications,
security and reliability of data transfer etc. The evolution would
continue to be monitored by requirements and desires, and it is
inevitable that effort would be to 'hack' the existing architecture
rather than a redesign each time, purely because of legacy and backward
compatibility.
===================================================
From santa@cs.rice.edu Thu Jan 22 15:30:10 2004
===================================================
The Design Philosophy of the DARPA Internet Protocols
The fundamental goals of the DARPA Internet Protocols in order of significance
have been detailed by the author. The Internet has transformed from a
military/educational network to a commercial network today and has changed the
siginificance of some of these goals though. The primary goal was to develop an

effective technique for multiplexed utilization of existing interconnected

networks. The second level goals in order are: # Continue despite loss of
networks and gateways. This gave rise to the end-to-end principle where all the
complexity and state is stored at the endpoints and the routers themselves are
stateless. # Support multiple types of communication. For example, low latency,
high reliability, etc. This led to TCP and IP to be separated into layers
rather than being in one layer as they initially were. # Accomodate a variety of
networks.
The very basic was expected from networks such as a minimum data packet size tha
t the
network must be able to handle. # Distributed management of resources
# Cost effective. # Low effort. # Resources be accountable. This goal was the
least important, and should have been pretty high up on the list had the
Internet been conceptualized as a commercial network.
===================================================
From amislove@rice.edu Thu Jan 22 15:50:16 2004
===================================================
In this paper, the author describes the design philosophy behind the
Internet protocols, including IP, TCP, and UDP. This paper does not
present the protocols (they had existed for a number of years before), but
it aims to simply describe the experience gained from desiging and
deploying the protocols. The paper begins by discussing some of the
fundamental goals of the Internet protocols, including developing a
effective technique for mulitplexed utilitzation of existing
interconnected networks. The author then describes the other goals and
how they were achieved, such as survivability, multiple types of service,
multiple network types, distributed management, and cost-effectiveness.
The paper describes in detail why TCP/IP was split into two seperate
layers, and how UDP came into existence. The author also includes
descriptions of some of the design decisions which shaped TCP which may
not be clear from the RFCs.