1) We have been using Internet for the past decades without knowing what led the internet to be in

the present form in terms of architecture and protocols. This paper tries to project the motivation
and reasoning which led to design of Internet in the early stages. It specifically addresses the
fundamental goals, secondary goals and the design challenges faced by the DOD while putting
forward the building blocks of Internet. This paper tries to elaborate upon why few of the goals
superseded few other goals and how it effected the design of Internet. It explains about the design
decisions taken in order to resolve challenges such as survival in case of failure and accommodating
different types of services. At last, it also let us know the design aspects which could have been done
differently to achieve the goals in a better way. Few of the key questions answered by the paper is
why the state information is stored only at host, Why was there a need to split single TCP layer into
TCP and IP, Why was there a need of UDP, Why most of the functionalities were pushed to end hosts
rather than gateways.

2) The problem addressed by the paper is important because it tells us about the approach taken by
the DOD in order to interconnect the different networks. It documents the what and why of the
critical design decision. This type of documentation has great relevance to both today's and future
work on the Internet since historical review can help us avoid future mistakes and forecast potential
dangers and opportunities.

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.

3) Reasons for some fundamental designing features of the protocols are stated in the paper. For
example, the reason that packet switching was accepted instead of circuit switching in the Internet
architecture is to satisfy the top goal of multiplexed utilization of existing networks.

Moreover, the second level goals led to the design of (TCP), the separation of Internet Protocol (IP)
from TCP and the creation of (UDP). Thus, from this paper, we can know very clearly how those
different protocols were created and the reason why they were created in this way not the others.
The author does not only stop in describing the existing Internet protocols, but also shows the
imperfect parts of the Internet architecture and the goals that current protocols haven't reached
yet. For instance, the Internet architecture is not cost effective and resource management and
accountability is still unsolved. In addition, the extremely challenging relationship between
architecture and performance is stated in the paper.

4) In order to present clear picture of transformation of single network to interconnection of several

network the author took a goal-based approach. He listed the primary and secondary objectives of
the designers. The goals were arranged in order of their precedence. This ordering of goals was very
important for the readers to know why the trade-off decision were taken inclined towards certain
aspects. For example, why the state information is stored only at host to ensure that there is no
disruption of communication in case of reconfiguration of network at lower layers. Also, Why Packet
switching was used instead of circuit switching, because (a) applications such as remote login which
were used back then were better served, (b) the networks that were to be interconnected were
already packet switched networks. Perhaps another reason for packet switching is the goal of
making the Internet as survivable as possible.

5) The author evaluated the design decisions by how much they were able to suffice the
requirement.

One of the key result of the paper is splitting of TCP into two layers to support multiple type of
services. TCP provides reliable sequenced data stream while IP offers basic building block where
different services can be built. User Datagram Protocol (UDP) was made for the basic datagram
service of the Internet as an application level interface. Interconnecting varied networks was
achieved by the assumptions that packet or datagram was of reasonable size, can be transported,
and can be transmitted with reasonable but not perfect reliability. The remaining secondary goals
were less met because of lower importance compared to the three.

According to the paper, performance and architecture association is a very challenging task because
it is very difficult to formulate such performance benchmarks within the architecture.

6) Strengths: A protocol stack which was tolerant to intermediate failures and simple at the network
interfaces was designed. The trade-off between reliability and real-time delivery was achieved.

It offers a solution that is highly scalable, which is why the number of hosts on the Internet has
grown exponentially in the past decade. Even in today's world, even though some of the original
assumptions behind the design no longer applies, the solution presented by the paper is still
considered highly successful.

Weakness: 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.

This paper emphasizes on simplicity over complexity. As a result, instead of having mechanisms in IP
make sure packets are delivered correctly, the burden of verification is placed on the end hosts, or
what the author calls as "fate-sharing." All of these design criteria led to a highly decentralized
architecture that is reliable but not as accountable.

7) This paper takes up from the TCP and addresses the issues that followed post that. Further
extension could be to explain the design rationale behind the TCP protocol itself.

The paper proposes a number of open problems. One such problem involves determining the
performance of a particular implementation of the IP/TCP protocol. The author does not claim to
have a solution for this and thus, a possible future work could be geared towards analysing the
performances of different implementations of that protocol. Proposal of some standards that would
maximize the performance of a given realization.

Another open problem suggested in the paper is to explore alternative building blocks (other than
datagrams) for the DARPA Internet protocol.

The author also gives some suggestion on protocol design to achieve more goals. "Flow" is
introduced to characterize the data block which makes resource management and accountability
possible. The concept "soft state" is declared which is to achieve the goals of survivability and
flexibility.