Presentation is loading. Please wait.

Presentation is loading. Please wait.

Services Architectures – Network Intermediaries and End-to-end Abstractions Dan Duchamp Stevens Institute of Technology Tilman Wolf University of Massachusetts.

Similar presentations


Presentation on theme: "Services Architectures – Network Intermediaries and End-to-end Abstractions Dan Duchamp Stevens Institute of Technology Tilman Wolf University of Massachusetts."— Presentation transcript:

1 Services Architectures – Network Intermediaries and End-to-end Abstractions Dan Duchamp Stevens Institute of Technology Tilman Wolf University of Massachusetts Amherst

2 Outline Premise: The next-generation Internet needs to do more than provide end-to-end bit pipes Three topics: 1. Network services and incentives (Dan) 2. Implementation challenges (Tilman) 3. Trust and naming (guest speaker: Paul Francis) Process Questions Brief presentation of context Long discussion Comments and questions welcome anytime!

3 Network Services and Incentives

4 Questions What services should the network provide? Should the network offer service at the application level rather than at the datagram level? Should anybody be allowed to provide services or not (and thus reduce potential for spam, phishing, spyware, etc.)? Will ease/speed of new service deployment be as important in the future as it has been in the past? Will the rate increase or decrease?

5 Questions (cont.) Capitalists would like to know: how should accounting/billing work? Should we construct a network that could, for example, bill per page view? Socialists would like to know: how can "undesirable uses" of the Internet be limited? What is the appropriate position for network architects to take regarding the design of censor-able, tap-able, spy- able Internet? What is the right technical tradeoff point between (1) a "civilized" appropriately-governable Internet, and (2) an Internet permitted "free expression"?

6 Session Layer Management of Network Intermediaries Dan Duchamp Computer Science Department and Wireless Network Security Center (WiNSeC) Stevens Institute of Technology Hoboken, NJ

7 The Discrete Internet Original Internet: Infrastructure supported by US government Users like-minded, like-behaving Intelligent hosts at edges of dumb routing fabric Current Internet: Commercially owned Subject to government oversight

8 Why Deploy Intermediaries? Commercial incentives: Added value – avoid being dumb pipe Place service hosts closer to client hosts to improve latency (e.g., Akamai) Customer incentives: Enforce customer policies on customer-owned networks (e.g., firewall) IP address flexibility/security (NAT) Government incentives: Law enforcement & surveillance

9 The Point Is … Internet has already been broken into discrete pieces Situation is not going to change We can either complain about it (end-to- end zealots) or deal with it

10 Basic Idea End-to-end layer 5 (L5) session runs over sequence of layer 4 (L4) transport connections Intermediaries explicitly addressed, each terminates an L4 connection

11 Consequences Easier to manage intermediaries if they are explicitly addressed Easier to manage network too Transport connections now long-lived & heavily usedthats how they work best: Amortize Path MTU discovery Maintain sstresh/cwnd settings More statistical multiplexing = less burstiness

12 Hypothesized Benefits Cleaner programming model Improved congestion control Improved core link utilization More efficient physical/routing design Improved session performance via pipeline parallelism Important qualification: improved performance after session has been established Easier traffic engineering

13 Foreseen Technical Problems How to locate desired intermediate service? Session setup too slow Study buffer management How to manage intermediary state? Additional points of failure & types of failures What is right app-intermediary control semantics/protocol? Want piecewise securityservice X should see only one part of payload, service Y only another part

14 Foreseen Philosophical Problems Unambitious: just what we dont need another hack to the socket/TCP/IP model Network is still pretty dumb: should know more about session semantics? If L5 handles end-to-end delivery semantics, what does L4 do?

15 Relation to FIND/GENI Yes, its trueL5 is just a tweak, not a new architecture But: gives a concrete base for experiments with certain architectural issues: What is a service? Where is it implemented? Who really provides itnetwork or host? State management Semantics/protocol for control signaling between end system & intermediary Mapping of function to layers

16 Questions What services should the network provide? Should the network offer service at the application level rather than at the datagram level? Should anybody be allowed to provide services or not (and thus reduce potential for spam, phishing, spyware, etc.)? Will ease/speed of new service deployment be as important in the future as it has been in the past? Will the rate increase or decrease?

17 Questions (cont.) Capitalists would like to know: how should accounting/billing work? Should we construct a network that could, for example, bill per page view? Socialists would like to know: how can "undesirable uses" of the Internet be limited? What is the appropriate position for network architects to take regarding the design of censor-able, tap-able, spy- able Internet? What is the right technical tradeoff point between (1) a "civilized" appropriately-governable Internet, and (2) an Internet permitted "free expression"?

18 Implementation Challenges

19 Questions If services are (partially) provided in the network, what is the appropriate "cut" between what is done in the network and what is done at the host? Does one cut fit all? How should services be accessed? Should the end-system application choose or should the network enforce service use? How much should the network know about data semantics? Is the web browser the "last application"? That is, every future service will have its host implementation as a browser plugin?

20 Questions (cont.) Should all services be visible to end-systems? Should all data modifications be reported to end- systems? Should communication between services be allowed? How should service state be handled? What services are necessary at the edges of networks with different operating principles (e.g., Internet to/from sensor net)

