Subject: FW: Adding reliable transport layer above sgm/xcsat

From: "Dave Oran" <[email-masked]>
Date: Tue, 15 Aug 2000 20:41:54 -0400

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Tal Anker
Sent: Tuesday, August 15, 2000 7:27 AM
To: [email-masked]
Cc: [email-masked]
Subject: Adding reliable transport layer above sgm/xcsat

Hi,

We would like to share some thoughts on the benefit from the xcast
model (or sgm) to small group multicast applications. In particular,
we have been playing with reliable multicast transport layers in the
last few years. A reliable transport for small group multicast may not
be important for video conference application, but for other
collaborative application such as shared editor or shared drawing
board (whiteboard) it may be very usefull. Since the reliable
multicast working group concentrate (for now) on one-to-many within
the SSM architecture, this issue may fit to this
working group.  

To trigger a discussion, we have comprised a list of issues that come up
when implementing reliale transport layer for multicast:

1) Fault detection - in xcast this is pretty simple to handle. In
large groups, the need to probe for liveness of every member is a
problem for the scalability proporty. In xcast, it becomes much simple
to handle. For instance every source can "ping" the liveness of all
the receivers in the members list, which leads us to the next item:

2) Dynamic Group Membership - In xcast every source is requested to
know the members list apriori. In general, learning the potential
group of members is a chalange. Special challange is the aggreement on
the "view" of the group - i.e., aggreement on the active members list.
In xcast, leader based or token based algorithms can be easily used.

3) Messages ordering - This is a problem that was discussed in various
forums and communities. Ordering is an important property for various
applications, such as distributed database applications or shared
whiteboards, etc. Typicall applications in xcast may not require a
full fledge database consistency requirements, but will certainly
benefit from various ordering properties. In particular, consider a
shared editor or whiteboard that a small group of participants
use. Consider scenarios where someone deletes an object fron the
drawing board, and another is moving the object around. An ordering
property (such as Total ordering) can resolve these conflicts
relatiely easily. We think that the xcast model alleviates the
deployments of ordering algorithms. For instance, logical "token based"
algorithms or leader based algorithms are very feasible for
implementation in the xcast model.

4) Buffering messages for retransmissions: When the group is small,
there is no real prolem in "saving" messages for later
retransmissions. This may not be nessary for video conferencing, but
wheh the conference is coupled with shared text editor or shared
drawing board, the two latter applications are sure to benefit from
this kind of reliability.

5) Flow control for small group multicast: We think that flow control
for small groups is a much easier problem to solve. For instance, one
can even think on maintaining a sliding window per receiver (from the
source point of view). 

6) Handling leave/join of members: When a new member joins the group,
the fact that the group is of small size makes it easier to build a
"digest" of the group state and transferring this digest to the
newcomer. The convergence of the group membership changes is much
faster.

7) handling network partitions/merges: In case there is a link that
has failed, some of the group members may be temporary
partitioned. This calls for the reliability layer to adapt to such
cases, and do not try and attempt recovering/retransmitting messages
that were sent within each partition. This is a sort of a "can of
worms" and is heavily discusses within the area of Group Communication
Systems. We suggest to put it away at this time. In any case, in small
groups there is a high chance that a sort of temporary "relays" can be
constructed within the period of partition. These relays are
point-to-point communication channels that can bridge accross
partiotions (given that logical transitivity exist).

Comments? opinions? anything :) ? 

Danny & Tal

=====================================
Institute of Computer Science
The Hebrew University of Jerusalem,
Givat Ram, Jerusalem 91904
Israel

---

From: Mark Handley <[email-masked]>
Date: Tue, 15 Aug 2000 18:13:38 -0700

The advantages they state seem to apply to any small group, whether
based on SGM, Internet Standard multicast or SSM.  I don't see how SGM
helps.  

Also not all RM protocols need to know who the receivers are.
(e.g. digital fountain approaches don't care who the receivers are)
Requiring the sender to know who the receivers are is therefore an
impediment, not an advantage.

The advantages of SGM (if any) do not seem to be at the
transport/application layer to me.  The one exception might be the
very limited security gain you get by having slightly more control
over who receives the traffic.  However IMHO such security gain is a
poor substitute for decent encryption.

Cheers,
	Mark

---

From: Tal Anker <[email-masked]>
Date: Wed, 16 Aug 2000 11:17:53 +0300 (IDT)

On Tue, 15 Aug 2000, Mark Handley wrote:

> based on SGM, Internet Standard multicast or SSM.I don't see how SGM
> helps.

That is almost correct with one thing different (you already said it
bellow): there is more control on who are the receivers that receives the
traffic. There are many reliable multicast "flavors", and to some of them
the membership (of receivers and sources) is important. When the
membership is known, it is much easier to give stronger semantics to the
user application, e.g., to guarantee that ALL the messages will be
delivered to ALL the alive receivers. This is obviously requires failure
detector (in the transport layer) in order to declare a receiver
"faulty" and thus enable the progression within the group (otherwise, the
source might get stuck and wait for acks from a faulty receiver). These
kind of protocols make it easier to build shared whiteboard/editor, where
the consistency of the object that is shared is important.

- Tal.

> transport/application layer to me.The one exception might be the
> over who receives the traffic.However IMHO such security gain is a