CS219/Fall 2002 10/02
Outline for this lecture
• Design Philosophy of Internet Protocols
• “End to end” argument
CS219/Fall 2002 10/02
Architectural Principles of the Internet: RFC 1958 & Clark’s Paper• Internet has grown by factors of 1000 (backbone
speed) to 10^6 (# of hosts) in 1996.• The principle of constant change is perhaps the
only principle of the Internet• The purpose is to find guidelines that had been
useful in the past: a small “spanning set” of rules• Reflects our current understanding of the Internet:
avoid statements like “Heavier-than-air flying machines are impossible” by Lord Kelvin in 1895
• If there are several ways of doing the same thing, choose the previous design unless you have a very good reason not to.
CS219/Fall 2002 10/02
Is there an Internet Architecture?• Architecture or tradition? The
community believes:– The goal is connectivity– The tool is the IP protocol– The intelligence is end to end rather
than hidden in the network• Revolution versus evolution for
Internet technology
CS219/Fall 2002 10/02
Design Philosophy of TCP/IP
• Network characteristics• Prioritized design goals• Architecture and implementation
CS219/Fall 2002 10/02
Network Characteristics• Network heterogeneity: varieties of
networks• Diverse application requirements:
throughput, delay, loss, etc.• Large number of subnetworks,
nodes• Decentralized management and
control
CS219/Fall 2002 10/02
Prioritized Design GoalsEffectiveness is more important than efficiency:• Connectivity: interconnection of distinguishable
networks• Robustness and survivability: communication
continues in the presence of various degree of failures
• Flexible service: meet diverse application requirements
• Distributed management• Cost effectiveness• Ease for Plug-in: Easy to attach for new hosts• Accounting issue
CS219/Fall 2002 10/02
Fundamental Goal• Multiplexed utilization of existing
interconnected networks– “Network of networks” or “multi-media
network:” Multiplexing versus integrating/unifying
– Packet switching versus circuit switching: bursty traffic versus regular traffic
– Store and forward packet forwarding– Internet level protocol must be independent of
the hardware medium and hardware addressing
CS219/Fall 2002 10/02
Robust Connectivity: how IP achieves
• Issues and solutions in IP– Heterogeneous networks: IP address and IP
router– Node and network failures:
• “connectionless” within the network: no connection state management for IP routers
• Fate-sharing with end hosts• ICMP error report messages
– Scalability: no per-connection/group state within the network, push such states to the edge (end hosts) of the network
CS219/Fall 2002 10/02
Flexible Service• Built on top of basic IP best-effort
service• Discard the approach of unified
transport service design:– UDP, TCP, RTP, … …
• Remember: no performance assurances
CS219/Fall 2002 10/02
Decentralized control• No centralized management• Two-tier routing: inter-domain,
intra-domain• Each domain can specify its own
routing policies/preferences• Exchanging routing table
information among border gateways
CS219/Fall 2002 10/02
Cost-effectiveness• Header contributes overhead
– Small packets• Recovery from lost packets:
– End-to-end retransmissions– Not link-by-link retransmissions
CS219/Fall 2002 10/02
Architecture and implementation• Packet-switching system that allows for
different realizations• Live with failures: Not to prevent failures
but how to react to them properly• How to evaluate your design
– Prototyping– Simulation– Compatiability issue: incremental
deployment
CS219/Fall 2002 10/02
A Few More Guidelines• Heterogeneity is inevitable and must be
supported by design– Hardware; application protocols
• Duplication of the same protocol functionality should be avoided as far as possible
• All designs must scale• Keep the solution simple: choose the
simplest solution if possible• Modularity is good.• Do not wait until a perfect solution is found
CS219/Fall 2002 10/02
More guidelines• Avoid options and parameters whenever
possible. They should be configured/negotiated dynamically rather than manually
• Be strict when sending, and tolerant when receiving. You may silently drop faulty input when in doubt without returning an error message.
• Be parsimonious with unsolicited (multicast or broadcast) packets
• Circular dependencies must be avoided
CS219/Fall 2002 10/02
Name and Address Issues• Avoid any design that requires addresses to
be hard coded or stored on non-volatile storage
• User applications should use names rather than addresses in general
• A single naming structure is used• Public names (e.g. DNS names) are in case-
independent ASCII.• Addresses must be unambiguous• Upper layer protocols must be able to
identify end-points unambiguously
CS219/Fall 2002 10/02
Confidentiality and Authentication• All designs must fit into the IP security
architecture ??• Authentication and confidentiality are the
responsibility of end users, not the network
• Security protocols should allow different cryptographic algorithms.
• Choose a well-known/studied cryptographic algorithm, do NOT invent a new one unless no existing one works
CS219/Fall 2002 10/02
Implementations• Objects should be self describing (including
type and size). Other type codes and magic numbers assigned by IANA may be used.
• Any implementation which does not include all of the required components cannot claim conformance with the standard
• Designs must be international, with support for localization
• Prefer unpatented technology
CS219/Fall 2002 10/02
End-to-end arguments in system design
Problem statement: given the freedom to implement a few functionalities in multiple “places” of the system (physical devices, or layers of protocols), where to implement them?
Goal: correctness, completeness, and performance tradeoff
Approach: end-to-end arguments
CS219/Fall 2002 10/02
What is end-to-end argument?• System: application, communication
subsystem and the rest• End-to-end:
– the function can completely and correctly be implemented ONLY with the knowledge and help of the application standing at the endpoints of the communication system.
– Providing the function as a feature of the communication system is not feasible
– appeals to application requirement– Move a function upward in a layered system
closer to the application that uses the function
CS219/Fall 2002 10/02
Example: file transfer• Problem: transfer a file from host A
to B• Steps:
– At A, file system reads and passes the file to ftp
– At A, ftp passes it to data comm. System
– Packets of the file are transferred from A to B
– At B, ftp retrieves the file– At B, file system writes the data to
the disk
CS219/Fall 2002 10/02
Example (continued)• Threats:
– Read error from the disk at A– Software errors in buffering and
copying data by file system, ftp, or network, at A or B
– Hardware errors at A or B– Transfer error in the network part– Host crashes at A or B
CS219/Fall 2002 10/02
Approach to handle threats• Approach 1: reinforce EVERY step
– Using duplicate copies, timeout and retry, error detection, crash recovery, etc.
– Maybe Not feasible– Uneconomical
• Approach 2: end-to-end check and retry– Implement “end-to-end” error
checking at Steps 1 and 5– Retry if checking fails
CS219/Fall 2002 10/02
end-to-end approach in the example• Guarantee correctness and
completeness of reliable file transfer
• Reliability is the composite effects of all the components
• Reliability in the network alone is not sufficient for end-to-end reliability
• Application requirement is the key• Works if the error is not frequent
CS219/Fall 2002 10/02
End-to-end versus low-layer implementation• Correctness and completeness
– Provided by end-to-end– Not by lower-layer implementations– Conclusion: end-to-end is a must
• Performance perspective– End-to-end may suffer without lower-layer
collaboration– Placing functions in lower layer is justified
only if performance benefits outweighs the cost of additional complexity at the lower layer.
• Redundancy perspective
CS219/Fall 2002 10/02
When to use the end-to-end approach• A functionality should be pushed to
higher layers if possible, motivated by– Correctness and completeness– Reduced redundancy– Incremental deployment– More flexibility exposed to applications
• Unless implementing it at lower layers can achieve large performance gains that outweigh the cost of additional complexity at lower layers
CS219/Fall 2002 10/02
More discussions and examples• End-to-end versus hop-by-hop reliability• Multicast: IP versus end-system
– Case against IP multicast• Stateful multicast architecture: Requires IP
routers to maintain group state• Vulnerable to flooding attack• Multicast address is needed for each group• Calls for infrastructure-level changes• Slow deployment• Implementing multicast congestion control at
higher layers?– Case against end-system multicast
• Performance penalty
CS219/Fall 2002 10/02
Another example: security• Security in a networking system• Bruce Schneier wrote in “Secrets and
Lies: Digital security in a networked world” (John Wiley & Sons, Inc; 2000)– Cryptography is not the Answer.– Cryptography is not sufficient from the
system perspective– “Security is a chain; it is only as secure as
the weakest link”– “Security is a process, not a product”
CS219/Fall 2002 10/02
What has changed since then?• Operations in an untrustworthy world
– Untrusted end-points (imply more mechanisms in the core to enforce good behaviors)
• More demanding applications– e.g., streaming media (intermediate
servers)• ISP service differentiation• The rise of third-party involvement• Less sophisticated users
CS219/Fall 2002 10/02
New Requirements• Security-related
– Users communicate but do not totally trust each other
– Anonymity in communications– End parties do not trust their
software/hardware• The ends vs the middle
– Third party involvement• Multiway communication• One party tries to force interaction on
another
CS219/Fall 2002 10/02
Different forms of e2e arguments• network side
– Avoid putting application-specific functions in the network
– Push application-specific functions up and out to the edges
• Application side– Decide where application-level
services should be attached
CS219/Fall 2002 10/02
Network side: Modify the end-node• Placement of function at the edge
may – compromise performance, but the
functional objective is met– Represent an imperfect but
acceptable solution– Not solve the problem
CS219/Fall 2002 10/02
Network side: the network core• Add functions to the network core
– Enable more functionalities and applications– Prevent certain malicious applications
• Design issues– Imposing a control element into the path of
communication (e.g. by using the topology information/characteristics)
– Revealing or hiding the message content (e.g. by using labels on information/keyword)
CS219/Fall 2002 10/02
Application side• Insert servers into the data path of
an application– mail servers, anonymous message
forwarders (e.g. nym)• Use of additional components
away from the e2e design– Using trusted third party (e.g. via
public key certificate)
CS219/Fall 2002 10/02
Some examples in wireless• Wireless proxy (I.e.,
transcoding,web)– Handle end devices with different
capabilities– Different client requirements – No change on the application server– Main complexity on the proxy
• Wireless security• Reliability over the wireless link