Barriers to Disruptive Innovation:Greater in Wireless or Wired Worlds?

…and reflections on Emulab

Jay LepreauUniversity of Utah

NSF WMPG WorkshopAugust 2, 2005

2

“Yes”

(many of the barriers are different)

3

Differences

ResearchDevelopmentRegulationLegal systemCommercial landscape

4

Technical

Inherently geographically localizedWireless (+)– Bounded scale– Natural boundary enables autonomy:

administrative, architectural, namespaces, security, problem diagnosis

Wireless (-):– Costly production testbeds unavailable to many

distant researchers

5

Research

Wireless (+, -)Limited bandwidth– Can’t just overprovision: more constraints,

more good problems (+)– Bandwidth problems may distract from more

interesting/important ones (-)

6

Research

Wireless (+)Link layer research is trivially enabled by SDR (USRP, SoftMAC, …)

Wireless (-)Many wireless devices are mobile and

untethered, for which SDR is poor (energy)

7

Research

Wireless (+)Testbeds which offer real marginal value to users are more likely in wireless– Wired typically can only offer BW or security

Hard to beat the Internet except for eScience

– Consider a city or campus with 10,000 coolwireless gadgets.

8

Regulatory & Legal

Spectrum regulation– Wireless (-)

Limited availability of open spectrumLicensing barriers• Research-, Deployment-, Impact-

– Wireless (+)There IS open spectrum!More may be coming.

9

Commercial Landscape

Wireless (-)Dominated by a few commercial providers who control the edge (~billion phones?)– Their (simple?) base-station architecture

dominates anything from our community– Unlike historic PSTN, also true of growth

rates

10

Observation: Federation is Crucial

In network architecturesIn experimental infrastructures

Need Administrative AutonomyNeed Architectural Autonomy

11

Emulab experience…

12

Emulab: It’s Real

Doing it for 5 years, in production 24/7~200 (-> 360) physical cluster nodes todayRecent 12 month period:– 13,613 “virtual clusters” created– 166,519 physical nodes loaded, configured>1000 active users, >150 institutions

13

It’s Big

> 400,000 LOC– Growing ~80K/year

14

Emulab Installations

10 now, 6 in progress

In production– Utah, Kentucky, Georgia Tech, Wisconsin, DETER ISI, Aerospace(2),

Uniten Malaysia, UBC, DETER UCB/extensionIn progress– Cornell, UT-Austin, KISTI S. Korea, SPARTA(2), Vanderbilt/Telcordia,

Ft. Monmouth?Planned– Special: Caltech (optical, real routers)– Wireless: MIT?, …

Maybe: Brazil, …

15

Current Device “Backends”PCs, VLANsWide-area FreeBSD nodes (RON, Utah)– Internet paths

Multiplexed VMs and links/LANs (virtual nodes & links)Simulated nodes and links/LANsPlanetLab virtual machines *Intel IXP1200 network processors802.11 a/b/g wirelessCisco routers: preconfigured scenarios (Wisconsin)Intel Stargates (ipaq-like) Motes: emotes, stargate motesRobots: GarciaSoftware Radio: “Universal Software Radio Peripheral” *

16

Future BackendsFirst-class layer 2 devices (for Telcordia/Vanderbilt DARPA)(Attenuated) 802.11 for mobile robots

IXP2400s – we have 20CMU’s FPGA-based wireless emulatorBetter support for commercial routers, optical gear– Wisconsin, Utah, DETER, Caltech

Generic clusters

17

But!

Little use of any devices except– PCs, VLANs– Virtual machines, multiplexed links– Widearea (RON) nodes– Some WiFi

18

Why?NewNot well advertisedInsufficient quantity of many new device typesAccidents of history and timingNot our community– Poor instincts?– Who we know? (advertising)

… Other communities don’t want to test in real life?

19

It’s Software!

A portable “operating system” for controllingexperimentation in networks and distributed systems

20

The Good News

Emulab is a portable, device-independent “OS” for controlling testbeds of networked devices… “devices” of all sorts: 12 types today: from PCs to virtual machines to wireless links to PlanetLab nodes to motes to software radios to high security

Dynamically reconfigurable. General-purpose testbed. Production system with huge usageWe solved many hard problemsNew neat stuff possible, making it even better for test, measurement, and development

21

Backup: Emulab abstractions

22

Common Abstractions,Map to Diverse Mechanisms

Nodes– Machines, VMs, Accts, Slivers

Addresses– IPv4, ns nodeid, …

Links– VLANs, tunnels, Internet paths,

multiplexed link, virtual link

TopologyTopology generatorsQueuesQueuing disciplinesRouting

ApplicationsTraffic generators

Control channel/netSync, startup, replayEventsViz of topology and trafficMonitors on links, nodes

“Experiment” and life-cycleAdmin entities

23

Common Abstractions (cont’d)

“Experiment”– Config, active entities– Life cycle– Default environment– Customization:

• Per-expt• Per-node• Per-run

– Hard state– Soft state– Initial/clean state

Restart– Node, Apps, Traf gens, events

Projects

Users– PI, TA/lieut, members– Credentials (keys)

Experiments