Scribe
======

Why does anyone care about multicast?
  Why not use repeated unicast?
  Why not flood like Gnutella?

What is Scribe model?
  Have a bunch of multicast groups, each with an ID
  For each group, there is a source node, which has closest ID in Pastry
  Form a multicast tree from source node

How does Scribe form its distribution tree?
  Fig 4. for algorithm

Why do the routes from members to rendezvous form a good tree?
  Minimum number of copies / Pastry nodes visited?
  Minimum distance on underlying Internet?

What if a node fails?
  Detection based on messages (or lack thereof):
    Parents required to send heartbeats to children if no traffic
    Children periodically send messages to parent
  How do children re-attach after detecting failure?
    Just join again

How does bottleneck-elimination work?

* Evaluation

What do graphs mean?

Is this a good system?
  Hard to evaluate when you don't have concrete end-to-end application in mind
    E.g., are link stress numbers practical for cable-modem setting?
  But idea is potentially nice, because of how decentralized it is
    If you wanted to deploy this, wouldn't have to involve your ISP

* Problem:  Interior nodes need way more bandwidth than leaf nodes--unfair

Solution:  Splitstream
  Break multicast data into multiple streams
  Want to ensure nodes are interior on only fair share of streams
    Form "interior-node-disjoint" trees:
      All interior nodes share at least one digit prefix with group ID
      So pick k multicast groups s.t. most significant digit of IDs different
  Also want to limit maximum #children of a node
    After a limit, nodes stop accepting children
    Can pass off to other children (like Scribe bottleneck remover)
    Also, special "spare capacity" lets joiner find someone with spare capacity