QuickSilver Scalable Multicast

1
QuickSilver Scalable Multicast

• Thinking beyond Web 2.0

Krzysztof Ostrowski, Ken Birman Cornell
University krzys,ken_at_cs.cornell.edu
2
Agenda

• Research vision
• Publish-Subscribe Services
• Experiences building a pub-sub engine
• Making it scalable (protocols)
• Making it fast
• The price of running in a managed environment
• A perspective on
• Web, OS interface, .NET CLR, Visual Studio

3
The Vision
4
(No Transcript)
5
(No Transcript)
6
Publish-Subscribe Services (I)
7
Publish-Subscribe Services (II)
8
New Style of Programming

• Topics Objects
• Topic x Internet.Enter(Game X)
• Topic y x.Enter(Room X)
• y.OnShoot new EventHandler(this.TurnAround)
• while (true)
• y.Shoot(new Vector(1,0,0))

9
(No Transcript)
10
Typed Publish-Subscribe
11
Operating System Embedding
12
Technology Needs

• Scalability ? in multiple dimensions nodes,
  groups, churn, failure rates etc.
• Performance ? full power of the platform
• Reliability ? consistent views of the state
• Embeddings ? easy and natural to use
• Interoperability ? integrating different systems,
  modularity, local optimization

13
(No Transcript)
14
QuickSilver Scalable Multicast

• Simple ACK-based reliability property
• Managed code (.NET, 95C, 5MC)
• Entire QuickSilver platform 250 KLOC
• Throughputs close to network speeds
• Scalable in multiple dimensions
• Tested with up to 200 nodes, 8K groups
• Robust against a range of perturbances
• Free www.cs.cornell.edu/projects/QuickSilver/QSM

15
Making It Scalable
16
Separation of Concerns
17
Scalable Dissemination
18
Regions of Overlap
region set of nodes with similar membership
19
Mapping Groups to Regions (I)
20
Mapping Groups to Regions (II)
21
Scalable Recovery
22
Hierarchy of Protocols (I)
23
Hierarchy of Protocols (II)
24
Key Insights

• Sharing work between groups
• No free lunch gt so we exploit regularities
• Hierarchy of protocols
• Scalability, reuse of protocols
• Can apply to various protocols!
• Used in QS/2, and in a new approach to web
  services pub-sub we proposedwww.cs.cornell.edu/
  krzys/ostrowski-notification.pdf

25
(No Transcript)
26
Hierarchy of Protocols (III)

• Make decisions where they matter, such as
• Picking a protocol,
• Setting timeouts,
• Etc.
• Can optimize!!!

27
(No Transcript)
28
latencies 10..25ms
192 nodes x 1.3 GHz CPUs 512 MB RAM100 Mbps
network
1000-byte messages (no batching), 1 group
29
(No Transcript)
30
Making It Fast
31
Is a Scalable Protocol Enough?

• So we know how to design a protocol
• but building a high-performance pub-sub engine
  is much more than that
• System resources are limited
• Scheduling behaviors matter
• Running in managed environment
• Must tolerate other processes, GC, etc.

32
(No Transcript)
33
(No Transcript)
34
(No Transcript)
35
(No Transcript)
36
Observations

• In managed environment memory is costly
• Buffering, complex data structures etc. matter
• and garbage collection can be disruptive
• Low latency is the key
• Allows to limit resource usage
• Depends on the protocol
• but is also affected by GC, applications etc.
• Cant be easily substituted

37
(No Transcript)
38
(No Transcript)
39
Pull Protocol Stack
40
Cooperative Caching
41
(No Transcript)
42
Threads Considered Harmful
43
Our Time-Sharing Policy
44
Our Priority-Based Processing
45
What the Runtime Could Do (I)

• Pull networking
• Sockets with Pull interface
• Sockets with Rate/Concurrency Control
• Priority I/O
• Assign priorities to channels
• Assign priorities to object types
• Fast serialization
• Lightweight scatter-gather

46
What the Runtime Could Do (II)

• Customizable Scheduling
• Support event-based processing
• Assign priorities, quanta to types of events
• Provide real-time guarantees
• Let the user customize it
• Non-Blocking Synchronization
• Missing primitives
• Event-based multithreaded cooperating
• Marshaling isnt acceptable

47
What the Runtime Could Do (III)

• More Friendly GC
• Private buffer management?
• Synchronize with scheduling

48
Conclusions

• Pub-sub services could be breakthrough
• web pages gt interactive virtual worlds
• web browser gt game console
• web services gt distributed interactive content
• And it can be done!
• We can build a fast, scalable, reliable engine
• but we need help
• Need better .NET
• Need language, shell, system embeddings