Review - A Reliable Multicast Framework for LWS and ALF

From: Ivan Hernandez <ivanxx_at_gmail.com>
Date: Mon, 30 Oct 2006 18:42:05 -0500

Review of A Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing
by Ivan Hernández

The paper presents a framework for Scalable Reliable Multicast (SRM)
for Light-Weight Sessions. SRM is designed to guarantee eventual
delivery of all the data to all the group members by making each
member responsible for its own correct reception of all the data. This
reliability is built on an end-to-end basis, without any special
support from the underlying IP network. The authors give a little
description of multicast, and then, they describe problems and
challenges that arise when is required to add loss detection and
recovery to a multicast service.

The authors provide a generic reliability framework that can be
tailored to suit particular applications requirements. In general each
application provides a namespace to talk about the data that has been
sent and received (one assumption is that the data has unique and
persistent names) and a series of details to determine how much
bandwidth is available to the group as a whole and how this bandwidth
are going to split this bandwidth. Next, the authors describe the
framework using a particular network conferencing tool called wb. All
members of a multicast group are able to multicast to the group.

The framework works as follows. Whenever a member generates new data,
the data is multicasted to the group. Each member of the group is
individually responsible for detecting loss. Additionally, each member
multicast periodic session messages that provide information regarding
to the information received from every member, these messages are sent
only if there is no other message in the network with similar
information, this helps to keep the control messages low. On the other
hand, repair request and retransmissions are always multicasted to the
whole group; if two nodes missed a message, the first one that request
a repair is the only one that will send the repair message, when the
other node listens the repair request of the other node it will
recognize that is a request for the same information and it suppress
its request, because the retransmission will get all nodes in the
multicast group. For retransmissions the protocol works in the same
way. The authors claim that reliable data delivery is ensure as long
as each data item is available from at least one member.

I found the paper interesting, nevertheless there are some points that
I would like to discuss. First, there is no discussion about the
mechanism to decide who is going to keep what data items in order to
ensure reliable data delivery; moreover, what happens if the node
responsible for some data items either goes off line or crashes;
another problem that arises in the wb implementation is when corrupted
data is used to answer repair requests, this data is distributed
throughout the multicast group. The authors show a discussion of the
request repair algorithms on simple topologies, but is not clear to me
that the presented scenarios are representative of general use
cases. The authors show that there is no a general parameter setting
for the algorithms that provide optimal performance for all
topologies, sessions, membership and loss patterns, therefore they
provide an adaptive algorithm to adjust it's parameters, nevertheless,
they do not show the simulations that the authors say "Simulations in
[13] show that the adaptive algorithm works well in a wide range of
conditions", I think that show this simulations instead that the
discussion on simple topologies would have been more worthy. There are
two topics that are not solved by the framework these are rate control
and data ordering mechanism. Finally, the proposed solution is tightly
coupled with the wb application, thus its initial claim that the
framework that can be tailored to suit particular applications
requirements is not clear to me.
Received on Mon Oct 30 2006 - 18:42:13 EST

This archive was generated by hypermail 2.2.0 : Mon Oct 30 2006 - 20:12:15 EST