1 / 13

The Internet Backplane

The Internet Backplane. Micah Beck mbeck@cs.utk.edu Innovative Computing Laboratory University of Tennessee, Knoxville. Contributers. University of Tennessee, Knoxville Micah Beck, Henri Casanova, Jack Dongarra , Terry Moore, Jim Plank University of California, San Diego

booth
Download Presentation

The Internet Backplane

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. The Internet Backplane Micah Beck mbeck@cs.utk.edu Innovative Computing Laboratory University of Tennessee, Knoxville

  2. Contributers • University of Tennessee, Knoxville • Micah Beck, Henri Casanova, Jack Dongarra , Terry Moore, Jim Plank • University of California, San Diego • Fran Berman, Rich Wolski

  3. Motivation: Optimizing Netsolve • NetSolve calls are functional • Naive implementation of functional paradigm mismanages state • Dependence analysis allows us to optimize state management • NetSolve state management requires imperative storage

  4. What can we do with data? • Send it • to a communication buffer • allocated by receiver • Store it • in a file • allocated by file system

  5. Moving data through time & space • Sending data gives control over location, but we lose control over time. • “best effort” or “ASAP with specified QoS” • can’t determine where data will be at any given time • Storing data gives control over time at the current location only. • What about controlling the trajectory? • “Lumpy pipes”

  6. Internet Backplane Protocol • Named buffers stored at IBP servers • Lightweight allocation and administration • Capabilities/certificates • Manipulating TCP/IP streams • staging, delivery, remote movement • volatile resources • “Files are just messages movin’ real slow”

  7. The IBP challenge: Give it away! • We now hoard high performance cycles. • Netsolve has us given ‘em away! • Once we guarded disk access. • The Web has us giving it away! • IBP gives away more. • How far can we go before security and allocation get in the way?

  8. IBP Application: NetSolve • Data locality is a requirement for high performance • NetSolve’s model moves all arguments and results for every remote call • argument caching • producer/consumer dependences • Temporary files, checkpointing

  9. IBP Application: Logistical QoS

  10. IBP Application: Logistical FTP • Name a time period and locality for delivery • Let the scheduler figure out how to get it to an appropriate IBP server • File delivery requests are resolved to IBP server & buffer by LFTP • Delivery of large files requiring QoS.

  11. IBP App: Network Management • Large data streams generated at routers and switches must be collected and analyzed. • Collection aided by logistical delivery. • Initial analysis can be performed by network intermediate nodes (IBP servers?) • Very important for networks with differentiated services

  12. Current Status • IBP version 1.0beta available • plank@cs.utk.edu • Deployment in Internet2 GigaPOPs • No security, community resources • Time-limited allocation • Volatile storage: you can take it back! • Logistical FTP under development

  13. Directions • More IBP-based services • Transactions • Directory • More attention to administration • Security • Allocation • Monitoring • Specifying QoS Delivery

More Related