The case for reliable concurrent multicasting using shared ACK trees

Abstract

Such interactive, distributed multimedia applications as shared whiteboards, group editors, and simulations require reliable concurrent multicast services, i.e., the reliable dissemination of information from multiple sou~es to all the members of a group. Furthermore, it makes sense to offer that service on top of the increasingly available 1P multicast service, which offers unreliable multicasting. This paper establishes that concurrent reliable multicasting over the Intemet should be based on reliable multicast protocols based on a shared acknowledgment tree. First, we show that organizing the receivers of a reliable multicast group into an acknowledgment tree and using NAK-avoidance with periodic polling in local groups inside such a tree provides the highest maximum throughput among all classes of reliable mtdticast protocols proposed to date. Second, we introduce Lomx, which demonstrates the viability of implementing a reliable multicasting approach in the Intemet based on acknowledgment trees in a scalable mannez La-ax is the first known protocol that constructs and maintains a single acknowledgment tree for reliable concurrent multicasting, eliminates the need to maintain an acknowledgment tree for each source of a reliable multicast group, and can be used in combination with any of several tree-based reliable mtdticast protocols proposed to date.

A novel group coordination protocol for collaborative multimedia systems

“…No specific site alone is hence burdened with the obligation to make floor allocation decisions, and tokens can wander freely across the tree branches, without being cast into a specific traversal order other than what multicast group membership expresses. While various tree-based reliable multicast protocols have been proposed for highly scalable conferencing [12,14,24], no group coordination mechanism or applications have been developed yet. The goal for such a protocol is to keep the tree depth minimal, in order to keep the number of hops for control transmissions low.…”

“…In a multicast collaboration session with multiple floors and floor holders, it is not practical to manage separate control trees, one per floor. Similar to the concurrent reliable multicast scheme proposed in [12], we hence assume a single shared control tree with a branching factor B, which can be re-hung as a control tree with any other node as the root and FH, while preserving the property that all nodes have B children.…”

“…We focus on an approach comparable to receiver-initiated multicast [12], which lets contending stations in the group-coordinated session maintain state information about a particular floor. Floor state information can hence be passed along between contending stations, without requiring the controller station to contact each station.…”

“…A construction method for a control tree for group coordination on top of a multicast routing tree is outlined in [12]. A node x in the resulting hierarchical acknowledgment tree, whose edges are directed from children to their parents, is labeled with a unique label lx, which is the prefix of all children of x. Labeling is top-down, and the maximal length of labels in a tree reflects its depth.…”

“…Note that labels in the tree remain constant for the lifetime of the session, except in cases when nodes fail or new nodes join a subtree. Rare cases when relabeling is necessary are discussed in [12]. Adding a node in the tree involves only the new node as a child and its parent, while deletions require relabeling of the subtree of the deleted node.…”