Transcript ppt - CSE Labs User Home Pages

Internet Design: Big Picture
• Internet architectural, design and implementation
principles
– not “scriptures”, but guidelines
– understand pros and cons, trade-offs involves
• Original Internet Design Goals
– what contributed to the huge success?
– what still amiss, biggest weaknesses?
• Internet as a case study
– virtualization., layered architecture, end-to-end
argument, soft-state, fate sharing, …
• Readings: ; [Cla88], [SRC84], [Car96]
– See Reading List
CSci5221:
Internet Design
1
Architectural Principles
(not unique to networks!)
Zhi-Li’s version (synthesized from various sources)
• End-to-end argument
– functionality placement
• Modularity
– Increase inter-operability and manage complexity
• vertical partition -> layered architecture
• horizontal partition?
• Keep it simple, stupid (KISS principle)
– Occam’s Razor: choose simplest among many solutions!
• complicated design increases system coupling (interdependence), amplifies errors, ..
• don’t over-optimize!
• Separating policies from mechanisms
– decouple control from data
– “semantics-free”
• Design for scale
– hierarchy, aggregation, …
CSci5221:
Internet Design
2
Network Architecture
What is (Network) Architecture?
– not the implementation itself
– “design blueprint” on how to “organize” implementations
• what interfaces are supported
• where functionality is implemented
• Two Basic Architectural Principles
– Modularity (e.g., layering)
• how to break network functionality into modules
– End-to-End Argument
• where to implement functionality
CSci5221:
Internet Design
3
Some Design/Implementation Principles
•
•
•
•
•
•
•
•
virtualization
indirection
soft state vs. hard state
fate sharing
randomization
expose faults, don’t suppress/ignore
caching
……
CSci5221:
Internet Design
4
Original Internet Design Goals
[Clark’88]
In order of importance:
0
1.
2.
3.
4.
5.
6.
Connect existing networks
– initially ARPANET and ARPA packet radio network
Survivability
- ensure communication service even with network and router
failures
Support multiple types of services
Must accommodate a variety of networks
Allow distributed management
Allow host attachment with a low level of effort
Be cost effective
7. Allow resource accountability
CSci5221:
Internet Design
5
Priorities
• The effects of the order of items in that list are
still felt today
– E.g., resource accounting is a hard, current research
topic
• Different ordering of priorities would make a
different architecture!
• How well has today’s Internet satisfied these
goals?
• Let’s look at them in detail
CSci5221:
Internet Design
6
0. Connecting Existing Networks
1974: multiple unconnected networks
–
–
–
–
ARPAnet
data-over-cable networks
packet satellite network (Aloha)
packet radio network
–
–
–
–
–
addressing conventions (i.e., address formats)
packet formats and packet sizes
Performance: bandwidth, latency, loss rate, …
error recovery mechanisms
routing
.. differing in:
• How to inter-network various (heterogeneous) network
technologies?
CSci5221:
Internet Design
7
Cerf & Kahn: Interconnecting Two Networks
ARPAnet
•
•
•
•
satellite net
“…interconnection must preserve intact the internal operation of each network.”
“ ..the interface between networks must play a central role in the development of
any network interconnection strategy. We give a special name to this interface
that performs these functions and call it a GATEWAY.”
“.. prefer that the interface be as simple and reliable as possible, and deal
primarily with passing data between networks that use different packet-switching
strategies
“…address formats is a problem between networks because the local network
addresses of TCP's may vary substantially in format and size. A uniform
internetwork TCP address space, understood by each GATEWAY and TCP, is
essential to routing and delivery of internetwork packets.”
CSci5221:
Internet Design
8
Design Alternatives
• Through translation/mapping:
– Map one address format to another: nxn mappings
– Difficulty in dealing with different features supported by
networks
– Scales poorly with # of network types, addition of new types
• Virtualization:
– Provide one common format overlaid on top of “lower-level”
addresses
– Map lower level addresses to common format: nx1 and 1xn
mappings
• role of ARP, encapsulation/decapsulation
– Layering necessary
• but what info from “lower layer” (underlying “physical”
networks) to hide, and what to expose!
CSci5221:
Internet Design
9
Gateway Alternative
• Translation
– Difficulty in dealing with different features supported
by networks
– Scales poorly with number of network types (N^2
conversions)
• Standardization/Virtualization
– “IP over everything”
– Minimal assumptions about network
– Hourglass design
CSci5221:
Internet Design
10
Design of Original Internet via Gateways
(cf. Cerf and Kahn)
Internetwork layer:
• addressing: internetwork
appears as a single, uniform
entity, despite underlying local
network heterogeneity
• network of networks
Gateway:
• “embed internetwork packets in
local packet format or extract
them”
• route (at internetwork level) to
next gateway
gateway
ARPAnet
CSci5221:
Internet Design
satellite net
11
Historical Aside:
Proposed Internetwork packet in 1974:
local source dest.
byte
seq. #
header address address
count
network
TCP
identifier
8
16
CSci5221:
Internet Design
flag
field
text
checksum
12
Cerf & Kahn’s Internetwork
Architecture
What is virtualized?
• two layers of addressing: internetwork
and local network
• new layer makes everything homogeneous
at internetwork layer
• underlying local network technology (cable,
satellite, 56K modem) is “invisible” at
internetwork layer
CSci5221:
Internet Design
13
1. Survivability
1. As long as the network is not partitioned, two
endpoints should be able to communicate
2. Failures (excepting network partition) should not
interfere with endpoint semantics (why?)
• Maintain state only at end-points
–
–
•
•
Fate-sharing, eliminates network state restoration
stateless network architecture (no per-flow state)
Routing state is held by network (why?)
No failure information is given to end-points
CSci5221:
Internet Design
14
Survivability (cont’d)
• If network disrupted and reconfigured:
– Communicating entities (“end systems”) should not care!
– No higher-level state reconfiguration
• How to achieve such reliability?
– Where can communication state be stored?
Network
Host
Failure handling
Replication
“Fate sharing”
Switches
Maintain only
routing state;
otherwise
“stateless”
Maintain perflow/per-connection
state
Host trust
Less
More
CSci5221:
Internet Design
15
Fate Sharing
Connection
State
No State
State
• Lose connection state information for an
entity if (and only if?) the entity itself is
lost
• Examples:
– OK to lose TCP state if one endpoint crashes
• NOT okay to lose if an intermediate router reboots
– Is this still true in today’s network?
• NATs, firewalls and other middle-boxes
CSci5221:
Internet Design
16
Soft-State
• Basic behavior
– Announce state
– Refresh state
– Timeout state
• Penalty for timeout – poor performance
• Robust way to identify communication
flows
– Possible mechanism to provide non-best effort service?
• Helps survivability
CSci5221:
Internet Design
17
End-to-End Argument
• Deals with where to place functionality
– Inside the network (in switching elements) ?
– At the edges (end-points) ?
• Argument:
– There are functions that can only be correctly
implemented by the endpoints – do not try to completely
implement these elsewhere
CSci5221:
Internet Design
18
Discussion
• Is there any need to implement reliability
at lower layers?
• Yes, but only to improve performance
• If network is highly unreliable
– Adding some level of reliability helps performance, not
correctness
– Don’t try to achieve perfect reliability!
– Implementing a functionality at a lower level should have
minimum performance impact on the applications that do
not use the functionality
CSci5221:
Internet Design
19
Design Challenges and Trade-offs
• Install functions in network that aid application
performance….
• …without limiting the application flexibility of the
network
• Trade-offs:
– application has more information about the data and semantics
of required service (e.g., can check only at the end of each data
unit)
– lower layer has more information about constraints in data
transmission (e.g., packet size, error rate)
• Note: these trade-offs are a direct result of
layering!
CSci5221:
Internet Design
20
Do These Belong in the Network?
•
•
•
•
Multicast?
Routing?
Quality of Service (QoS)?
Name resolution? (is DNS “in the
network”?)
• Web or media caches?
CSci5221:
Internet Design
21
2. Types of Service
•
•
•
•
Best effort delivery
All packets are treated the same
Relatively simple core network elements
Building block from which other services (such as
reliable data stream) can be built
• Contributes to scalability of network
• No QoS support assumed from below
– Accommodates more networks
– Hard to implement without network support
– QoS is an ongoing debate…
CSci5221:
Internet Design
22
Types of Service (cont’d)
• TCP vs. UDP
–
–
–
–
Elastic apps that need reliability: remote login or email
Inelastic, loss-tolerant apps: real-time voice or video
Others in between, or with stronger requirements
Biggest cause of delay variation: reliable delivery
• Today’s net: ~100ms RTT
• Reliable delivery can add seconds.
• Original Internet model: “TCP/IP” one layer
– First app was remote login…
– But then came debugging, voice, etc.
– These differences caused the layer split, added UDP
CSci5221:
Internet Design
23
3. Varieties of Networks
• Minimum set of assumptions for underlying net
– Minimum packet size
– Reasonable delivery odds, but not 100%
– Some form of addressing unless point to point
• Important non-assumptions:
–
–
–
–
Perfect reliability
Broadcast, multicast
Priority handling of traffic
Internal knowledge of delays, speeds, failures, etc.
• Much engineering then only has to be done once
CSci5221:
Internet Design
24
The “Other” goals
• 4. Management
– Each network owned and managed separately
– Will see this in BGP routing especially
• 5. Attaching a host
– Not awful; DHCP and related autoconfiguration
technologies helping.
• 6. Cost effectiveness
– Economies of scale won out
– Internet cheaper than most dedicated networks
– Packet overhead less important by the year
• But…
CSci5221:
Internet Design
25
7. Accountability
• Huge problem!
• Accounting
– Billing? (mostly flat-rate. But phones are moving that
way too - people like it!)
– Inter-provider payments
• Hornet’s nest. Complicated. Political. Hard.
• Accountability and security
– Huge problem!
– Worms, viruses, etc.
• Partly a host problem. But hosts very trusted.
– Authentication
• Purely optional. Many philosophical issues of privacy
vs. security.
– Greedy sources aren’t handled well
CSci5221:
Internet Design
26
Other IP Design Weaknesses
• Weak administration and management tools
• Incremental deployment difficult at times
– Result of no centralized control
– No more “flag” days
– Are active networks the solution?
CSci5221:
Internet Design
27
Internet Motto
We reject kings , presidents, and voting. We
believe in rough consensus and running
code.”
David Clark
CSci5221:
Internet Design
28
Real Goals
1.
2.
3.
4.
5.
6.
7.
8.
9.
Something that works…..
Connect existing networks
Survivability (not nuclear war…)
Support multiple types of services
Accommodate a variety of networks
Allow distributed management
Easy host attachment
Cost effective
Allow resource accountability
CSci5221:
Internet Design
29
Summary: Internet
Architecture
• Packet-switched
datagram network
• IP is the “compatibility
layer”
– Hourglass architecture
– All hosts and routers run IP
• Stateless architecture
– No per flow state inside
network
CSci5221:
Internet Design
TCP
UDP
IP
Ethernet
Cellular
WiFi
30
Summary: Minimalist Approach
• Dumb network
– IP provide minimal functionalities to support connectivity
• Addressing, forwarding, routing
• Smart end system
– Transport layer or application performs more
sophisticated functionalities
• Flow control, error control, congestion control
• Advantages
– Accommodate heterogeneous technologies (Ethernet,
modem, satellite, wireless)
– Support diverse applications (telnet, ftp, Web, X
windows)
– Decentralized network administration
• Beginning to show age
– Unclear what the solution will be  probably IPv6?
CSci5221:
Internet Design
31
Questions
• What priority order would a commercial
design have?
• What would a commercially invented
Internet look like?
• What goals are missing from this list?
• Which goals led to the success of the
Internet?
CSci5221:
Internet Design
32
Requirements for Today’s Internet
Some key requirements (“-ities”)
• Availability and reliability
– “Always on”, fault-tolerant, fast recovery from failures, …
• Quality-of-service (QoS) for applications
– fast response time, adequate quality for VoIP, IPTV, etc.
• Scalability
– millions or more of users, devices, …
• Mobility
– untethered access, mobile users, devices, …
• Security (and Privacy?)
– protect against malicious attacks, accountability of user actions?
• Manageability
– configure, operate and manage networks
– trouble-shooting network problems
• Flexibility, Extensibility, Evolvability, ……?
– ease of new service creation and deployment?
– evolvable to meet future needs?
CSci5221:
Internet Design
33