1 / 20

An End-to-End Approach to Globally Scalable Programmable Networking

An End-to-End Approach to Globally Scalable Programmable Networking. Micah Beck , Assoc. Prof. & Director Terry Moore , Assoc. Director James S. Plank , Assoc. Prof & Director Logistical Computing & Internetworking (LoCI) Lab Computer Science Department

kolina
Download Presentation

An End-to-End Approach to Globally Scalable Programmable Networking

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. An End-to-End Approach to Globally Scalable Programmable Networking Micah Beck, Assoc. Prof. &DirectorTerry Moore, Assoc. DirectorJames S. Plank, Assoc. Prof & Director Logistical Computing & Internetworking (LoCI) Lab Computer Science Department Future Directions in Net Architecture Workshop Sept 27, 2003

  2. What We Mean By That Title • End-to-End: Rorschach for Networkers • Generic functionality at intermediate nodes • Push complex functionality to “endpoints” • Scalability has many dimensions • Number and distribution of nodes • “Global” – like the Internet • Programmable Networking • Able to implement new functionality without deploying new infrastructure

  3. How to Build a Scalable Network ServiceFrom Things You Have Around the House • Weaken the Semantics • Best Effort: Availability, Correctness & Security • Implement stronger guaranteesEnd-to-End • Maximum Service Units in all dimensions • Visible state must be generic • Softness of state is a function of its use, not itsimplementation

  4. Review: Scalable Network Storage • An End-to-End Approach to Globally Scalable Network Storage, SIGCOMM 2002Beck, M., Moore, T., and Plank, J. • End-to-End means writer to reader • Weak semantics: storage at server not necessarily available, correct or secure! • Tends to upset storage people • Network people find it more natural • Déjà vu: Are we reinventing file-based networks? • “Everything I need to know I learned in Multics”

  5. The Internet Backplane Protocol • malloc-like allocation API; load/store/copy • Maximum Service Units in all dimensions • Maximum size of storage allocation • Maximum duration of storage lease (renewable) • Generic service: Minimal structure in stored state • Names not semantically meaningful (long, random) • Servers are functionally interchangeable • Warning: Denial of Service attacks! • Scalable yes, but is it worth doing?

  6. A Gratuitous Diagram The limit of scalable functionality scalability Scalable services Too good to be true Not worth doing functionality Won’t scale

  7. Scalable Programmable Networking • Elements of Programmability • Transforming data (computing) • Making decisions (control) • Computing is resource intensive • Control is hard to scale • Let’s start with computation • Remote Procedure Call (client/server) • Network services operating on flows (send/receive) • Warning: Denial of Service attacks!

  8. Applying Our Methodology • Weaken the Semantics • Best Effort: Availability, Correctness & Security • Implement these End-to-End • Maximum Service Units in all dimensions • Maximum size of input & output • Maximum duration of computation • Push state management to the endpoints • Functional operations; no communication! • IBP provides scalable state management

  9. The Network Functional Unit (NFU) • Exposed Service Model • Buffer-to-buffer operations • Must be composed with communication • Remote Procedure Call • Flow Service • IBP allocations can beRAM or mapped files client NFU operation receiver sender

  10. The NFU API (simplified) • IBP_nfu_run(IBP_depot, NFU_op, IBP_arg_list[]) • Depot Address/port identifier • NFU_op: numerical operation identifier • Different implementations of same opcode must be interchangable • IBP_arg_list: list of allocations on called depot • Each list element specifies • call by reference (IBP capability) or value • read-only or read/write • Data types are not checked by NFU call mechanism

  11. Dealing with State in the NFU • Operands and results are IBP allocations • State & side effects are possible • But are they necessary? (use RAM buffers!) • What operations are supported on a depot? • Whatever application communities want • Not necessarily homogeneous, but consistent • How is the set of operations extended? • Assigned names w/ fixed semantics • Trust is required to install new operations • Dynamic extension reduces scalability

  12. End-to-End Guarantees: Availability • A weak model is arbitrary outputs on failure • Weaker still: arbitrary inputs on failure • Stronger model: atomicity • Transient unavailability: Retry • Partition: redundancy in management of state • Don’t overwrite inputs • Checkpointing • Transactions

  13. Correctness: Now It Gets Difficult • Can computational elements be untrusted? • Generalize from Networking & Storage • These services “compute” the identity • Checksums verify the identify function • We need to verify other services • Independent redundant computations • Efficiently verifiable computations • Verifiability may require redundancy in outputs • Example: When computing a GCD, return all the prime factors

  14. Security is difficult, too! • Current approaches to remote computation require trust & authentication of the server • Communication between client & server is secure • This is classical hop-by-hop security! • This assures accountability • End-to-end: compute without decrypting • Is it possible? In some cases, perhaps. • Is a dual strategy possible?“Trust but verify”

  15. Is This Anything? Is It Networking? • “This no longer fits my intuition of what networking is. This is remote access to storage or distributed computation or something else.” • What is networking? How did I get here? • What do users what from the network? • Synchronous communication • Asynchronous communication • Computation is sometimes required • Implementing control is a performance issue • Support for distributed applications

  16. Multidimensional Networking “… memory locations … are just wires turned sideways in time” Dan Hillis, 1982,Why Computer Science is No Good

  17. Illustrative Example: Merge Tree Z M Y L X K Depot 2 Depot 1 copy copy K L M X Y Z K X stream state Depot 3 merge merge state C B A B C A operations in red are initiated by endpoint stream state network endpoint

  18. What About Performance? • Obvious problems with client-to-depot latency • Data & Control dependences enforced at edge • Deep pipelining can mask latency • Fill pipe with straight-line code • We could even label and cache “instructions” • When autonomy is delegated to processor, state at depot increases • Pseudo-processes can be created at the discretion of the client

  19. Related Work • Ephemeral State Processing, Calvert, Griffioen and Wen, SIGCOMM 2002 • 64-bit allocations; scalar operations • Active Networking • Agents & Mobile Code • Distributed Operating Systems • Remote Procedure Call • Checkpointing & Process Migration • State Machine Models • Grid Computing; Peer-to-Peer

  20. Conclusions • Our architectural development follows a clear architectural methodology, generalizing from IP • The network is made up of limited-size, unreliable, limited-duration resources • Creation of unbounded, reliable, permanent abstractions is difficult and costly • Why is this so counter-intuitive? • Networking starts from an analysis of scalability • Computer Science usually starts from desired functionality • The proof of the pudding is in the tasting…

More Related