15 744 Computer Networking L19 Active Networks Srinivasan

15 -744: Computer Networking L-19 Active Networks © Srinivasan Seshan, 2001 LH-1; 1 -15 -00

Active Networks Active networks • Active services • Assigned reading • • • [W 99] Active network vision and reality: lessons from a capsule-based system [AMK 98] An Active Service Framework and its Application to Real Time Multimedia Transcoding © Srinivasan Seshan, 2001 L -17; 03 -14 -01 2

Overview Active Networks • Active Services • © Srinivasan Seshan, 2001 L -17; 03 -14 -01 3

Why Active Networks? • Traditional networks route packets looking only at destination • • Problem • • Also, maybe source fields (e. g. multicast) Rate of deployment of new protocols and applications is too slow Solution • Allow computation in routers to support new protocol deployment © Srinivasan Seshan, 2001 L -17; 03 -14 -01 4

Active Networks • Nodes (routers) receive packets: • • Perform computation based on their internal state and control information carried in packet Forward zero or more packets to end points depending on result of the computation Users and apps can control behavior of the routers • End result: network services richer than those by the simple IP service model • © Srinivasan Seshan, 2001 L -17; 03 -14 -01 5

Why not IP? • Applications that do more than IP forwarding • • • Firewalls Web proxies and caches Transcoding services Nomadic routers (mobile IP) Transport gateways (snoop) Reliable multicast (lightweight multicast, PGM) Online auctions Sensor data mixing and fusion Active networks makes such applications easy to develop and deploy © Srinivasan Seshan, 2001 L -17; 03 -14 -01 6

Variations on Active Networks • Programmable routers • • • Active control • • • More flexible than current configuration mechanism For use by administrators or privileged users Forwarding code remains the same Useful for management/signaling/measurement of traffic “Active networks” • • • Computation occurring at the network (IP) layer of the protocol stack capsule based approach Programming can be done by any user Source of most active debate © Srinivasan Seshan, 2001 L -17; 03 -14 -01 7

Case Study: MIT ANTS System • Conventional Networks: • • Active Networks: • • All routers perform same computation Routers have same runtime system Tradeoffs between functionality, performance and security © Srinivasan Seshan, 2001 L -17; 03 -14 -01 8

System Components Capsules • Active Nodes: • • Execute capsules of protocol and maintain protocol state Provide capsule execution API and safety using OS/language techniques Code Distribution Mechanism • Ensure capsule processing routines automatically/dynamically transfer to node as needed © Srinivasan Seshan, 2001 L -17; 03 -14 -01 9

Capsules • Each user/flow programs router to handle its own packets • • • Code sent along with packets Code sent by reference Protocol: • Capsules that share the same processing code May share state in the network • Capsule ID is MD 5 of code • © Srinivasan Seshan, 2001 L -17; 03 -14 -01 10

Capsules Active Node IP Router Capsule IP Header Version Active Node Capsule Type Previous Address Type Dependent Header Files Data ANTS-specific header • Capsules are forwarded past normal IP routers © Srinivasan Seshan, 2001 L -17; 03 -14 -01 11

Capsules Request for code Active Node 1 IP Router Capsule Active Node 2 Capsule • When node receives capsule uses “type” to determine code to run • If no code at node requests code from “previous address” node • Likely to have code since it was recently used © Srinivasan Seshan, 2001 L -17; 03 -14 -01 12

Capsules Code Sent Active Node 1 IP Router Active Node 2 Capsule • Code is transferred from previous node • Size limited to 16 KB • Code is signed by trusted authority (e. g. IETF) to guarantee reasonable global resource use © Srinivasan Seshan, 2001 L -17; 03 -14 -01 13

Research Questions • Execution environments • • Safety, security & resource sharing • • How isolate capsules from other flows, resources? Performance • • What can capsule code access/do? Will active code slow the network? Applications • What type of applications/protocols does this enable? © Srinivasan Seshan, 2001 L -17; 03 -14 -01 14

Functions Provided by Capsule • Environment Access • • Capsule Manipulation • • Access header and payload Control Operations • • • Querying node address, time, routing tables Create, forward and suppress capsules How to control creation of new capsules? Storage • Soft-state cache of app-defined objects © Srinivasan Seshan, 2001 L -17; 03 -14 -01 15

Safety, Resource Mgt, Support • Safety: • • Resource Management: • • Provided by mobile code technology (e. g. Java) Node OS monitors capsule resource consumption Support: • If node doesn’t have capsule code, retrieve from somewhere on path © Srinivasan Seshan, 2001 L -17; 03 -14 -01 16

