Review of Networking and Design Concepts (II): Architecture & Evolution

1. Review of Networking and Design Concepts (II): Architecture & Evolution • Two ways of constructing a software design: • make it so simple that there are obviously no deficiencies, and • make it so complicated that there are no obvious deficiencies • --- C.A.R. Hoare

2. Overview • Protocols, layering, encapsulation • Interface design: functionality, technology, performance • System design: technological building blocks, Amdahl’s law, exponential trends • Function-placement: End-to-end principle • Implementation: App-layer framing, ILF, cross-layer design • New directions: middleboxes, tussle, layered naming, overlays • Chap 1-6 (Kurose book),Chapter 1,2,3, 10 in Doug Comer book • Reading: Saltzer, Reed, Clark:"End-to-End arguments in System Design" • Reading: Clark: "The Design Philosophy of the DARPA Internet Protocols": • Reading: RFC 2775: Internet Transparency: In HTML • Reference: Clark et al, "Tussle in Cyberspace: Defining Tomorrow's Internet" • Reading:Balakrishnan et al: "A Layered Naming Architecture for the Internet":

3. Part I: Architectural Concepts, Guidelines

4. HTTP Packet radio Why Layering? (FTP – File Transfer Protocol, NFS – Network File Transfer, HTTP – World Wide Web protocol) • No layering: each new application has to be re-implemented for every network technology! • Capture common functions in intermediate layer. • Convert O(N^2) mapping problem to O(N) FTP NFS Telnet Application Coaxial cable Fiber optic Transmission Media

5. HTTP Packet radio Why Layering? • Solution: introduce an intermediate layer that provides a unique abstraction for various network technologies FTP NFS Telnet Application Intermediate layer Coaxial cable Fiber optic Transmission Media

6. What is Layering? • A technique to organize a network system into a succession of logically distinct entities, such that the service provided by one entity is solely based on the service provided by the previous (lower level) entity

7. Layering • Advantages • Modularity – protocols easier to manage and maintain • Abstract functionality –lower layers can be changed without affecting the upper layers • Reuse – upper layers can reuse the functionality provided by lower layers • Disadvantages • Information hiding – inefficient implementations; • Invariant APIs (interfaces) => may not leverage new capabilities available at lower layers

8. Layered Protocols • Building blocks of a network architecture • Each protocol object has two different interfaces • service interface: defines operations on this protocol • peer-to-peer interface: defines messages exchanged with peer Li+1 Li+1 service interface Li Li peer interface

9. network link physical application transport network link physical application transport network link physical application transport network link physical application transport network link physical data data data ack Example: Transport Protocol(Logical Communication) • take data from app • add addressing, reliability check info to form “datagram” • send datagram to peer • wait for peer to ack receipt • analogy: post office transport transport (Source: Kurose & Ross)

10. Encapsulation • A layer can use only the service provided by the layer immediate below it • Each layer may change and add a header to data packet data data data data data data data data data data data data data data

11. network link physical application transport network link physical application transport network link physical application transport network link physical application transport network link physical data data Example: Transport Protocol(Physical Communication) (Source: Kurose & Ross)

12. Telnet FTP DNS TCP UDP IP Packet radio LAN OSI vs. TCP/IP • OSI: conceptually define services, interfaces, protocols • Internet: provide a successful implementation Application Application Presentation Session Transport Transport Network Internet Datalink Host-to- network Physical OSI TCP

13. Interface Design • Driven by three factors: • Functionality: what features the customer wants, and is placed at a level due to e2e principle etc • Technology: what’s possible. Building blocks and techniques. Improvement trends in technology. • Performance: How fast etc… User, Designer, Operator views of performance .. • Interface design crucial because interface outlives the technologyused to implement the interface.

14. Perspectives on Interface Design • Network users: services and performance that their applications need, • Network designers:cost-effective design • Network providers: system that is easy to administer and manage • Need to balance these three needs

15. System Design Tradeoff (waste) cheap resources … and … optimizeexpensive resources [to achieve a given functionality]

