Internet Architecture &
Design Philosophy
CS4482 High Performance Networking
Dilum Bandara
Dilum.Bandara@uom.lk
Some slides extracted from Dr. Dan Massey’s CS557 class at Colorado
State University

Outline
1. J.H. Saltzer, D.P. Reed, and D.D. Clark, “End to End
Arguments in System Design,” ACM Transactions on
Computer Systems, vol. 2, no. 4, Nov. 1984, pp. 277-
288
2. D.D. Clark, “Design Philosophy of the DARPA Internet
Protocols,” ACM, 1988
2

Architecture
 Dictionary definitions
 A style & method of design & construction
 Orderly arrangement of parts
 Manner of construction of something & disposition of
its parts
 Design, the way components fits together
 Definitions vary & no one agrees
 Goal
 Why the Internet was designed this way?
3

4
OSI
Stack
Source: http://walkwidnetwork.blogspot.com/2013/04/physical-layer-osi-model.html

Layered Design
5
Source: http://blog.anuesystems.com/category/span-and-taps/

Hourglass Architecture
 Why internet layer?
 Make a big network
 Global addressing
 Virtualized network to isolate
protocols from network details
 Why only IP?
 Maximum interoperability
 Minimize no of service interfaces
 Why IP is so narrow?
 Assumes least common network
functionality  many networks 6
Steve Deering’s
hourglass showing
“waist” of the Internet
Source: http://isoc.org/wp/ietfjournal/?p=454

Hourglass Architecture Insufficient
7
Putting on weight
Need for more
functionality
Midlife Crisis
Address space not
sufficient

Architecture often seen today
8
Source: http://isoc.org/wp/ietfjournal/?p=454

End-to-End Argument [1]
 Examines which layer should implement a service
 Argue many services should be implemented at
higher layers
 e.g., on end hosts
 Contributions
 Fits with the model of minimal network (IP) layer
 Provides guidance on what (not) to add to data link
layers
 End-to-end principle is fundamental to Internet success
9

Which Layer?
 Services
 Reliable delivery
 Duplicate message suppression
 FIFO ordering
 Delivery guarantees
 Encryption
 Transaction Management
 Recovery from crashes
 Options
 Lower layers help application by providing those services
 Lower layers are of little help as application has the final
say 10

File Transfer – Example
 Errors can occur at many levels
 Transfer from sender disk to memory
 Transfer from sender OS to sender line card
 Transfer across network
 Transfer from receiver line card to receiver OS
 Transfer from receiver memory to disk
 What would be the effect of a perfectly reliable
network?
 Does not recover from other errors
 Provides a false sense of security
 Impact other applications that don’t need those services
11

Tradeoffs
 As far as application has to perform its own
checking, extra effort at network level is of little
help
 End systems have information on semantics &
requirements
 Application state
 Network has information on data transmission
parameters (packet size, error rate)
 Assuming packets follow the predicted path
12

Other Examples
 Delivery guarantees
 Did the end act upon the received message?
 Encryption
 Clear data before entering the secure network
 Duplicate message suppression
 Applications may retry, e.g., remote login
 FIFO ordering
 In distributed systems with multiple destinations
 Recovery from crashes
 What if the network failed & all state is lost?
13

Rules of Thumb
 Consider marginal gain in lower layer
 If you can achieve large impact with limited effort, go
for it
 Consider impact on other services
 Implement at lower layer, only if minimal impact on
applications that don’t use that service
 General Result
 Implement services at the end, not inside the network
14

Why TCP/IP? [2]
 Objective
 Why TCP/IP was designed this way?
 DARAP Internet Architecture
 1 fundamental goal
 Several 2nd level goals
 Ordering of 2nd level goals
15

Fundamental Goal
 Allow connection of many existing networks
 Effective technique for multiplexed utilization of existing
interconnected networks
 Some important assumptions
 Connect ARPANET with ARPA packet radio
 Networks represent administrative boundaries
 Rely on packet switching & store and forward
 Net result
 Packet switched network consisting of distinct networks
with store & forward gateways between them
16

2nd Level Goals
1. Function despite loss of networks/gateways
2. Support multiple types of services
3. Accommodate a variety of networks
4. Distributed management of resources
5. Cost effective
6. Low level of effort to add a host
7. Provide accounting of resources used
 What else could a network designer ask for?
17

Fundamental Trade-Offs
 All goals can’t be satisfied equally
 Which goals win & which lose in the trade-off?
 Order of goals is essential
 Very strong focus on first 3
 Survive network & gateway failures
 Provide different types of services
 Accommodate a variety of networks
 See a connection to hourglass model?
 A different order would produce a different design
 e.g., accounting barely works at all in the Internet
18

Survivability
 Links & Gateways will fail & stop working
 Design didn’t anticipate misbehaviour
 Source has no physical path to destination
 2 entities can continue to communicate
 Despite faults at any intermediate point
 Mask any transient failures, e.g., route changes
 Break only if total network partition
 See a connection to end-to-end principle?
19

Achieving Survivability
 Implications for storing network state
 Failure of intermediate nodes  loss of state
 Must replicate state stored at intermediate nodes
 Replication is difficult
 Clever Solution
 State only stored at edges
 Stateless packet switches (middle of network)
 State at the edge
 e.g., TCP state: seqnum, acknum, window, etc.
 Fate-sharing
 Acceptable to lose the state if the host itself has failed
20

Types of Services
 Virtual circuit service (TCP)
 Bi-directional reliable delivery
 Differing goals even within this service
 High bandwidth, delay not so important, e.g., file transfer
 Low latency, bandwidth less important, e.g., Telnet
 Other services
 Low complexity, no reliability, e.g., debugging
 Predictable rate with minimal jitter, e.g., voice
 Reliability is counterproductive
21

Types of Services (Cont.)
 Split TCP/IP as 2 separate layers
 TCP (transport) & IP (network)
 Datagram as basic building block
 No assumption desired service is present in
underlying network
 Build services such as TCP or UDP at the end hosts
22

Variety of Networks
 Assumptions regarding underlying network
 Transport a packet with reasonable packet size
 Reasonable (but not perfect) reliability
 Reliability proved a problem for sending voice
 Assumptions that weren’t used
 Reliable or sequenced delivery
 Network broadcast or multicast
 Priorities or services
 Failures, speeds, or delays
 Minimal set of functionalities
 Build other services at host, e.g., TCP for reliability 23

Other Goals
 Distributed management
 Success in allowing multiple domains (2 tier routing)
 Failure in routing policies
 Cost Effective
 Longer headers reduce efficiency
 Retransmission at the ends reduces efficiency
 Adding Hosts
 Host software is complex
 Relies on correct implementations at the host
 Misbehaviour is a real problem today
 Accounting
 Challenges of datagram model
 May prefer flows for accounting 24

Implementations
 Proven to meet goal of network variety
 Some high speed, some not
 Some highly redundant, some single point of failure
 This failure is due to the implementation, not the design
 Leaves much of the work for implementation
 What bandwidth? What redundancy?
 Performance Goals
 Little good guidance
 Limited effective simulation
 Specifying Performance
 Must specify it, or you won’t get it
 Leave it to network administrators to specify performance goals
25

Summary
 Identified & Prioritized Goals
 Top 3 goals very successful
 Bottom goals less successful
 Building block – datagram
 Very effective for top goals
 Suggests “flows” may be better (for different priorities
of goals)
 Suggests Period Messages – Soft-state
26