1. TRUST:Team for Research in Ubiquitous Secure Technologies
Secure Information Management Software Tools
Ken Birman (lead)
Anantharam, Bajcsy, Karsai, Lee, McFadden, Samuelson, Sastry, Schmidt, Sztipanovits, Weber, Wicker
NSF STC Review
September 13th 2004

2. The Need: Better Tools TRUST
Software developers depend on complex platforms, and increasingly work by extending or customizing with extra code
Web Services, J2EE, CORBA
Even Microsoft .NET
The quality of these platforms and “tools” is a direct determinant of the quality of their applications and solutions 2
NSF STC Review
September 13th 2004

3. Existing Platforms are Inadequate
TRUST
Existing Platforms are Inadequate
But existing platforms
Scale poorly and can “melt down” under stress
Are insecure; child’s play to disrupt or intrude
Are human intensive to deploy, configure
Are hard to repair when disruption occurs
Are costly to own and operate
Example: publish-subscribe scalability issues within Yahoo, Amazon, other big data centers 3
NSF STC Review
September 13th 2004

4. Why don’t platforms scale?
TRUST
Why don’t platforms scale?
Prevailing client-server communications model, combined with strong reliability goals, impose O(N) delays and O(N2) performance degradation
New technologies offer hope
Based on peer-to-peer interaction styles
Substitute probabilistic objectives for classic deterministic ones 4
NSF STC Review
September 13th 2004

5. Map nodes to affinity groups
Kelips
Map nodes to affinity groups
Affinity Groups:
peer membership thru consistent hash 1 2 1 N -
110 N
230
202
members per affinity group 30

6. 110 knows about other members – 230, 30…
Kelips
110 knows about other members – 230, 30…
Affinity group view
Affinity Groups:
peer membership thru consistent hash id
hbeat
rtt 30
234
90ms
230
322
30ms 1 2 1 N -
110 N
230
202
members per affinity group 30
Affinity group pointers

7. 202 is a “contact” for 110 in group 2
Kelips
202 is a “contact” for 110 in group 2
Affinity group view
Affinity Groups:
peer membership thru consistent hash id
hbeat
rtt 30
234
90ms
230
322
30ms 1 2 1 N -
110
Contacts N
230
202
members per affinity group
group
contactNode … 2
202 30
Contact pointers

8. Gossip protocol replicates data cheaply
“cnn.com” maps to group 2. So 110 tells group 2 to “route” inquiries about cnn.com to it.
Kelips
Affinity group view
Affinity Groups:
peer membership thru consistent hash id
hbeat
rtt 30
234
90ms
230
322
30ms 1 2 1 N -
110
Contacts N
230
202
members per affinity group
group
contactNode … 2
202 30
Resource Tuples
Gossip protocol replicates data cheaply
resource
info …
cnn.com
110

9. Gossip protocol replicates data cheaply
Kelips
Lookup is routed by a contact node in group 2, then handled by node 110
Affinity Groups:
peer membership thru consistent hash 1 2 1 N -
110 N
230
202
members per affinity group 30
Gossip protocol replicates data cheaply

10. Astrolabe: Scalable Monitoring Infrastructure
Astrolabe: Scalable Monitoring Infrastructure. Captures system state hierarchically, using P2P protocol that “assembles a puzzle” without any servers
Dynamically changing query output is visible system-wide
SQL query “summarizes” data
Name
Avg Load
WL contact
SMTP contact SF
2.6
ITH
1.8
Paris
3.1
Name
Load
Weblogic?
SMTP?
Word Version …
swift
2.0 1
6.2
falcon
1.5
4.1
cardinal
4.5
6.0
Name
Load
Weblogic?
SMTP?
Word Version …
gazelle
1.7
4.5
zebra
3.2 1
6.2
gnu .5
Ithaca
San Francisco

11. Our team has many ideas like the two you’ve seen
TRUST
Our team has many ideas like the two you’ve seen
We’re challenging assumptions industry accepts as dogma (like client-server structure)
Building real solutions that really work
And finding ways to apply them in critical infrastructure settings
For example, we’ve worked with EPRI to explore applications of Astrolabe and Kelips to monitoring the electric power grid
Poor monitoring contributed to ’03 blackout 11
NSF STC Review
September 13th 2004