Lecture Outline
• A brief history of the Internet
Internet Design Principles and • How is the Internet different from the
Architecture telephone network (and why)?
• Design goals and principles
Venkat Padmanabhan • End-to-end (E2E) argument
Microsoft Research • Rethinking the principles
2 April 2001
• Overview of projects
CSE561 Venkat Padmanabhan 1 CSE561 Venkat Padmanabhan 2
Spring 2001 Spring 2001
A Brief History of the
POTS versus Internet
Internet
Two motivations Many similarities
• sharing of expensive computing resources
• Large scale (1B+ phones, 100M+ hosts)
• robust communication infrastructure
Timeline • Global coverage
• 1961: packet switching invented • Hierarchical addressing
• 1969: ARPAnet born • Link heterogeneity
• Early 70s: TCP/IP designed
• 1983: NCP → TCP/IP transition
• 1986: NSFNET backbone created
• 1995: full transition to commercial Internet
CSE561 Venkat Padmanabhan 3 CSE561 Venkat Padmanabhan 4
Spring 2001 Spring 2001
POTS versus Internet POTS
Main difference Several factors simplify engineering
• single-function versus multi-function • one service model: voice
• constant bit rate (64 Kbps)
which leads to several others
• traffic engineering using models of voice calls
• circuit switching versus packet
• flow control and error recovery by humans
switching
• congestion control via busy signals
• intelligence in the core versus in the but
edges • tight latency constraint (100-200 ms)
CSE561 Venkat Padmanabhan 5 CSE561 Venkat Padmanabhan 6
Spring 2001 Spring 2001
1
Internet Architecture Goals
Internet
(Clark88)
Several complicating factors Main goal: multiplexed utilization of existing
• multitude of applications interconnected networks
Secondary goals
• bursty traffic
• survivability in the face of failure
• no universal model for traffic engineering
• support for multiple types of service
• protocols need to do flow control, congestion • support for a variety of networks
control, and loss recovery
• distributed management of resources
but • cost effectiveness
• less stringent requirements (“best effort”) • easy addition of new hosts
• accounting of resource usage
CSE561 Venkat Padmanabhan 7 CSE561 Venkat Padmanabhan 8
Spring 2001 Spring 2001
Design Decisions Packet Switching
• Packet switching as basis for • Invented by Baran, Kleinrock et al. in early 60s
multiplexing • Radical departure from circuit switched model
• Store-and-forward gateways as basis • Far more efficient for data communication
for interconnection since it is bursty (peak >> average)
• Key idea: statistical multiplexing
• “Fate-sharing” model for reliability – share on demand
• Layering – based on statistics of offered load rather than a
fixed offered load
• Minimal assumption about the network
CSE561 Venkat Padmanabhan 9 CSE561 Venkat Padmanabhan 10
Spring 2001 Spring 2001
Statistical Multiplexing:
Statistical Multiplexing
Example
• One user sends at 1 Mbps and is 90% idle • Occasional oversubscription
– 10 Mbps channel; 10 users if statically allocated
– need for buffering inside the network
Prob Prob
2 users 10 users – need for loss recovery
– need for congestion control
• How much statistical multiplexing is
there in the Internet?
0 1 2 Mbps 0 1 … 10 Mbps
• For 35 users, prob(>10 active) = 0.17%
CSE561 Venkat Padmanabhan 11 CSE561 Venkat Padmanabhan 12
Spring 2001 Spring 2001
2
Network Interconnection Layering
• Minimal assumptions made about the individual • Need abstractions to handle complexity
networks
– ability to transport a datagram of a certain • A protocol layer
minimum size – implements a fixed set of functions
• Networks interconnected by a layer of – exposes a well-defined interface to other
gateways
layers
• IP is the common glue
• Intelligent end-points do the rest • Good design principle but not always
– scalable ideal for implementation
– flexible
CSE561 Venkat Padmanabhan 13 CSE561 Venkat Padmanabhan 14
Spring 2001 Spring 2001
OSI Reference Model Internet Protocol Stacks
• Seven Layers Their functions: Many
Application
Application – application-dependent (HTTP, SMTP)
Presentation – Encode/decode messages Transport TCP / UDP
Session – Manage connections
Transport – Reliability, congestion control
Network IP
Network – Routing Many
Link
Link – Framing, multiple access (Ethernet, …)
Physical – Symbol coding, modulation
Model Protocols
CSE561 Venkat Padmanabhan 15 CSE561 Venkat Padmanabhan 16
Spring 2001 Spring 2001
Supporting Multiple Types of
Survivability
Service
• Original Internet protocols (Cerf & Kahn 74) • Continued operation in the face of network
– TCPIP was one protocol and gateway failures
– addressing + “virtual circuit” service • Only failure on top of transport layer is total
• But this was sub-optimal partition
– service abstraction not suitable for all applications • There has hard state that must be protected
(e.g., packet voice)
• “Fate-sharing” model: OK to lose state
• Layering to the rescue information if entity also lost
– TCP and IP were split up into separate protocols
• So hard state stored in hosts, not switches
– UDP created to provide datagram service
• End-to-end principle generalizes this idea
CSE561 Venkat Padmanabhan 17 CSE561 Venkat Padmanabhan 18
Spring 2001 Spring 2001
3
End-to-End Principle
Careful File Transfer
(Saltzer, Reed, Clark 84)
• Articulation of conventional wisdom in system • Goal: reliable transmission of a file
design • Threats
• An argument against low-level function – corruption/loss at endpoints
implementation if completeness and – corruption/loss within the network
correctness require participation of endpoints – host crash
• Low-level function implementation may • Error recovery within the network would be
sometimes be warranted as a performance – inefficient: not needed for all applications
enhancement – incomplete: doesn’t address end-point failure
– soft state versus hard state • Preferred approach: end-to-end check and
• Layering is a consequence of the E2E principle retry
CSE561 Venkat Padmanabhan 19 CSE561 Venkat Padmanabhan 20
Spring 2001 Spring 2001
E2E and Wireless Links Other Examples
• Wireless links tend to be error prone • Secure data transmission
• E2E retransmissions may be expensive – WEP a bad idea?
• So link-level ARQ is commonly used • Duplicate message suppression
• E2E still needed no matter how good – sequence numbers
link-level ARQ is • FIFO message delivery
• Danger: competing retransmissions – TCP fast retransmission allows some slack
• More?
CSE561 Venkat Padmanabhan 21 CSE561 Venkat Padmanabhan 22
Spring 2001 Spring 2001
Internet Architecture Goals
E2E and Thin Clients
Revisited
Proxies to integrate thin clients into the • survivability in the face of failure
Internet
Pros: • support for multiple types of service
• content transformation • support for a variety of networks
• performance benefit (e.g., caching) • distributed management of resources
Cons:
• cost effectiveness
• end-to-end transformation may be better
– Web page author is one “end” • easy addition of new hosts
• encryption might shut out proxies • accountability of resource usage
CSE561 Venkat Padmanabhan 23 CSE561 Venkat Padmanabhan 24
Spring 2001 Spring 2001
4
What if the priorities were Rethinking Layering
different? (Clark, Tennenhouse 90)
• Accountability of resources • Separation between layers may not be as clean
as we would like
– billing database attached to each router
• Basic problem: layering may not be the most
– digitally signed packets effective modularity for implementation
• Easy attachment of hosts • Example #1: data manipulation functions
– dumb hosts and smart switches – copying data, buffering, encryption, formatting
– inefficient to do these in different layers
– DHCP: greater dependence on the network
• Example #2: lost and mis-ordered data
• Low cost – presentation formatting can happen in parallel with
– uniform networks loss recovery
CSE561 Venkat Padmanabhan 25 CSE561 Venkat Padmanabhan 26
Spring 2001 Spring 2001
Two New Principles Structure of the Internet
• Application-level Framing (ALF)
You at work Large corporation
– lower layers should deal with data units that
the application specifies (ADUs)
“Consumer ” ISP
– is P-HTTP a good idea? Peering
point
• Integrated Layer Processing (ILP)
Backbone service provider Peering
point
“ Consumer” ISP
– there may be ordering constraints
– need well-designed ADUs
“Consumer”ISP
Large corporation
• Used in actual applications Small
corporation
You at home
– example: scalable reliable multicast
CSE561 Venkat Padmanabhan 27 CSE561 Venkat Padmanabhan 28
Spring 2001 Spring 2001
Practical Issues Recap
• Interconnection • Key features of the Internet
– competitors are forced to cooperate – multi-function
• Client-provider versus peer-peer – heterogeneous networks
– who is providing more value? – intelligence at the edges
• Settlements • End-to-end principle
– fate sharing
• Internet’s design is a reflection of its
priorities
CSE561 Venkat Padmanabhan 29 CSE561 Venkat Padmanabhan 30
Spring 2001 Spring 2001
5
Next Lecture
• D.R. Boggs, J.C. Mogul, C.A. Kent,
Measured Capacity of an Ethernet:
Myths and Reality, ACM SIGCOMM
1988 (review due)
• Brush up on routing basics
CSE561 Venkat Padmanabhan 31
Spring 2001
6