1 / 19

Questions about Programming the Internet Ken Calvert University of Kentucky USA

Questions about Programming the Internet Ken Calvert University of Kentucky USA. Why? How? What?. Collaborators: Jim Griffioen, students Su Wen, Amit Sehgal, Billy Mullins, and Leon Poutievski. Question: Why?. Why do we want a programmable Internet?

hedwig
Download Presentation

Questions about Programming the Internet Ken Calvert University of Kentucky USA

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. Questions about Programming the InternetKen CalvertUniversity of KentuckyUSA Why? How? What? Collaborators: Jim Griffioen, students Su Wen, Amit Sehgal, Billy Mullins, and Leon Poutievski NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  2. Question: Why? Why do we want a programmable Internet? • To speed evolution, overcome “ossification” But ... stability of basic processing is crucial for the fast path • To customize processing along the network path What do we need beyond forwarding, scheduling? • To improve scalability of group applications Example: Concast • To overcome limitations (info hiding) of the best-effort service abstraction Example: Using Ephemeral State Processing to identify branch points in multicast trees NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  3. Concast • Scalability through abstraction • Inverse of multicast • Single address represents an arbitrary number of senders. • Network merges messages from the group • According to user-supplied merge specification (=program) • Benefits both receiver and network • Multiple sends result in a single message delivery • Reduced bandwidth requirements • Merging happens exactly where required (on direct path to R) R S Concast Multicast S R S R R S R S R S NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  4. Question: Why? Why would providers want a programmable Internet? • Because users will pay to get it (see also Wakeman) Why trust shared infrastructure to... • Forward packets to specified destinations? • Reserve end-to-end bandwidth/buffering for their packets? • Process user data to improve scalability? • Example: multicast feedback aggregation/filtering • Process content en route from content provider? • Example: transcoding news video for low-bandwidth links • Enforce user policies? • Example:controlling concast group membership NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  5. Concast Security Policies • User (Receiver) Concern: Data integrity, authenticity, confidentiality • Application-level policy: Which senders can participate • Network-level policy: Which routers (domains) can participate in the flow (i.e. be upstream) • Perform merging • Enforce policies! • Provider (Router) Concern: Only paying customers get access to the service • Network-level policy: Which entities can participate as senders/receivers • Network-level policy: Which routers (domains) can be downstream/upstream NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  6. 1. Join Flow Request Merge Spec Rcvr Sender Policy R0 Sender Policy R0 Downstream Policy R0+Rcvr Upstream Policy 6. Join Flow Succeeded 5. Apply policies, install merge spec 2. Request for Merge Spec 4. Merge Specification R1 Policy Monotonicity Requirements R0 Sender Policy R0 Downstream Policy R0 Upstream Policy Sender Domain Boundary R0 Receiver 3. Apply policies R1 Downstream Policy R1 Upstream Policy Rcvr Sender Policy Rcvr Upstream Policy NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  7. Merge Spec Rcvr Sender Policy R0 Sender Policy R0 Downstream Policy R0+Rcvr Upstream Policy 6. Join Flow Succeeded 4. Merge Specification 8. Merge Specification R1 Rcvr Sender Policy R0+R1 Sender Policy R1 Downstream Policy R0+R1+Rcvr Upstream Policy Policy Monotonicity Requirements 1. Join Flow Request Sender Domain Boundary 5. Apply policies, install merge spec R0 2. Request for Merge Spec 7. Request for Merge Spec Receiver 3. Apply policies R1 Downstream Policy R1 Upstream Policy Rcvr Sender Policy Rcvr Upstream Policy NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  8. Question: How? How should the network be programmed? • Lots of possible answers; depends on assumptions • We have only begun to explore this (see also Tschudin, Smirnov) How to charge for a programmable Internet? • At signaling time, not forwarding time • Untrusted  trusted transformation, policy application too costly for data plane • Locally, not end-to-end • At least two providers involved in end-to-end service • Avoid multilateral settlement protocols, transitive trust NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  9. Two-level Model of Programmability • Node-local functions enabled directly by user Examples: duplicate, redirect, drop • Controlled via secure signaling protocol • Affect only packets “belonging to” the paying user • Paid for at signaling time via bilateral agreement between end user and node administration • End-to-end functions available to all packets • IP-like resource requirements (“too cheap to meter”) • Fixed set of computations • Close to fast path • Sequence of per-packet computations + ephemeral state = global computations NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  10. Lightweight Processing Modules and Ephemeral State Processing • LWP: fixed-function per-flow modules • Invoke at particular node(s) • User supplies flowspec, function + params, credit card • Maintain via soft-state • Use to implement: multicast, mobility, anti-DoS • ESP: allow packets to create, manipulate small amounts of state in routers at forwarding time Example: increment a counter, drop packet if > threshold • Fixed instruction set; one instruction per packet • Per-packet processing, storage requirements bounded due to state lifetime • Narrow interface to forwarding function: drop or forward • Use to: probe topology, aggregate user data (a la concast), ... NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  11. Join Example: Multicast via ESP+LWP • LWP “dup()” function installed by receivers to duplicate and forward marked packets to themselves • To join the tree: • Discover closest existing branch point (via ESP) • Activate a dup() to self there • Find optimal branch point (via ESP), move dup() there B C dupB() dupC() S A r1 r2 r3 E D NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  12. Example: Multicast via ESP+LWP • LWP “dup()” function installed by receivers to duplicate and forward marked packets to themselves • To join the tree: • Discover closest existing branch point (via ESP) • Activate a dup() to self there • Find optimal branch point (via ESP), move dup() there B C dupB() dupC() S A r1 r2 r3 E D r1 NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  13. dupE() Example: Multicast via ESP+LWP • LWP “dup()” function installed by receivers to duplicate and forward marked packets to themselves • To join the tree: • Discover closest existing branch point (via ESP) • Activate a dup() to self there • Find optimal branch point (via ESP), move dup() there B C dupB() dupC() S A r1 r2 r3 E D NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  14. Example: Multicast via ESP+LWP • LWP “dup()” function installed by receivers to duplicate and forward marked packets to themselves • To join the tree: • Discover closest existing branch point (via ESP) • Activate a dup() to self there • Find optimal branch point (via ESP), move dup() there B C dupB() dupC() S A dupE() r1 r2 r3 E D r2 NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  15. dupE() dupE() Example: Multicast via ESP+LWP • LWP “dup()” function installed by receivers to duplicate and forward marked packets to themselves • To join the tree: • Discover closest existing branch point (via ESP) • Activate a dup() to self there • Find optimal branch point (via ESP), move dup() there B C dupB() dupC() S A r1 r2 r3 E D NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  16. Programmability via LWP and ESP • Deployment strategy • Recover costs via LWP • Value-added: end-to-end services like multicast • Deploy ESP to enable LWP • End-to-End Services • Multicast • Layered multicast congestion control • Open issue: what others? • Can we do QoS with custom processing at 1-2 nodes? • Are congestion location/timescales consistent with LWP-based approach? NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  17. Question: What? What to program? Do processing here... ... not here Channel • Global fault-tolerance • Run at channel speed • Simple interface to forwarding path Interconnect • Not fail-safe • Maintain forwarding state • Run at interconnect speed = (wire speed)n How to structure services as channel computations? (See also Tschudin, Che) NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  18. Research Issues • Design of “trustworthy” infrastructures for combined communication/processing • Incentive/trust acquisition/revocation? • Composable policies, proxy enforcement? • “Policy: the Next Frontier” Connection to ad hoc, P2P • Programming models for relay systems (consider trust)! • Necessary and sufficient set of (channel-oriented) functions? • What can be done with local enhancements? • Is local differentiation sufficient for E2E QoS? • Congestion episode timescales, bottleneck movement Connection to measurement, modeling • Design of “best effort” end-to-end computations NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

  19. References • Concast: Design and Implementation of an Active Network Service, K. Calvert, J. Griffioen, B. Mullins, L. Poutievski, A. Sehgal, S. Wen, IEEE JSAC 19(3), March 2001 • Lightweight Network Support for Scalable End-to-end Services, K. Calvert, J. Griffioen, S. Wen, Proceedings of ACM SIGCOMM 2002 • Building Multicast Services from Lightweight Processing Modules and Ephemeral State, J. Griffioen, S. Wen, K. Calvert, Computer Networks 38(3), February 2002 • CALM: Congestion-Aware Layered Multicast, S. Wen, j. Griffioen, K. Calvert, Proceedings of IEEE OPENARCH 2002 NeXtworking’03 June 23-25,2003, Chania, Crete, Greece The First COST-IST(EU)-NSF(USA) Workshop on EXCHANGES & TRENDS IN NETWORKING

More Related