You are on page 1of 18

The Design Philosophy of

DARPA Internet Protocols


David D. Clark.

History
DARPAs initiative to build a suite of protocols
began 30 years ago.
Intended for packet switched networks.
Widely used in military and commercial systems.
Author joined project in mid-70s, took over
architectural responsibility in 1981.

Fundamental Goals
Interconnectivity
provide some larger service.
integrate autonomous units.

Multiplexing Technique : Packet Switching.


rlogin.
existing networks.

Interconnecting switches would employ the Store


and Forward technique. [Gateways]

2nd Level Goals

Survivability.
Support service multiple types.
Accommodate a wide variety of networks.
Permit distributed management of resources.
Be cost-effective.
Permit host-attachment with a low-level of effort.
Permit resource accountability.

2nd Level Goals [Discussion]


Features given in order of importance.
Author stresses : Interconnection first, Survivability
next, rest come later.

(Hence) Original architects paid less attention to


accountability and security.
Changing priorities can change architecture.
Nowadays accountability is more important : QoS.

Survivability
Communicating entities should be able to
continue conversation (in face of failure) without
re-establishing or resetting high level state.
How? By masking Transient failures by hiding
Synchronization from client (application).
Conversation details.

Where to store state ?


Switches replication distributedcomplex.
End-Points [Fate-Sharing]. [End-To-End Argument]

Survivability [contd.]
Chose Fate-Sharing.
Protects against any number of intermediate failures.
Easier to engineer.

Enter Soft-State, refresh based mechanisms.


Fate-Sharing consequences for Survivability
gateways become stateless.
More trust placed in host machine.

Types of Service
Support variety of service types.
E.g. differing requirements in speed (ftp), latency (rlogin)
and reliability.
Real-Time delivery of digitized speech.

Clearly more than one transport layer required else


would be too complex and fat for most
applications. [mismatch between application needs
and supplied primitives].
Did not wish to make any assumptions since could
add service types in the future use datagram as
basic building block.
Best Effort delivery

Varieties of Networks
Success of the Internet was to be able to
incorporate and utilize a wide variety of network
technologies.
Achieves flexibility by makes a minimum set of
assumptions about the networks.
Network can transport a packet/datagram.
Packet should be delivered with good but not perfect
reliability.
Network should have some form of addressing.
Other services can be built on top of these at endpoints.

Distributed Management
Several Autonomous Systems (AS) connected by
gateways that are independently managed.
2 level routing hierarchy which permits gateways
from different organizations to exchange routing
tables.
Organizations which manage gateways are not
necessarily the same organizations that manage the
networks to which the gateways are attached.
Private routing algorithms within gateways of a
single organization.

Cost Effectiveness &


Accountability
Small data packets have large overheads (in terms
of headers etc.).
Reliable communication system example from the
end-to-end argument paper.
Only currently being studied. (Author has a later
paper Differentiated Services).

Attaching a host to the Internet


Author states that cost of attaching a host to the
Internet is somewhat higher that in other
architectures. [didnt quite get this]
Poor implementation of host resident mechanisms
can hurt the network as well as the host.
Used to be a limited problem localized now
grown big.
Fate-sharing not good if host misbehaves.
[monitors/watch-dogs security papers later].

Architecture & Realization


Architecture
Realization - particular set of networks, gateways
and hosts which have been connected in the context
of Internet Architecture.
Wide variability in realizations by way of
performance and characteristics.
The various Autonomous networks constituting the
Internet
could
have
different
topologies.
Redundancy could be added depending on need.
The Internet Architecture tolerates the variety by
design.

Implementation
Protocol verifiers confirm logical correctness but
omit performance issues.
Even after demonstration of logical correctness,
design changes (when faults are discovered) can
cause performance degradation by an order of
magnitude.
These difficulties arose because of tensions
between architectural goals (not to constrain
performance, permit variability) and because no
formal tools for describing performance existed.

Datagrams
Gateways do not need to maintain connection
state.
Basic building block out of which a variety of
services can be built.
Represent minimum network service assumption.
The author repeated clarifies that the datagram is
not intended to a service in itself. [gives several
examples].

TCP
Originally flow control was based on both bytes
and packets.
Discarded too complex.
TCP => Byte stream.
Permit TCP to fragment a packet so can pass through
networks with smaller MTUs. However this was later
moved to IP layer.
Permit small packets to be gathered to a bigger packet.
Allowed insertion of control information in byte
sequence space so control could also be
acknowledged dropped.
In retrospect, need both byte and packet control. [???]

TCP contd.
EOL Flag :
Original idea break byte stream into records.
Different records => different packetsgoes against
combining packets especially on retransmission.
Hence semantics was changed data upto this point is
a record.
Now 1 record => 1 or more packets => combining was
possible due to presence of delimiters.
Various application now had to invent a way of
delimiting records.
Some rare problem. EOL had to use up all sequence
space upto next value.

Conclusions
The Internet architecture has been very successful.
Datagrams have solved high priority problems, but
made it difficult to solve low priority ones. E.g.
accountability.
This is due to the stateless nature of switches and
the elemental nature of datagrams as a building
block.
Author identifies a better building block : Flow
Accountability/Service differentiation : DiffServ.

You might also like