1

Thoughts on aNew Research Agenda for

Systems

Randy H. Katz, Dave Patterson, Ion Stoica, Doug TygarComputer Science Division

Electrical Engineering and Computer Science DepartmentUniversity of California, Berkeley

Berkeley, CA 94720-1776

2

Berkeley Approach toSystems Research

• Find important problem spanning system layers, with actual prototype at project end, with potential for high impact if successful (usually started in a grad course)

• Assemble band of 3-6 faculty, 12-20 grad students, 1-3 staff to tackle it over 4-5 years

– Large enough group to span areas of expertise, each prof can define own piece of project, small enough to coordinate and share the wealth, essential that this project be main focus of their research activity (pig vs. hen’s interest in the bacon and eggs breakfast)

– Students get known by more than one or two professors—important for job letters!– Select mostly younger grad students, leaven with some senior students

• Meet twice a year for 3-day retreats with invited outsiders– Builds team spirit, advice on direction, change course– Offers milestones for project stages– Grad students give 6 to 8 talks, become Great Speakers

• Write papers, finish prototype, get PhDs, jobs• End of project party, reshuffle faculty, go to 1• 10 year reunion

3

RAID 10 Year Reunion(January 2003)Profs Industrial

Researchers

Industry

Retired

Still here after allthese years!

Start-ups

4

Pain Points

• Bottleneck is NOT performance• Reliability an unsolvable problem

– System failures will happen—how to make failures less disruptive?

• Increased network interconnection has made systems more valuable but also (much) more vulnerable

– Break-ins, denial of service, spam, …

• Bottleneck is system management complexity– Why are end systems so hard to configure or upgrade?– Why are networks so difficult to configure and manage?– Many system vulnerabilities due to misconfigurations or

incomplete configurations– Huge state, complex interactions, unintended consequences, too

many tuning knobs, …

• Getting worse over time, NOT better• Is an interdisciplinary approach yielding a new

approach possible?

5

Technical Building Block“Mobile Internet Edge”

HW supports scaled monitoring/measurement for allocation of resources, network management, charging, …

Content optimization, policy-based filtering, security & authentication, session/content/location/subscriber-aware

6

Randy’s Technical Trend #1:Scalable Processing Inside the

Network• Scalable server architectures well understood• BUT strategic placement of services to servers

embedded in Internet Data Centers inside the network– Latency to client– Bulk transfer bandwidth from publisher– Multiple copies for load balancing, redundancy– Awareness of abstracted network topology and connectivity

• New processing appliances for scaled, application or service-specific processing

– From firewalls to session personalization, billing, etc.– What other services/applications enablers can be programmed in

this way?

• Why leave the configurations to the end system?– Can you trust the infrastructure to do the right thing?

• Programming model innovations vs. protocol innovations?

7

Single LocationNetwork Operator

(SLN)Single LocationNetwork Operator

(SLN)CooperativeNetworking

Full ServiceNetworkOperator

Full ServiceNetworkOperator

Challenge: Single Operator vs. “Virtual” Composed

Operator

Premises-basedAccess

Full ServiceNetworkOperator

Single LocationNetwork Operator

(SLN)

SLN Aggregator

WISP Aggregator

RevenueSharing

Single Sign-onUnified Billing

Billing, ECommerceAuthentication

Inter-site Mobility

Private Brand NetOperator (MVNO)

VPN Operator, Client-Software

8

Randy’s Tech Trend #2:Spanning Many Admin/Service

Domains• Multipolar vs. Unilateral World

– No preestablished trust relationships among entities (like peer-to-peer systems)

– Single authentication/authorization infrastructure unlikely

– Composition/interoperation architecture rather than a single all encompassing architecture

• Need for more flexible monitoring and managing resource usage

– Monitoring component as fundamental element of system architecture

– Or building block tool for applications and services– Who monitors the monitor?

» Especially when it is used for resource allocation and charging!

» Verification revisited

9

Challenge: Multiple “Operators”

Coordination Issues• Top-Down vs. Bottom-Up Network Deployment

– Operator vs. aggregator/virtual operator models– Neighborhood cooperative mesh networks

• Security– Blurring of distinction between public & private networks:

rogue APs – Interoperation among service/access providers– End-to-end considerations in untrusted infrastructure– Authorization and billing for multi-party services

• Resource Management– Unlicensed but ignore coordination at the cost of performance– Radio resource planning and allocation

• Service creation and personalization platform– Intelligent edge services: service and policy management, user

mobility and profiling, charging and billing

10

Security/Availability Issues

• Architecture must span firewalls while supporting VPNs

– Burden of multiple passwords and access rights– Support for authentic visitors inside enterprise networks

• Content security– Digital rights management

• Achieve network availability in the face of active attacks, misconfigurations, and scale of activity

– Misconfiguration as dangerous as active attacks– Intrusion Detection: monitoring for suspicious traffic

11

Implications

• Workability/evolvability more critical than raw performance

• Process/observe individual flows/sessions at enormous scale

– Observe and adapt—at the edges and inside the network» Automated configuration and network management?

– Which intermediates do you trust? Delegation to infrastructure?– New programming model? New correctness conditions? New

verification approaches?

• Topology awareness to allow processing to placed where needed, to manage latency and introduce redundancy to enhance robustness

– Discovery, qualification, insertion of functionality into infrastructure– Who is allowed to do this? Trust Model? Programming model?

• Make “services” work at policy/control level across much larger number of independent entities (servers, access network operators, service providers, etc.)

12

Discussion

• New research agenda– New principles of distributed system design?– Distributed apps built from services across the

network

• Concrete next steps: common meeting time, seminar, etc.

• Your thoughts?• Tuesday night Industry Open Mic session• Wednesday AM session