21 Service-Centric End-to-End Abstractions in Next-Generation Networks Tilman Wolf Department of Electrical and Computer Engineering University of Massachusetts Amherst

22 Information vs. Data Current Internet considers data as unchangeable entity Information encoded on end-systems Network unaware of semantics End-systems want to transfer information Use of explicit information transfer semantics Network communicates and processes information in suitable way High-level semantics sufficient Streaming vs. random access Point-to-point vs. multipoint Interactive vs. canned Bandwidth-sensitive vs. delay-sensitive Requires network to do more than forward bits

23 Information Transfer and Data Services Processing of data not limited to end-systems anymore Data processing throughout the network Services: Reliability Privacy Congestion control Caching Security (e.g., firewall, IPS/IDS) Quality of service Multicast Payload transcoding

24 Services Services can be combined for end-to-end information transfer Example 1: Reliable and private communication Example 2: Web caching

25 Services Example 3: Content distribution and transcoding How can all this be implemented?

26 Service Platforms Network processors are specialized processing system for packet processing System-on-a-chip multiprocessor Optimized for networking workloads Typical configurations Tens to hundreds of processing engines Multiple memory interfaces, co-processors Commercially available Intel, AMCC, Freescale, Hifn, etc. Multiple data path processors Memory I/O Control processor

27 Service Specification Abstraction for services along connection Similar to UNIX pipe concept Example 1: transfer between nodes {N1 > N2} Example 2: reliable transfer between nodes {N1 | TCP_TX > N2 | TCP_RX} Example 3: transcoding at arbitrary intermediate node {N1 | TCP_TX > * | TXP_RX | TRANSCODE | TCP_TX > N2 | TCP_RX} Leads to placement problem Assignment of processing tasks to underlying infrastructure

28 Service Placement Mapping problem appears on all layers of system End-to-end Routers Port processors

29 Service Placement Layered graph approach Single metric for communication and computation Source of connection Extra layer with vertical processing steps Destination of connection

30 Service Placement Ramdomized mapping approach: Random placement Fast analytics evaluation Repeat Performance Incrementally better results

31 Summary and Next Steps Abstraction based on information and data services Network can provide best setup for end-to-end communication Requires processing capabilities throughout the network Tackle implementation issues Service specification Service placement Prototype demonstration

32 Questions If services are (partially) provided in the network, what is the appropriate "cut" between what is done in the network and what is done at the host? Does one cut fit all? Is the web browser the "last application"? That is, every future service will have its host implementation as a browser plugin? How should services be accessed? Should the end-system application choose or should the network enforce service use? How much should the network know about data semantics?

33 Questions (cont.) Should all services be visible to end-systems? Should all data modifications be reported to end- systems? Should communication between services be allowed? How should service state be handled? What services are necessary at the edges of networks with different operating principles (e.g., Internet to/from sensor net)

34 Trust and Naming

35 Questions Should the Internet provide "trust"? Should we have source/identity validation? If application creators (apparently) want source/identity validation, why not provide it? Is a better tradeoff between trust/flexibility achievable? How? What should we use to identify end-system processes, users, etc.? How should we maintain identity mapping under mobility? Should the network understand the semantics of a data exchange?

36 End-Middle-End Architectures Paul Francis Cornell University

37 Most basic function in the Internet: Send a packet from an app on one host to an app on another host Often doesnt work… Sometimes an unwanted connection can be made Often a wanted connection cannot be made

38 What is the problem? IPv6 folks think (thought?) the problem is NATs But firewalls often err Port number only meaningful at the endhost Addresses change Shouldnt access control be done at the hosts? Argument of IPv6ers and E2E purists

39 We still need firewalls DoS Privacy of endhost IP address gives away private information Study of 100K mobile dyndns users Reality of infrastructure evolution Sometimes its just easier to put a box in the middle

40 Other reasons to put stuff in the middle Proximity (web caches) Benefits of scale (spam filtering) Centralized control Ease of deployment

41 End-Middle-End architecture Need an architecture that allows all stakeholders in a connection to: Know what is going on Assert their policies Access control policies Steering policies Security policies Transport policies

42 Do we need a blank slate? Maybe But lots of progress can be made on the existing infrastructure Formed EME IRTF Research group Initiated by Francis and Handley Chaired by Tilman Wolf Early stages

43 EME requirements Authentication, access control, and privacy Name-based Middlebox discovery and control Steering through middleboxes Anycast, multicast Mobility, multihoming Multi-party negotiation Performance Incremental deployability

44 EME Architecture Demote 5-tuple connection Ephemeral Use name-based signaling to manage connections Make this name-based approach part of the common sockets API

45 Slightly more detail Two types of signaling Off-path Used when IP address(es) not known Or to obtain (optional) credentials SIP is a good model On-path Used when IP address(es) known and have credentials Get through firewalls Steer connections

46 Questions Should the Internet provide "trust"? Should we have source/identity validation? If application creators (apparently) want source/identity validation, why not provide it? Is a better tradeoff between trust/flexibility achievable? How? What should we use to identify end-system processes, users, etc.? How should we maintain identity mapping under mobility? Should the network understand the semantics of a data exchange?


Download ppt "Services Architectures – Network Intermediaries and End-to-end Abstractions Dan Duchamp Stevens Institute of Technology Tilman Wolf University of Massachusetts."

Similar presentations


Ads by Google