CS219/Fall 2002 10/02 Outline for this lecture Design Philosophy of Internet Protocols “End to end” argument.

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 Goals

Effectiveness 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