Sponsored by the National Science Foundation SCAFFOLD Spiral 2 Year-end Project Review Princeton University Michael Freedman (PI), Jennifer Rexford (co-PI) Erik Nordstrom, Steve Ko (Postdocs) Matvey Arye, Prem Gopalan, David Shue, Wyatt Lloyd (Students) August 27, 2010

Sponsored by the National Science Foundation 2 Project Summary SCAFFOLD is a software platform and network architecture for simplifying the design and deployment of services –Service-centric network with a new socket API Apps see service id’s, but not network addresses. Network sees both. –Replication: Service-level anycast with flow affinity Network support: Separate name resolution/routing for new flows and forwarding to known replicas for bound flows Host support: Accept unbound flows, bind to local address for affinity –Dynamism Tighter network integration: Host/service availability reprograms network In-band address renegotiation: Failover/migration w/o per-flow network state Medium-term vision: Network support for self-config of replicated services? Long-term vision: “Service-centric networking” as new thin waist of Internet? August 27, 2010

Sponsored by the National Science Foundation 3 Milestone & QSR Status IDMilestoneStatusOn Time?On Wiki? GPO signoff? S2.aDemo switch: Demonstrate OpenFlow- based SCAFFOLD switch and minimal L2 network config (client, server, static switch) Demonstrated.On timeYesDone S2.bDatagram code: SCAFFOLD datagram socket API for UNIX Code delivered with accompanying docs. On timeYesDone S2.cDemo Server: NOX-based rendezvous server and minimal L2 network configuration Demonstrated in 3-page technical report with eval. On timeYesDone S2.dStream code: SCAFFOLD stream socket API for UNIX Code delivered with accompanying docs. On time (renegotiated) / 1 mo late YesDone S2.eMulti server: M ulti-server SCAFFOLD network within L2 domain: client, multiple servers (part of same SCAFFOLD group), switch, rendezvous Demonstrated.EarlyYesDone S2.fBasic stateless server: Transparent migration/recovery of application TCP flows (e.g., HTTP transfers of static content) in unmodified legacy applications and unmodified clients Code delivered, functionality demonstrated in 14-page tech report. On time (renegotiated) / 1 mo late YesDone August 27, 2010

Sponsored by the National Science Foundation 4 Accomplishments 1: Advancing GENI Spiral 2 Goals SCAFFOLD is both platform and application –Application: Distributed service on GENI platform (& exercises aggregates) –Platform: for deploying other user-facing services on GENI –Year 1 of multi-year project, current focus on significant “app” development Current prototype: –New network stack: ServiceID-based TCP/UDP thru BSD-like socket API –Changes to NOX to integrate endhosts: Socket calls translate to NOX events, which reprogram network switches –Changes to OpenFlow: Match on multiple rules and support anycast –Ported apps: UDP (iperf, tftp, opendns, memcached), TCP (elinks, mongoose) –Deployment in single rack at Princeton: 1 NOX, 1 “service router” for anycast, 3 label routers, 8 endhosts Testing framework to instantiate topologies of hosts, service/label routers, links,… August 27, 2010

Sponsored by the National Science Foundation 5 Accomplishments 1: Advancing GENI Spiral 2 Goals Once deployed, SCAFFOLD will enable: Stress-testing of existing GENI prototypes: Current prototype uses enterprise GENI kits (OpenFlow/NOX). Wide-area plans with Transit Portal (BGPMux). Once deployed, GENI control aggregates for slicing. Easing the deployment of new wide-area services: SCAFFOLD would lower the barrier for deploying user-facing services on GENI. Primarily support Spiral 2 goal of continuous experimentation, through deep programmability of network/host resources and slicing of resources for multiple tenants running on SCAFFOLD simultaneously. August 27, 2010

Sponsored by the National Science Foundation 6 Accomplishments 2: Other Project Accomplishments Community evangelizing –Presentation of poster and PlanetLab cluster talks at GEC-6, -7, -8 Exposure of both faculty and postdocs to GENI –Talks at Stanford, HP Labs, Google, and forthcoming at Vancouver Systems Colloquia (attached to OSDI ‘10) Undergrad participation: Kay Ousterhout and Andrew Gwozdz Feedback to OpenFlow about requirements for next-generation –GRE tunneling to NOX (now in openvswitch) –Hashing on bits, multiple rule matching and anycast –Flexible packet formats and packet rewriting August 27, 2010

Sponsored by the National Science Foundation 7 Issues Technical Desirable platform for SCAFFOLD and deploying services –Smaller number of larger (homogenous) clusters –Each cluster with multiple upstream providers to public Internet Commercial OpenFlow hardware (and OF 1.0) lacks needed features –Our implementation thus uses OpenVSwitch software with modifications Clarification of licensing (e.g., kernel mods and research not directly funded) Operational Ability to renegotiate milestones as goals change GENI resource deployment and allocation policies –What resources will be available and when? (App) researchers need long-term planning –Example: What will be available for “long-term, best effort” vs. “short term, guaranteed”? –SCAFFOLD implications: How we sell SCAFFOLD/GENI deployment to potential users –Lack of systems audience at GEC for “requirements gathering” August 27, 2010

Sponsored by the National Science Foundation 8 Plans Spiral 2 Continue with specified goals: More robust platform for local-area SCAFFOLD deployment of hosts, routers, controllers, and apps Spiral 3 “Application development” of SCAFFOLD will continue for at least another year, as we slowly turn to “platform development” and make SCAFFOLD available to other GENI researchers Spend more time with “requirements gathering” from systems researchers at GEC conferences, to direct future development August 27, 2010