Transcript The Design Philosophy of DARPA Internet Protocols

The Design Philosophy of
DARPA Internet Protocols
David D. Clark.
History
• DARPA’s 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-70’s, 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]
nd
2
•
•
•
•
•
•
•
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.
nd
2
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… distributed…complex.
– 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. [didn’t 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 packets…goes 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.