Performance • User level Java implementation ok for T 1 (1. 5 Mbps) © Srinivasan Seshan, 2001 L -17; 03 -14 -01 17

Performance Based on profile of code Java specific overheads and user level send/receive are bulk of extra overhead • Safe evaluation and type demultiplexing only add 30% overhead • • Other more efficient technologies available • • Software fault isolation (SFI) Proof carrying code (PCC) © Srinivasan Seshan, 2001 L -17; 03 -14 -01 18

Applications/Protocols • Limitations • • • Expressible limited by execution environment Compact less than 16 KB Fast aborted if slower than forwarding rate Incremental not all nodes will be active Proof by example • Host mobility, multicast, path MTU, Web cache routing, etc. © Srinivasan Seshan, 2001 L -17; 03 -14 -01 19

Discussion Active nodes present lots of applications with a desirable architecture • Key questions • • • Is all this necessary at the forwarding level of the network? Is ease of deploying new apps/services and protocols a reality? © Srinivasan Seshan, 2001 L -17; 03 -14 -01 20

Overview Active Networks • Active Services • © Srinivasan Seshan, 2001 L -17; 03 -14 -01 21

Active Service Way of doing “application-level active networking” for a specific domain • Service agents (“Servents”) • • Perform operations like transcoding and multicast-to-unicast conversion in a cluster environment © Srinivasan Seshan, 2001 L -17; 03 -14 -01 22

Components of Architecture • • • Service environment: defines programming model and execution environment Service location: how to locate AS 1 cluster Service management: resource allocation in cluster Service control: how to control servent Service attachment: how to attach a cluster if a client doesn’t have multicast Service composition: not explored © Srinivasan Seshan, 2001 L -17; 03 -14 -01 23

Service Environments at application layer and uses MASH infrastructure • Claim: a good environment is domainspecific as are the APIs • Safety not addressed • • Can leverage work on type-safe languages, etc. © Srinivasan Seshan, 2001 L -17; 03 -14 -01 24

Service Location/Management • How to locate cluster? • • Use mechanism like DHCP (or even DNS) Listen on well-known multicast address for advertisements Static configuration (/etc/X. config) Service Management • This topic is the bulk of the paper © Srinivasan Seshan, 2001 L -17; 03 -14 -01 25

Servent Launching (ASCP) • Uses announce/listen protocol model and no centralized manager • • • Periodically announce set of (key; value) pairs on multicast group Receivers either update, refresh or age entries out of table Error recovery subsumed as part of normal operation Host managers, on per cluster machine, use this to launch servents • Servent floods • • Prevent using multicast damping (random timers/suppression) © Srinivasan Seshan, 2001 L -17; 03 -14 -01 26

Processor Sharing • Use of a birth-death process to grow and wean number of cluster machines • • N is the desired target number of machines and n is the number of actual machines in current operation If n<N, randomly fork copy on an idle machine with probability pl = min(1, N/n-1) And if n>N, kill with probability 1 -N/n Property that no HMs exist can be made exponentially small in the target number © Srinivasan Seshan, 2001 L -17; 03 -14 -01 27

Other Issues • Service Control • • • Service Attachment • • Application specific control In Me. Ga architecture, uses SCUBA (Scalable Consens. Us–based Bandwidth Allocation) to control servents Uses “soft-state gateways” to bridge multicastto-unicast regions Paper describes deployment experience on Berkeley NOW © Srinivasan Seshan, 2001 L -17; 03 -14 -01 28

Discussion Framework for active services in the context of media gateways and real time Mbone applications • Specific to restricted class of applications • Soft-state announce-listen protocols is different from “standard” centralized managers • © Srinivasan Seshan, 2001 L -17; 03 -14 -01 29

Review • Papers present two ways of building flexible networks • • Changes the way IP forwarding is done Works at application layer © Srinivasan Seshan, 2001 L -17; 03 -14 -01 30

Announcements Approximately 1 month to project due date!!! • Final exam on May 8 th – time TBA • No HW 3 • • • Spend extra time on your project Make sure you keep up with reading – it will be critical on exam © Srinivasan Seshan, 2001 L -17; 03 -14 -01 31

Next Lecture: Application Networking HTTP • APIs • Assigned reading • • • [BSR 99] An Integrated Congestion Management Architecture for Internet Hosts [PM 95] Improving HTTP Latency © Srinivasan Seshan, 2001 L -17; 03 -14 -01 32