A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing

I had dreaded this set of readings because I disliked the multicast papers on the network prelim reading list, but this paper is actually pretty well-written. It explains why reliable multicast has to be solved differently from reliable unicast and pushes for receiving more semantics from the application (application-level framing). It explains that a one-size-fits-all reliable and ordered model is infeasible. It also motivates the work with a real application, wb, which manages to build a useful service from idempotent operations and reliable but unordered multicast. Finally, there is a lot of analysis of how to implement retransmission requests and recovery without imploding the sender through randomized backoffs. Although the simulations and analysis are not on Internet topologies, they do cover some "extremes" such as a chain or a star, so they are fairly believable. The most important point in the paper, in my opinion, is the recognition that different applications require different things from multicast, which leads the authors to build a simple base for reliable multicast protocols rather than trying to design a one-size-fits-all solution. This is reminiscent of how IP provides a simple service model over which more complex ones can be built by the application.

Of course the elephant in the room with all this is that multicast on the Internet is pretty much not present today. There seem to be three reasons: First, doing it in hardware would have required massive hardware changes, and nobody agreed how it really should be done. Second, and more importantly, providers didn't know how to charge for multicast! Not many papers address this. Third, we've managed to do all our multi-user communication stuff using central servers. You can get wb today: it's just all running in one data center, and you're accessing it through HTTP. The cost of building a central server is so small and the benefits in manageability, upgradeability, etc are so large that nobody has chosen to do the peer-to-peer whiteboard instead. We do see some peer-to-peer multicast communication for other applications, most notably multiplayer games (where relaying commands through a central server hurts latency), but these have few enough players that using all-pairs communication solves the problem. So SRM fits into that category of interesting ideas that lack implementation details and motivation.