16. Performance • Performance questions: • Absolute: How fast … • Relative: Is A faster than B and how much faster? • Define system as a black box. • Parameters: input; Metrics: output • Parameters: only those the system is sensitive to • Metrics: must reflect the system design tradeoff System Parameters Metrics

17. What’s a performance tradeoff ? • You cannot get something for nothing! • Also known as a zero-sum game or no-free-lunch. • Example moving from circuit-switching to packet switching • => tradeoff delay, buffer space, packet loss, e2e complexity to optimize on capacity utilization and provisioning gains ($$) (But…) Technology can reduce costs of components by leveraging fundamental laws of physics, manufacturing economies of scale etc (Moore’s law)

18. Impact of Technology Trends: What is expensive today may become cheap tomorrow. DWDM Link speed x2/8 months Internet x2/yr Huge mismatches in technology trends (eg: DWDM vs DRAM) must be planned for in modular designs! Router capacity x2.2/18 months Moore’s law x2/18 m DRAM access rate x1.1/18 m

19. Amdahl’s Law • http://en.wikipedia.org/wiki/Amdahl's_law • Guides the iterative design process. • If design implies a set of tradeoffs, the question is how to redesign components so that the system cost-performance (in terms of expensive resources) is improved. • Amdahl’s law talks about the maximum expected improvement to an overall system when only a part of the system is improved. • Statement of “diminishing returns” when the focus is on improving only a single component • System Speedup =

20. Amdahl’s Law (contd) • If a part of a system accounts for 12% of performance (P = 0.12) and • You speed it up 100-fold (S = 100) • The actual system speedup is only: 13.6% !!!! • Lesson #1: Optimize the common cases (accounting for a large fraction of system performance) • Lesson #2: Bottlenecks shift! If you optimize one component, another will become the new bottleneck!

21. Key questions in architecture • How to decompose the complex system functionality into protocol layers? • What functions to be placed at which levels? • Can a function be placed at multiple levels ?

22. Common View of the Telco Network Brick

23. Common View of the IP Network

24. End-to-End Argument • “…functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the lower level…” • “…sometimes an incomplete version of the function provided by the communication system (lower levels) may be useful as a performance enhancement…” • This leads to a philosophy diametrically opposite to the telephone world which sports dumb end-systems (the telephone) and intelligent networks.

25. OK Example: Reliable File Transfer Host A Host B • Solution 1: make each step reliable, and then concatenate them • Solution 2: end-to-end check and retry Appl. Appl. OS OS

26. Discussion • Solution 1 not complete • What happens if the sender or/and receiver misbehave? • The receiver has to do the check anyway! • Thus, full functionality can be entirely implemented at application layer; no need for reliability from lower layers • Is there any need to implement reliability at lower layers?

27. Discussion • Yes, but only to improve performance • Example: • assume a high error rate on communication network • then, a reliable communication service at datalink layer might help

28. Trade-offs • Application has more information about the data and the semantic of the service it requires (e.g., can check only at the end of each data unit) • A 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!

29. Internet & End-to-End Argument • At network layer provides one simple service: best effort datagram (packet) delivery • Only one higher level service implemented at transport layer: reliable data delivery (TCP) • performance enhancement; used by a large variety of applications (Telnet, FTP, HTTP) • does not impact other applications (can use UDP) • Everything else implemented at application level

30. Key Advantages • The IP service can be implemented on top of a large variety of network technologies • Does not require routers to maintain any fined grained state about traffic. Thus, network architecture is • Robust • Scalable

31. What is a “level” of a system? • Protocol “layer” = “level” • Within a single layer, closer to the core => “lower” level • Eg: Edge-boxes of a domain implementing functions like firewalls, address translation, QoS functions are at a “lower” level compared to other boxes in the domain • Core router is “lower” level compared to an “edge router” • In hierarchical routing, use of smaller prefixes correspond to lower levels of the system.

32. E2E Argument: Interpretations • One interpretation: (limited in my opinion…) • A function can only be completely and correctly implemented with the knowledge and help of the applications standing at the communication endpoints • Another: (more precise…) • a system (or subsystem level) should consider only functions that can be completely and correctlyimplemented within it. • Alternative interpretation: (also correct …) • Think twice before implementing a functionality that you believe that is useful to an application at a lower layer • If the application can implement a functionality correctly, implement it a lower layer only as a performance enhancement

