This is multicast over an overlay network - an obvious goal to go for if you want to create deployable multicast systems because it became clear that the routers in the Internet were unlikely to be updated to support new multicast protocols. The actual implementation of application-layer multicast here is rather complicated, involving creating a tree of clusters of nodes with some mathematical properties about number of levels and number of nodes per cluster. There are even a set of invariants (section 2.4) that must hold. My first thought is, this is way too complicated. You will pay a lot more to keep up such invariants than you would if you had a more organic network. Why not try out something extremely simple first, such as random neighbors and gossip? (Note: this idea was inspired by Ari's blog). Why not just build multiple non-clustered threes? People complained about the DHT papers focusing too much on nice mathematical properties, but those are very unorderly compared to the NICE trees in this paper. Apart from the fact that you'd imagine costs could be lower with a less restrictive topology, the other complication is that maybe there are corner cases when the tree invariants are not kept and cannot easily be restored. It's hard to prove that you've covered all the possibilities about simultaneous leaves and joins.
Apart from this, the paper contains simulations comparing it with another overlay multicast system called Narada and an implementation that ran with ~30 nodes. Having an implementation is good, but the scale is not particularly interesting - at 30 nodes, one can easily have a centralized server. The application considered - low bandwidth data streams - also adds to this since it means that a centralized server or data center may work well even for far more than 30 nodes.
Thursday, November 20, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment