1 / 46

Active Names: Flexible Location and Transport of Wide-Area Resources

Active Names: Flexible Location and Transport of Wide-Area Resources. http://www.cs.utexas.edu/users/less/bb/. Motivation. DNS Name IP Address New naming abstractions: Server selection, content selection, customization, device presentation, disconnected operation,...

tatyana-ruiz
Télécharger la présentation

Active Names: Flexible Location and Transport of Wide-Area Resources

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Active Names:Flexible Location and Transport of Wide-Area Resources http://www.cs.utexas.edu/users/less/bb/

  2. Motivation • DNS • Name IP Address • New naming abstractions: • Server selection, content selection, customization, device presentation, disconnected operation,... • Same name, different services • Traditional naming is only one step in larger process

  3. Adding Flexibility Under Current Infrastructure • HTTP redirect • DNS round robin • URN’s with sed scripts to mangle names • Cisco Local Director/Distributed Director • Mobile IP • Web caches/Active Caches • HTTP content negotiation • Dynamic distillation • ... • Each adds flexibility to one step in name binding But how do you combine services?

  4. End-to-End, Flexible, Composable Name Resolution • DNS • Name IP Address • Everyone gets same translation • Protocol/path used to access service is fixed • Active Names • End-to-end • Translate from what user types to what data appear • Programmable • General-purpose programs for name resolution • Composable • Server and client customize path between them

  5. Outline • Motivation • Architecture • Applications and Experiments • Conclusions

  6. Active Names: Basic Idea • Names identify a Namespace to interpret them • Namespace Programs have two tasks • 1) Determine name and namespace to evaluate next • 2) Transport and transform data to that namespace Name’ Data’ Name Data Namespace Programs

  7. Delegation: Hierarchical Namespaces Each namespace has jurisdiction over its names Delegation policy is namespace specific e.g., HTTP reply specifies namespace to handle future requests to subordinate URLs e.g., DNS delegates based on administrative ownership HTTP Server Customization CNN Customizer Yahoo Customizer Generic HTTP Location 1: Delegation

  8. Location 2: After Methods • Composability • Combine namespace programs • Integrate extensions provided by different parties (e.g., client+server) • After methods • Continuation-passing style of programming • Programs bundle remaining work into “after methods” before passing control e.g. [modem-customizer|proxy|client] [proxy|D-encode|D-decode|client]

  9. Transport: Programming Model Program 1 Program 2 Client • Stream data model • Pipelining • Continuation-passing style • Return path may differ from request path • Minimize WAN communication Request Reply Data

  10. Proxy Client Server Proxy Client Server Performance Gains • Application-customized transport protocols • Location-independent programs • Each program decides where it runs • Choose location to optimally utilize resources • (e.g., D-encoding+transcoding to optimize slow link) • Customize close to client instead of at server • (e.g., to generate dynamic content near client) • 3-way RPC

  11. ... Hit Count Resolver Virtual MachineMicrokernel Approach • Java-based virtual machine • Sandbox namespaces • Access to other namespaces via Resolver • Controlled access to local resources Transcode Yahoo Server Select Namespaces CNN Http Hoard QRPC N W Resolver $ Virtual Machine Local Resources

  12. Applications and Experiments • Server selection: • End-to-end approach and extensibility • Mobile distillation: • Location independence • Distillation+ad rotation+hit counting: • Composability

  13. Server Selection DNS Round-Robin • Randomly choose replica • Avoid hotspots Distributed Director • Route to nearest replica • Geographic locality Active Naming • Previous end-to-end performance • Adaptive Seattle Replica Berkeley Replica Berkeley Clients

  14. Server Selection Performance • Optimal server selection varies with offered load • Low load: choose closest server • High load: distribute load randomly • Active Names framework provides • End-to-end measurements • Flexible algorithms Nearest Active Random

  15. Composability • Recall: name resolution • name service representative(s) result • Many entities customize name resolution • Client: device presentation, cache hierarchy to use, hoarding, ... • Server: customization, server selection, consistency, disconnected server, ... • Cache system: replica location, active caching, ... • Server replication system/Mirrors: service placement, server selection, … • Cooperating services: content | language translator, meta-search, ...

  16. Composability: HTTP Caching • HTTP cache hit rates 30%-50% • No “magic bullet” for making more web data cachable • Use Active Names to combine strategies

  17. Experiment • Composability • Server wants to make “uncachable” data cachable • Use ServerCustomization module to insert AdRotate module and HitCount module into pipeline • Client on modem wants to improve miss times • Use ClientCustomization module to insert DistillImage module into pipeline

  18. ServerCust: ON Distillation: ON ServerCust: ON Distillation: OFF ServerCust: OFF Distillation: ON ServerCust: OFF Distillation: OFF Composability Results Cumulative Avg. Times Per-Request Times • Early requests: Distillation makes misses faster • Later requests: Server cust. makes misses into hits • Combined server and client strategies best

  19. Status and Future Work • Status: Active Names Framework • Framework for distributing name resolution programs across WAN • http://www.cs.utexas.edu/users/less/bb/ • Issues • Infrastructure • Improved cache consistency and distributed state • Resource allocation • Debugging • Secure RMI • Distributed services • Server placement and selection algorithms • Network mapping • ...

  20. Conclusions • Active Name: • Mobile programs to locate services and transport data • Programmability addresses needs of WAN services • Design emphasizes • Efficiency in WAN Pipelining, n-way RPC, location independence • Extensibility, composability Delegation, continuation-passing style

  21. Related Work • Point solutions • see above • Extensible frameworks • Ninja (Gribble et. al) • Intentional naming (Balakrishnan et. al) • Active networks (…) • Transaction monitors

  22. Status and Future Work • Status: Active Names • Framework for distributing name resolution programs across WAN • Issues • Stringent cache consistency requirements • Server placement and selection algorithms • Resource allocation • Debugging • Simplify distributed security

  23. Active Naming Approach • Unified end-to-end framework to match new name resolution abstraction • Extensible and composable • General-purpose programs for name resolution • Service and client control name resolution • Service and client control transport of data • Efficient in WAN

  24. Example: Mobile Distillation • Clients name a single object • Returned object based on client • Network connection, screen • Current approach [Fox97] • Proxy maintains client profile • Requests object, distills • Active naming • Transmit name + applet • Flexible distillation point • Tradeoff computation/bandwidth • Support mobile clients Client-Specific Naming Variables: Network Screen

  25. Importance of Location Independence I • Distill 59 K image to 9 K • Clients/Proxy at UC Berkeley • Server at Duke Active Policy tracks then beats best static policy

  26. Importance of Location Independence II • Server loaded with 10 competing processes • No longer makes sense to perform all distills at server Dynamic placement of computation for optimal performance

  27. Active Naming Vision • Today: Name is static binding to physical location and object (DNS, LDAP) • Want: dynamic, flexible binding to service/data • Server selection among geographic replicas (CISCO, IBM, etc.) • Client customization (e.g., distillation, custom CNN) • Server customization (e.g., hit counting, ad rotation, etc.) • An Active Name is a mobile program that invokes a service or acquires data • Flexibly support various naming semantics • Minimize wide-area communication

  28. Namespace Program Namespace’ Name’ After Methods’ Location Transport Data’ Active Name Architecture Resolver Virtual Machine Namespace Program Active Name Namespace Name After Methods Data Local Resources

  29. Active Name Resolution Namespace Program Namespace’ Name’ After Methods’ Namespace Name After Methods Location Transport Data’ Data • Namespace Program: A filter with two tasks: • Locate next filter to run • Transport data to next filter

  30. Traditional P P Request Response C P S P Multi-Way RPC P P Request C P S P Response Multi-Way RPC • Goal: minimize latency • Usually have to pass results down a hierarchy • Adds latency • Store and forward delays • Multi-Way RPC via after methods • Last after method transmits result back to client • Minimize latency • Use capabilities for security

  31. Program 1 Program 2 Client Request Data Advantages • End-to-end semantics • Location independence • Extensibility and composability • Minimize wide-area communication

  32. Change the Socket API? • Name resolution v. service access • Traditional model separates resolution from service access • ipaddr = gethostbyname(“www.cs.utexas.edu”); • socket = connect(ipaddr, 80); • write(socket, “GET /index.html HTTP/1.0\n\n”); • read(socket, buffer); • Active names integrates location and transport • buffer = Resolver.Eval(“(HTTP) www.cs.utexas.edu/index.html”); • Hide physical address from programmer • Allows for reorganization under the hood • End-to-end approach

  33. Security • Protection between active name programs provided by Java’s type safety mechanism. • Caller passes a certificate to the callee granting it a subset of its rights. • Transitive closure of the certificates determines the rights of a principal. • For instance, each caller might grant its callee the right to respond to the client.

  34. ServerCust: ON Distillation: OFF ServerCust: OFF Distillation: OFF ServerCust: OFF Distillation: ON ServerCust: ON Distillation: ON Composability Results • Combined server and client strategies give best performance

  35. Composability Results ServerCust: ON Distillation: OFF ServerCust: OFF Distillation: OFF ServerCust: ON Distillation: ON ServerCust: OFF Distillation: ON • Combined server and client strategies give best performance

  36. Extensible caches: No “magic bullet”: need composability

  37. Program Name Data Background and Motivation • Goal: programmable name --> result binding • Active naming • Common framework for interposing program on name-to-object translation • Set of applications • Note: Much in common with Active Networks, Detour

  38. Wide Area Naming Today DNSServer 2 Host Binding Client Cache HTTPServer Program 1 Name 4 URL 5 Name 6 Data 3 URL Redirect HTTPServer Name translation often just one step in larger request

  39. Extending WAN Data-delivery Architectures • Many proposed improvements; few used • Server multiplexing [CISCO, Smart Clients, HTTP Redirect, Ammar et. al, ...] • Flexible cache consistency [Tannenbaum et. al, Yin et. al] • Multimedia caching • Dynamic distillation [Brewer et. al] • Delta-encoding [Mogul et. al] • Active caches and hit counting [Cao, Mogul, …] • “Monolithic” protocol structure

  40. Requirements and Goals • “Forward compatibility”/easy to deploy new services • Dynamically download, safely execute code • No central code repository • Compose services • After methods • Namespace delegation • Minimize/hide network latency • “3-way RPC”/Continuation-passing • Pipeline-data model • Location independence

  41. Backwards Compatibility Front-ends Httpd ... DNS HitCount … Core System Virtual Machine N W Resolver $ Local Resources Namespaces Http Distiller DNS Utilities • “Microkernel” approach

  42. Goal: Add New Services • Dynamically download/safely execute code Resolver::Eval(ActiveName, …) • ActiveName uniquely identifies NamespaceProgram and Name • “Find Namespace and evaluate name” • Resolver downloads and instantiates Namespace • or finds Namespace in cache • Resolver calls Namespace.Eval(name, …) • Namespace executes in a sandbox • Namespace can access Resolver and LocalResources • No central code repository • Fetch via HTTP (or AName?)

  43. Comp Delta Enc. Goal: Hide NW Latency • 3-way RPC • Pipeline-data model • InputStream Eval(ActiveName, InputStream, …) • Location independence • Programs may be executed anywhere • Programs can decide where they want to run Request Namelet1 Namelet2 client proxy $ Http Http CNN Front End Http Delta Dec Decomp Http

  44. Fallacy: URL --> Object • Assumption needed for caching • Reality: WWW is not fetch(objName) • It is closer to execute(programName, args) • Customization, Ad rotation • URL + cookie --> object • URL + MIME header --> object • Hit counting • URL --> object + side effect • Dynamic page generation • URL --> program output • Volume/channel prefetching • Impact: • Many requests uncachable • Was this HTTP interface a mistake?

  45. Security • Current: simple model • Each namespace owns its state • Namespaces can only touch Resolver, LocalResources • CRISIS library needed? • Delegation, fine-grained access control • e.g. I want remote job to be able to access exactly one file on local machine • Interface • Stack inspection (Java)? • Authenticated InputStreams (CRISIS)?

  46. Resource management • Phase 1: requests should consume bounded resources • Associate request stream with a resource container • Other issues • Per request v. per-namespace restrictions • Is it: cycles, bandwidth v. state? • Multi-resource restrictions • Multi-machine coordination • Real-time guarantees

More Related