Professional Documents
Culture Documents
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.
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.
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.
Survivability [contd.]
Chose Fate-Sharing.
Protects against any number of intermediate failures.
Easier to engineer.
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.
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.
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.