1. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 Review of Networking and Design Concepts (II): Architecture & Evolution Two ways of constructing a software design: 1)make it so simple that there are obviously no deficiencies, and 2)make it so complicated that there are no obvious deficiencies --- CAR Hoare Based in part upon slides of Prof. Raj Jain (OSU), J. Kurose (U Mass), I. Stoica, S. Shenker, A.Joseph (UCB)

2. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2 q Protocols, layering, encapsulation q Interface design: functionality, technology, performance q System design: technological building blocks, amdahl’s law, exponential trends q Function-placement: End-to-end principle q Implementation: App-layer framing, ILF, cross-layer design q New directions: middleboxes, tussle, layered naming, overlays q Chapter 1,2,3, 10 in Doug Comer book q Reference NOTES: Network Architecture: Principles and Guidelines q Other SUGGESTED readings (not necessary): see webpage for full list q Reading: Saltzer, Reed, Clark: "End-to-End arguments in System Design""End-to-End arguments in System Design" q Reading: Clark: "The Design Philosophy of the DARPA Internet Protocols":"The Design Philosophy of the DARPA Internet Protocols": q Reading: RFC 2775: Internet Transparency: In HTMLIn HTML q Reference: Clark et al, "Tussle in Cyberspace: Defining Tomorrow's Internet""Tussle in Cyberspace: Defining Tomorrow's Internet" q Reading: Balakrishnan et al: "A Layered Naming Architecture for the Internet":"A Layered Naming Architecture for the Internet": Overview

3. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3 Part I: Architectural Concepts, Guidelines Note: Part II: To be covered later in the course (TBD) Reference NOTES: Network Architecture: Principles and Guidelines

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

5. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5 Why Layering? q Solution: introduce an intermediate layer that provides a unique abstraction for various network technologies Telnet FTPNFS Packet radio Coaxial cable Fiber optic Application Transmission Media HTTP Intermediate layer

6. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6 What is Layering? q 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. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7 Layering q Advantages q Modularity – protocols easier to manage and maintain q Abstract functionality –lower layers can be changed without affecting the upper layers q Reuse – upper layers can reuse the functionality provided by lower layers q Disadvantages q Information hiding – inefficient implementations; q Invariant APIs (interfaces) => may not leverage new capabilities available at lower layers

8. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8 Layered Protocols q Building blocks of a network architecture q Each protocol object has two different interfaces q service interface: defines operations on this protocol q peer-to-peer interface: defines messages exchanged with peer service interface peer interface L i+1 LiLi LiLi

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

10. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10 Encapsulation q A layer can use only the service provided by the layer immediate below it q Each layer may change and add a header to data packet data

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

12. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12 OSI vs. TCP/IP q OSI: conceptually define services, interfaces, protocols q Internet: provide a successful implementation Application Presentation Session Transport Network Datalink Physical Internet Host-to- network Transport Application IP LAN Packet radio TCPUDP TelnetFTPDNS OSITCP

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

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

15. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15 System Design Tradeoff (waste) cheap resources … and … optimize expensive resources [to achieve a given functionality]

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

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

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

19. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 19 Amdahl’s Law q http://en.wikipedia.org/wiki/Amdahl's_law http://en.wikipedia.org/wiki/Amdahl's_law q Guides the iterative design process. q 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. q Amdahl’s law talks about the maximum expected improvement to an overall system when only a part of the system is improved. q Statement of “diminishing returns” when the focus is on improving only a single component q System Speedup =

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

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

22. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 22 Common View of the Telco Network Brick

23. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 23 Common View of the IP Network

24. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 24 End-to-End Argument q “…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…” q “…sometimes an incomplete version of the function provided by the communication system (lower levels) may be useful as a performance enhancement…” q This leads to a philosophy diametrically opposite to the telephone world which sports dumb end- systems (the telephone) and intelligent networks.

25. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 25 Example: Reliable File Transfer q Solution 1: make each step reliable, and then concatenate them q Solution 2: end-to-end check and retry OS Appl. OS Appl. Host AHost B OK

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

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

28. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 28 Trade-offs q 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) q A lower layer has more information about constraints in data transmission (e.g., packet size, error rate) q Note: these trade-offs are a direct result of layering!

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

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

31. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 31 What is a “level” of a system? q Protocol “layer” = “level” q Within a single layer, closer to the core => “lower” level q 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 q Core router is “lower” level compared to an “edge router” q In hierarchical routing, use of smaller prefixes correspond to lower levels of the system.

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

33. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 33 End-to-End Argument: Critical Issues q The end-to-end principle emphasizes: q function placement q correctness q completeness and q overall system costs. q It allows a cost-performance tradeoff q 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. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 34 Summary: End-to-End Arguments q If the application can do it, don’t do it at a lower layer -- anyway the application knows the best what it needs q add functionality in lower layers iff it is q (1) used and improves performance of a large number of applications, and q (2) does not hurt other applications q Success story: Internet

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

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

37. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 37 Eg: Real-Time Protocol q RTP svcs: payload type identification, sequence numbering, timestamping and delivery monitoring q “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.” q RTP is a protocol framework that is deliberately not complete and can be tailored modifications/additions to the headers. q RTP specifies only common functions for its apps q Avoid taking on additional functions q making the protocol more general or q Adding options requiring expensive parsing

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

39. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 39 Wireless Performance Gap Efficiency & performance imperatives, with strict limits on raw spectrum resource (no Moore’s law!)

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

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

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

43. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 43 Part II: To be covered later in the course (TBD)

44. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 44 Evolving the Internet Today: Challenges, Principles, Approaches

45. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 45 We Aren’t in Kansas Anymore... q Internet was designed in cohesive environment q Everyone had the same goals, worked together q The Internet is now fully commercial q There are many competing interests q Users no longer share same goals q Providers now compete with each other

46. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 46 Eg: Uncoop. Congestion Control q Each user’s performance is a function of bandwidth and delay/drops q Users adjust their sending rate to maximize their performance q What is the resulting equilibrium? q FIFO routers: terrible! q FQ routers: very good! (detailed game theory analysis) q Edge-based policing of uncooperative users: good, but requires estimation

47. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 47 Designing for Selfishness q Assume every user (provider) cares only about their own performance (profit) q Give each user a set of actions q Design a “mechanism” that maps action vectors into a system-wide outcome q Choose a mechanism so that user selfishness leads to socially desirable outcome q Nash equilibrium, strategy-proof, etc.

48. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 48 Tussles: Generalized Conflicts q Generalization of “conflicts”, called “tussles”. q Accept the presence of tussles and design for them q Game-theory etc, one way of resolving tussles within technical domain q Allows solution in non-technical domain, but offers guidelines for architecture to provide a platform to facilitate this. q Ideas: q Design for choice, not for outcome q Separate mechanism from policy [usual advice] q Modularize design along tussle boundaries

49. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 49 Tussle Interfaces q Make value visible: allow parties with compatible interests to reach equilibrium q Make costs visible: allow parties to make informed choices q Provide tools to isolate and resolve faults/failures

50. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 50 Eg: Layered Naming

51. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 51 Context: Architectural Discontents in Today’s Internet q Lack of features q End-to-end QoS, host control over routing, end-to-end multicast,… q Lack of protection and accountability q Denial-of-service (DoS) q Architecture is brittle

52. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 52 Architectural Brittleness q Hosts are tied to IP addresses q Mobility and multi-homing pose problems q Services are tied to hosts q A service is more than just one host: replication, migration, composition q Packets might require processing at intermediaries before reaching destination q “Middleboxes” (NATs, firewalls, …)

53. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 53 Internet Naming is Host-Centric q Two global namespaces: DNS and IP addresses q These namespaces are host-centric q IP addresses: network location of host q DNS names: domain of host q Both closely tied to an underlying structure q Motivated by host-centric applications

54. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 54 The Trouble with Host-Centric Names q Host-centric names are fragile q If a name is based on mutable properties of its referent, it is fragile q Example: If Joe’s Web page www.berkeley.edu/~hippie moves to www.wallstreetstiffs.com/~yuppie, Web links to his page break q Fragile names constrain movement q IP addresses are not stable host names q DNS URLs are not stable data names

55. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 55 Key Architectural Questions 1. Which entities should be named? 2. What should names look like? 3. What should names resolve to?

56. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 56 Idea: Name Services and Hosts Separately q Service identifiers (SIDs) are host-independent data names q End-point identifiers (EIDs) are location- independent host names q Protocols bind to names, and resolve them q Apps should use SIDs as data handles q Transport connections should bind to EIDs Binding principle: Names should bind protocols only to relevant aspects of underlying structure

57. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 57 The Naming Layers User-level descriptors (e.g., search) App session App-specific search/lookup returns SID Transport Resolves SID to EID Opens transport conns IP Resolves EID to IP Bind to EID Use SID as handle IP hdrEIDTCPSID… IP Transport App session Application

58. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 58 Resolution Service Flat Names Enable Flexible Migration <A HREF= http://f012012/pub.pdf >here is a paper <A HREF= http://f012012/pub.pdf >here is a paper HTTP GET: /docs/pub.pdf 10.1.2.3 /docs/ 20.2.4.6 HTTP GET: /~user/pubs/pub.pdf (10.1.2.3,80, /docs/) (20.2.4.6,80, /~user/pubs/) /~user/pubs/ q SID abstracts all object reachability information q Objects: any granularity (files, directories) q Benefit: Links (referrers) don’t break Domain H Domain Y

59. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 59 Virtualization as an Evolution Enabler Reading: Balakrishnan et al: "A Layered"A Layered Naming Architecture for the Internet": Reference: Stoica et al, "Internet Indirection"Internet Indirection Infrastructure", Reference: Peterson et al: "Overcoming"Overcoming the Internet Impasse through Virtualization": Reading: Tennenhouse et al, A survey ofA survey of active networks research,

60. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 60 Fundamental Assumption q The Internet’s current evolutionary path will not adequately meet our future needs q Security q Reliability q New application and user requirements q ….. q We will need a significant architectural change q Perhaps not now, but eventually

61. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 61

62. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 62

63. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 63

64. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 64 Assumptions So Far… q Researchers invent new architectures q Architectures are validated on a testbed q IETF, ISPs, and router vendors collaborate to deploy new design

65. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 65 What about Deployment? q Architectural change requires ISP consensus q Hard to agree q No competitive advantage from architectural innovation q All have huge sunk investment in the status quo q ISPs are unlikely candidates for architectural change q Too fragmented, intense competition q Architecture isn’t just static, its decaying q Ad hoc workarounds muddy the architectural waters q => Impasse!

66. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 66 The Purist Evolutionary Scenario q Periods of architectural stability followed by disruptive change to new coherent architecture q In quiescence, a pure well-defined architecture q Punctuated equilibrium q Key to evolving the architecture: q Proxy support, Overlays q Virtualization is a means q For testing and deploying new architecture

67. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 67

68. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 68 Recall: The Power of Indirection "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem.” - David Wheeler (1929-2004), chief programmer for the EDSAC project in the early 1950s. q Synonymns: Mapping, Binding, Resolution, Delegation, Translation, Referencing, Coupling, Interfacing, (dynamic or flexible) Composition, Relocation …  Just like pointers and “referencing” provides great flexibility in programming… (why?)  Indirection provides great flexibility in distributed system/protocol design!

69. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 69 Recall: Indirection is Everywhere! “foo.org” IP foo DNS Server foo.org IP foo IP foo DNS (IP home,data) Home Agent IP home IP mobile (IP mobile,data) IP mofile Mobile IP (IP nat :P nat,data) NAT Box IP nat :P nat IP dst :P dst (IP dst :P dst,data) IP dst NAT Internet (IP M  IP R1 ) (IP M  IP R2 ) (IP M,data) (IP R1,data) (IP R2,data) IP R1 IP R2 IP Multicast (IP foot,data)

70. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 70 Internet Indirection Infrastructure (i3) q Use an overlay network to implement this layer q Incrementally deployable; don’t need to change IP Build an efficient indirection layer on top of IP IP TCP/UDP Application Indir. layer

71. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 71 Internet Indirection Infrastructure (i3)  Each packet is associated an identifier id  To receive a packet with identifier id, receiver R maintains a trigger ( id, R) into the overlay network Sender idR trigger iddata Receiver (R) iddata R

72. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 72 Mobility q Host just needs to update its trigger as it moves from one subnet to another Sender Receiver (R1) Receiver (R2) idR1 idR2

73. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 73 iddata Multicast q Receivers insert triggers with same identifier q Can dynamically switch between multicast and unicast Receiver (R1) idR1 Receiver (R2) idR2 Sender R1data R2data iddata

74. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 74 Anycast q Use longest prefix matching instead of exact matching q Prefix p: anycast group identifier q Suffix s i : encode application semantics, e.g., location Sender Receiver (R1) p|s 1 R1 Receiver (R2) p|s 2 R2 p|s 3 R3 Receiver (R3) R1 data p|a data p|a data

75. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 75 Service Composition: Sender Initiated q Use a stack of IDs to encode sequence of operations to be performed on data path q Advantages q Don’t need to configure path q Load balancing and robustness easy to achieve Sender Receiver (R) id T T id R Transcoder (T) T,id data iddata R id T,id data id T,id data

76. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 76 Service Composition: Receiver Initiated q Receiver can also specify the operations to be performed on data Receiver (R) id id F,R Firewall (F) Sender id F F id F,R data R F,R data id data id data

77. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 77 A Common Platform For Overlays:

78. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 78

79. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 79

80. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 80

81. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 81

82. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 82

83. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 83

84. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 84 Current Status q Goal: 1000 sites… worldwide. q Several services running on planetlab today.

85. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 85 The Pluralist Scenario q Many different architectures simultaneously available q No clear distinction between architecture and services q Key to evolving the architecture: q Virtual link establishment and virtual routers q Substrate for deploying overlays is new “waist” q Planetlab becomes model for Internet q Virtualization becomes an end in itself

86. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 86 Purists vs Pluralists q Purists: q Architecture specified by universal protocol (e.g., IP, I3) q Goal: long-term flexibility and applicability q Challenge: foreseeing future needs q Pluralists: q IP is just one component of the Internet “system” q “Architecture” arises from union of overlays, etc. q Goal: meet short-term needs to attract users q Challenge: how can apps/users cope with diversity?

87. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 87 The Ultimate Pluralist: Active Networking q Seminal work: D. Tannenhouse and D. Wetherall ’96 q Routers can download and execute remote code q At extreme, allow each user to control its packets User 2: Multicast User 1: RED Reading: Tennenhouse et al, A survey ofA survey of active networks research,

88. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 88 An Active Node Toolkit: ANTS q Add active nodes to infrastructure IP routersActive nodes

89. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 89 Active Nodes q Provide environment for running service code q Soft-storage, routing, packet manipulation q Ensure safety q Protect state at node; enforce packet invariants q Manage local resources q Bound code runtimes and other resource consumptions

90. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 90 Where Is the Code? q Packets carry the code q Maximum flexibility q High overhead q Packets carry reference to the code q Reference is based on the code fingerprint: MD5 (128 bits) q Advantages: q Efficient: MD5 is quick to compute q Prevents code spoofing: verify without trust packet code packet code reference

91. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 91 Code Distribution q End-systems pre-load code q Active nodes load code on demand and then cache it previous node loading node request time packet code responses packet

92. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 92 Code Distribution q End-systems pre-load code q Active nodes load code on demand and then cache it previous node loading node request time packet code responses packet

93. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 93 Practical Issues q Efficiency/Performance: largely solved problem q Node-level protection: largely solved problem q Network-level protection: unsolved q hard to prevent routing loops, too many generated messages, etc. q have to rely on “certified” programs, approved by administrative authorities

94. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 94 Active Networking and E2E Principle End-to-end arguments address design more than implementation and implementation more than execution--that is, they suggest who should provide the code, not which box it should run on.

95. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 95...... end-to-end arguments have not one, but two complementary goals: Higher-level layers, more specific to an application, are free to (and thus expected to) organize lower-level network resources to achieve application-specific design goals efficiently. (application autonomy) Lower-level layers, which support many independent applications, should provide only resources of broad utility across applications, while providing to applications usable means for effective sharing of resources and resolution of resource conflicts. (network transparency)

96. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 96 q While making lower layers more active or programmable is likely to enhance application autonomy, the risk is that programmable lower layers may reduce network transparency. The reason is that a key element of transparency is some ability to predict how the network will behave.

97. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 97 Will ISPs Adopt? q If ISPs aren’t willing to adopt individual services (e.g., multicast), why would they be willing to adopt Active Networking? q If ISPs aren’t willing, then deploying Active Nodes at the application level is merely another form of an overlay network q If ISPs are willing to deploy code, then why isn’t this just a case of programmable routers

98. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 98 Guidelines for Robustness Reading: Anderson et al: "Design Guidelines"Design Guidelines for Robust Internet Protocols":

99. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 99 Isn’t the Internet Robust? q Robustness was one of the Internet’s original design goals q Adopted failure-oriented design style: q Hosts responsible for error recovery q Critical state refreshed periodically q Failure assumed to be the common case q Internet has withstood some major outages with minimal service interruption q Why the lecture on robust protocols?

100. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 100 Traditional Failure Models q Most Internet protocols are design with (at most) two failure models in mind: q Participating nodes: fail-stop q Other nodes: malicious q Denial-of-service, spoofing, etc. q They are usually vulnerable to participating nodes misbehaving: q Subverted nodes q Misconfigured nodes q Bug in software

101. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 101 Semantic vs Syntactic Failures q Syntactic failures: q Node doesn’t respond, message ill-formed, etc. q Semantic failure: q Node responds with well-formed message, that is semantically incorrect

102. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 102 Traditional Techniques q Cryptographic authentication: q Verifies who is talking, but not what they say q Formal verification: q Verifies that correct protocol operation leads to the desired result q Fault-tolerance via consensus: (Byzantine techniques) q Requires that several nodes have enough information to do the required computation q In network routing, for instance, only the nodes at the end of a link know about its existence

103. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 103 Example: Routing Misconfiguration q Router advertises short route to some prefix q All other routers believe q Several such instances have taken large portions of the Internet down

104. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 104 Example: Congestion Control q Hosts can ignore TCP CC and send too fast q Receiver can lie to sender about ECN bits

105. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 105 Traditional Techniques q Don’t deal with any of these problems… q Parties could be authenticated q Protocols are correct q Can’t use consensus techniques

106. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 106 How Can We Avoid These Problems? q No single rule or algorithm q Some general guidelines (presented next) q Overall theme: design defensively

107. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 107 G1: Value Conceptual Simplicity q Obvious, but often unheeded (e.g., BGP) q Simplicity allows one to reason about behavior more easily q Leads to better failure handling

108. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 108 G2: Minimize Your Dependencies q The more nodes you depend on for correct information, the higher the chances for failure are q Example: Sender trusts receiver for congestion information

109. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 109 G3: Verify When Possible q Can’t use heavyweight Byzantine-style algorithms q But can try lightweight verification techniques q Examples at end of lecture q Active area of research

110. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 110 G4: Protect Your Resources q Example 1: SYN flood and SYN cookies q Example 2: Fair queuing in networks

111. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 111 G5: Limit Scope of Vulnerability q If system is vulnerable to a failure anywhere else in system, then robustness is unlikely q Route flap damping limits extent to which failures propagate

112. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 112 G6: Expose Errors q To conflicting goals: q Automatically recover q Don’t let problems fester

113. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 113 Lightweight Verification q ECN nonces q Self-verifying CSFQ q See paper for more details: q Reading: Anderson et al: "Design Guidelines for Robust Internet Protocols":"Design Guidelines for Robust Internet Protocols":

114. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 114 Extra Slides: Only For Reference (Will not be covered in class)

115. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 115 System Design Rules of Thumb q Design a system to tradeoff cheaper resources against expensive ones (for a gain) q When resources are cheap and abundant, waste them. Design focuses on cutting out any expensive resource that comes in the way! (eg: parallelism) q Filtering => Efficiency => Scalability q Apply principles like E2E and ALF to decide on right placement of functionalities in different system levels q Interfaces must outlive several generations of change in the components being interfaced. q Three factors drive interface design: q functionality demanded, q available technology, q performance tradeoff.

116. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 116 q Functionality requirements can be understood by taking different views of the system (eg: designer, implementor, operator). q Reduced functionality can result in cheaper, scalable, quickly engineered system q Placement of functionality is critical in system design q No paradigm is going to work or functionality can be met if the available technology to implement it does not exist. q Performance is either relative or absolute and is usually modeled at the high level as a function from system parameters (input) to system metrics (output). q Metrics must be design to reflect design tradeoffs. q Only sensitive parameters matter. q Optimize the common case (Amdahl’s law) q Solve 90% of the problem that matters, throw away the remaining 10% of the problem requirements!

117. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 117 Layered Naming: extra slides

118. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 118 Key Architectural Questions 1. Which entities should be named? 2. What should names look like? 3. What should names resolve to?

119. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 119 SIDs and EIDs should be Flat q Flat names impose no structure on entities q Structured names stable only if name structure matches natural structure of entities q Can be resolved scalably using, e.g., DHTs q Flat names can be used to name anything q Once you have a large flat namespace, you never need other global “handles” Stable-name principle: A stable name should not impose restrictions on the entity it names

120. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 120 Flat Names are a Two-Edged Sword q Global resolution infrastructure needed q Perhaps as “managed DHT” infrastructure q Lack of local name control q Lack of locality q Not user-friendly q User-level descriptors are human-friendly

121. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 121 Key Architectural Questions 1. Which entities should be named? 2. What should names look like? 3. What should names resolve to?

122. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 122 Delegation q Names usually resolve to “location” of entity q Packets might require processing at intermediaries before reaching destination q Such processing today violates layering q Only element identified by packet’s IP destination should inspect higher layers Delegation principle: A network entity should be able to direct resolutions of its name not only to its own location, but also to chosen delegates

123. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 123 Delegation Enables Architecturally-Sound Intermediaries EID d IP ipd EID s Firewall EID f IP ipf Dest EIDMapping df fipf q Delegate can be anywhere in the network, not necessarily on the IP path to d (ipd) q SID/EID can resolve to sequence of delegates ipf EID d TCP hdr Packet structure (dests only) Resolution svc

124. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 124 Application-Layer Intermediaries EID s Spam/virus filter SID v, EID eidv, IP ipv Dest EID/SIDMapping SID fmid[v, ms] SID veidv ipv... Mail server SID ms Goal: Email to user must traverse spam filter en route to mail server fmid is SID for composed service ipv EID eidv TCP SID v data SID ms msg Resolution svc

125. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 125 Take-Home Points q Flat names are now plausible q Two flat naming layers fix brittleness q SIDs and EIDs q Delegation is a powerful primitive

126. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 126 The Future? q With flat SID/EID + delegation: q Like hosts, data becomes first-class entity q Middleboxes gracefully accommodated q IP will continue to be a rigid infrastructure q But naming is more malleable and can reduce architectural brittleness q Deployment requires q Changes to hosts q Global resolution infrastructure