Outline for this lecture

1. Outline for this lecture • Design Philosophy of Internet Protocols • “End to end” argument

2. 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.

3. 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

4. Design Philosophy of TCP/IP • Network characteristics • Prioritized design goals • Architecture and implementation

5. Network Characteristics • Network heterogeneity: varieties of networks • Diverse application requirements: throughput, delay, loss, etc. • Large number of subnetworks, nodes • Decentralized management and control

6. 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

7. 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

8. 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

9. 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

10. 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

11. Cost-effectiveness • Header contributes overhead • Small packets • Recovery from lost packets: • End-to-end retransmissions • Not link-by-link retransmissions

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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”

28. 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

29. 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

30. 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

31. 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

32. 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)

33. 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)

34. 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