33. End-to-End Argument: Critical Issues • The end-to-end principle emphasizes: • function placement • correctness • completeness and • overall system costs. • It allows a cost-performance tradeoff • If implementation of function in higher levels is not possible due to technological/economic reasons (eg: telephone network in early 1900s), then it may be placed at lower levels

34. Summary: End-to-End Arguments • If the application can do it, don’t do it at a lower layer -- anyway the application knows the best what it needs • add functionality in lower layers if it is (1) used and improves performance of a large number of applications, and (2) does not hurt other applications • Success story: Internet

35. Architecture vs Implementation: ALF Principle • Architecture: decomposition into functional modules, semantics of modules and syntax used • There should be no a priori requirement that the engineering design of a given system correspond to the architectural decomposition • Eg: layering may not be most effective modularity for implementation • Summary: • Flexible decomposition • Defer engineering decisions to implementer. • Avoid gratuitous implementation constraints • Maximize engineering options for customization/optimization

36. Application Layer Framing (ALF) • Several processing bottlenecks may lie at the “presentation” layer which does not really exist in the TCP/IP stack • These functions are absorbed partially in the transport layer and partly in the application layer. • Principle: the application-layer should have control of the syntax and semantics of the presentation conversions • Transport should provide only common functions • Generalization of ALF: look for elegant ways to allow application visibility/participation in lower-level activities • Eg: QoS – carry application intelligence to the point of QoS enforcement

37. Eg: Real-Time Protocol • RTP svcs: payload type identification, sequence numbering, timestamping and delivery monitoring • “RTP is intended to be malleable to provide the information required by a particular application and will often be integrated into the application processing rather than being implemented as a separate layer.” • RTP is a protocol framework that is deliberately not complete and can be tailored modifications/additions to the headers. • RTP specifies only common functions for its apps • Avoid taking on additional functions • making the protocol more general or • Adding options requiring expensive parsing

38. Cross-Layer Design: Motivation Efficiency & performance imperatives, with strict limits on raw spectrum resource (no Moore’s law!)

39. LOCAL AREA PACKET SWITCHING WIDE AREA CIRCUIT SWITCHING ATM ATM 100 M 100,000 100,000 Ethernet 10,000 10,000 FDDI wired- wireless bit-rate "gap" Ethernet wired- wireless User User 1000 1000 bit-rate "gap" ISDN Bit-Rate Bit-Rate 2nd gen WLAN (kbps) (kbps) 100 100 28.8 modem 1st gen WLAN 32 kbps Polling 9.6 modem PCS 14.4 digital cellular 10 10 9.6 cellular 2.4 modem Packet 2.4 cellular 1 1 Radio .1 .1 .01 .01 1970 1980 1990 2000 1970 1980 1990 2000 YEAR YEAR Wireless Performance Gap Efficiency & performance imperatives, with strict limits on raw spectrum resource (no Moore’s law!)

40. Cross-layer Design For Wireless • Application • Network • Access • Link • Hardware Delay Constraints Rate Constraints Energy Constraints Adapt across design layers Reduce uncertainty through scheduling Provide robustness via diversity

41. Cross-layer Techniques: Examples • Adaptive techniques • Link, MAC, network, and application adaptation • Resource management and allocation (power control) • Diversity techniques • Link diversity (antennas, channels, etc.) • Access diversity • Route diversity • Application diversity • Content location/server diversity • Scheduling • Application scheduling/data prioritization • Resource reservation • Access scheduling

42. A Cautionary Perspective • Cross-layer design can limit the rate of architectural evolution • Moore’s law like efficiency benefits cant be easily incorporated by multiple enterprises at different layers • Open problem: how to retain architectural flexibility, long-run contributions by multiple vendors, while meeting the short-run performance imperatives ? • Maintain modularity and layering, but permit: • ALF-like flexible customization and • Information-sharing/statistical learning across layers to facilitate multi-layer optimizations. • Flexible header structures (floating headers) for inter-layer information sharing