1 / 35

In VINI Veritas Realistic and Controlled Network Experimentation

In VINI Veritas Realistic and Controlled Network Experimentation. Andy Bavier Nick Feamster* Mark Huang Larry Peterson Jennifer Rexford. Princeton University *Georgia Tech. How to Validate an Idea?. Emulation. VINI. Fixed, shared among many experiments

ryann
Download Presentation

In VINI Veritas Realistic and Controlled Network Experimentation

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. In VINI VeritasRealistic and Controlled Network Experimentation Andy Bavier Nick Feamster* Mark Huang Larry Peterson Jennifer Rexford Princeton University *Georgia Tech

  2. How to Validate an Idea? Emulation VINI • Fixed, shared among many experiments • Runs real routing software • Exposes realistic network conditions • Gives control over network events • Carries traffic on behalf of real users Simulation Small-scale experiment Live deployment

  3. Scientific Value The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’ (I found it!) but ‘That’s funny …’ -- Isaac Asimov • Move off the emulator, into the wild • Opportunity for more ‘that’s funny’ moments • Avoid “Fallacy of Misplaced Concreteness” • Simulation and emulation are important tools • Modeling abstracts general properties from reality • Philosophy: the devil may be in the details… • But insights and soundness are found there too

  4. Traffic Synthetic or traces Real clients, servers Arbitrary, emulated Synthetic or traces Actual network Real clients, servers Topology Traffic Inject faults, anomalies Observed in operational network Network Events “Controlled Realism” • Start with a controlled experiment • Relax constraints, study effects • Result: an operational virtual network that’s • Feasible • Valuable • Robust • Scalable, etc.

  5. Overview • VINI requirements • Fixed, shared infrastructure • Flexible network topology • Expose/inject network events • External connectivity and routing adjacencies • Strategy for building VINI • PL-VINI: prototype on PlanetLab • Experimental results • Timeline

  6. Fixed Infrastructure Deploying VINI nodes in National LambdaRail, Abilene with Gigabit links

  7. Shared Infrastructure Experiments given illusion of dedicated h/w

  8. Flexible Topology VINI supports arbitrary virtual topologies

  9. Network Events VINI exposes, can inject network failures

  10. c External Connectivity s Experiments can carry traffic for real end-users

  11. BGP BGP c BGP BGP External Routing Adjacencies s Experiments can participate in Internet routing

  12. PlanetLab  VINI • Build VINI from PlanetLab, a global testbed for distributed services • Begun in 2002 • 700 nodes at 336 sites in 35 countries • 600 projects and 2500 researchers • Serves 3-4 TB/day to ~1M clients • MyPLC: PlanetLab software distribution • Anyone can run their own private PlanetLab

  13. PlanetLab Experiments • Simultaneous experiments in separate VMs • Each has “root” in its own VM, can customize • Reserve CPU, network capacity per experiment Node Mgr Local Admin VM1 VM2 VMn … PlanetLab node Virtual Machine Monitor (VMM) (Linux++)

  14. PL-VINI: Prototype on PlanetLab • Feasible?  prototype on public PlanetLab • Enable experiment: Internet In A Slice • XORP open-source routing protocol suite (NSDI ’05) • Click modular router (TOCS ’00, SOSP ’99) • Clarify issues that a VINI must address • Unmodified routing software on a virtual topology • Forwarding packets at line speed • Illusion of dedicated hardware • Injection of faults and other events

  15. PlanetLab VM XORP: Control Plane XORP (routing protocols) • Goal: real routing protocols on virtual network topologies • BGP, OSPF, RIP, PIM-SM, IGMP/MLD • XORP can run in a PlanetLab VM

  16. PlanetLab VM User-Mode Linux: Environment UML XORP (routing protocols) • Interface ≈ network • PlanetLab limitation: • Experiments cannot create new interfaces • Run routing software in UML environment • Create virtual network interfaces in UML eth0 eth1 eth2 eth3

  17. PlanetLab VM Click: Data Plane UML XORP (routing protocols) • Performance • Avoid UML overhead • Move to kernel, FPGA • Interfaces  tunnels • Click UDP tunnels correspond to UML network interfaces • Filters • “Fail a link” by blocking packets at tunnel eth0 eth1 eth2 eth3 Control Data Packet Forward Engine UmlSwitch element Tunnel table Click Filters

  18. Resource Isolation • Issue: Forwarding packets in user space • PlanetLab sees heavy use • CPU load affects virtual network performance

  19. Intra-domain Route Changes s 2095 856 700 260 233 1295 c 639 548 366 846 587 902 1893 1176 Watch OSPF route convergence on Abilene

  20. Link down Link up Routes converging Abilene RTT: 73ms Ping During Link Failure

  21. Link down Link up Zoom in TCP Throughput

  22. Slow start Retransmit lost packet Arriving TCP Packets PL-VINI enables a user-space virtual network to behave like a real network on PlanetLab

  23. Attracting Real Users • Could have run experiments on Emulab • Goal: Operate our own virtual network • Carrying traffic for actual users • We can tinker with routing protocols • We expect that: • PlanetLab services will subscribe to VINI network architectures to access Gb/s • Experiments will advertise routes via BGP

  24. You are here Fall 2006 2007 2008 • PL-VINI • PlanetLab • Resource resv • CPU priority • NLR-VINI • Abilene-VINI • PCs • PlanetLab OS • MyPLC • Gigabit layer 2 • eBGP uplinks • to friendly ISPs • NLR-VINI • Abilene-VINI • Japan-VINI • PCs • VINI OS • MyVINI • Xen • Exchange traffic • with ISPs • NLR-VINI • Abilene-VINI • Japan-VINI • ???-VINI • Other GREN • PC + FPGAs, NPs • Create layer 2 • “on the fly” Timeline Other features?

  25. The End • Questions?

  26. The End • URL: http://www.vini-veritas.net • Questions?

  27. Backup slides

  28. Conclusion • VINI = evolution of PlanetLab • Installing VINI nodes in NLR, Abilene • Download and run Internet In A Slice • MyPLC  MyVINI as code diverges • Build, run, modify your own VINI • We expect there to be many VINIs http://www.vini-veritas.net

  29. Timeline • Conclude with a timeline instead? Like the one for Gibson. • Experiments on the top, infrastructure on the bottom, “You are here.” • Today: IIAS, PL-VINI • Next: RCP, VINI-NLR • What other experiments?

  30. Ongoing Work • Improving realism • Exposing network failures and changes in the underlying topology • Participating in routing with neighboring networks • Improving control • Better isolation • Experiment specification

  31. Performance is bad • User-space Click: ~200Mb/s forwarding • Can do a lot with 200Mb/s • 20 experiments can have dedicated 10Mb/s nationwide networks • Improving performance is ongoing work • Allow experiments to load custom Click modules into the VINI kernel

  32. PL-VINI Summary

  33. PL-VINI / IIAS Router UML XORP (routing protocols) • XORP: control plane • UML: environment • Virtual interfaces • Click: data plane • Performance • Avoid UML overhead • Move to kernel, FPGA • Interfaces  tunnels • “Fail a link” eth0 eth1 eth2 eth3 Control Data Packet Forward Engine UmlSwitch element Tunnel table Click

  34. What’s New with VINI? • Integration of routing w/Internet • Better isolation • Real topologies • Inject events

  35. Traffic Synthetic or traces Real clients, servers Arbitrary, emulated Synthetic or traces Actual network Real clients, servers Topology Traffic Inject faults, anomalies Observed in operational network Network Events “Controlled Realism” • Control: • Reproduce results • Methodically change or relax constraints • Realism: • Long-running services attract real “customers” • Forward high traffic volumes (Gb/s) • Robustly handle unexpected events

More Related