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

From: "Dave Oran" <[email-masked]>
Date: Sun, 27 Aug 2000 14:00:20 -0400

My knowledge of reliable multicast is spotty at best, so I wade in here with
some trepidation. Since this is a side issue wrt SGM, feel free to drop this
thread at any point. I just want to make sure that any claims are
supportable with analysis or hard facts. See below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2000 2:34 PM
> To: Dave Oran
> Cc: [email-masked]
> Subject: RE: FW: FW: Adding reliable transport layer above sgm/xcsat
>
>
>
>
> >> >
> >> > 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.
> >>
> >> It is not true that the advantages apply to any small group.  The
> >> distinguishing characteristic of SGM is that it can easily send to a
> >> subset of the destinations, which makes things like reliability and
> >> congestion control easier.
> >>
> >I'm not sure this dicussion is getting us anywhere, but I don't follow
> >Dirk's contention that having explicitly-addressed subsets of the group
> >helps in any substantial way for congestion control or reliability. An
> >explanation might help.
>
> The explicit list of addresses helps with respect to reliability in
> a couple of ways.
>      -  you know the address(es) at the other end which is helpful if
>         you want to implement "end-to-end" reliability
In order to have any sort of end-to-end reliability, you either use FEC or
feedback to the transmitter. In the case of FEC the transmitter never finds
out (or needs to find out) who the receiver(s) is/are. In the case of
feedback, the feedback contains the (unicast) source address of the receiver
and hence you can target retransmissions via unicast if need be.

>      -  it's easy with SGM to send "appropriate" retransmissions when
>         retransmissions are needed.  ie you can send an SGM packet to
>         the subset of destinations that have not acked, say, or to the
>         subset that have nacked, say, and the retransmission is "optimal"
>         in terms of the network bandwidth consumed.
Well, if you use ACKs/NAKs then the main problem is the number of ACKs/NAKs,
right? That's why nearly all rmt schemes use some form of ACK/NAK
elimination to avoid implosion. There may be some savings if you use
explicit multicast addressing for the retransmissions, but that savings
depends sensitively on where the losses occur (the closer to the source, the
better you do, I suppose). There is also the problem with estimating the
RTT, and hence tuning the retransmission scheme, which I don't think
explicit multicast doesn't helps with at all. If you don't have the timers
tuned you will wind up with multiple retransmissions to different subsets
and hence may have even less gain over multi-unicast, or pure multicast.

>      -  the routers don't have to do much to support reliable SGM (ie
>         they don't have to do anything other than support unreliable SGM)
Well, that's true of some of the RMT schemes as well. For schemes that do
have router state, the difference is that with RMT the router state is
viewed as optimizations and the sources don't have to get involved in
figuring out the optimal strategy.

>           -  i.e. they don't have to keep track of multicast group
>              state and they don't have to do retransmissions
>              (since reliability would be end-to-end)
Some schemes have routers only holding protocol state and not data state and
hence the routers don't actually do any retransmissions. Note that
reliability is still end-to-end because the router state is used only as an
optimization.

>           -  the routers don't have to build special multicast trees
>              when a source needs to send a retransmission to a subset
>              of the destinations.  (The tree for the retransmission
>              is built (as is always the case in SGM) "on the fly" as
>              the packet flows from the source to the destinations.)
>
I do not believe I know of schemes which build special trees. Some schemes
are smart and prune the existing tree to the subtree needed to cover the
receivers which need the retransmission, but this is not a tree computation.

> Of course the fact that the groups are "small" is also helpful.
>
Right. The question again is whether there is any gain compared to "rmt
classic" *for groups of identical size*. Has anyone actually done any
analysis or simulation? Some of these properties are anti-intuitive and need
hard justification.

> re: congestion control, if you have end-to-end awareness (as you have
> in SGM) you can implement end-to-end congestion control.  And the
> fact that you can easily send to a subset helps too as Dirk mentioned.
>
I think I disagree with this, but I'm on REALLY shaky ground here so please
correct me as needed. The reason congestion control is hard for multicast in
general (and RMT in particular) is because you don't know where the
bottlenecks are relative to the delivery tree and because each receiver is
seeing a potentially different congestion environment. As long as the source
is going to try to get one packet to multiple destinations, no matter how it
does so, this fact doesn't change.

> You said you're "not sure this discussion is getting us anywhere".
> Well it has brought out certain points such as the fact that if one
> is using "conference bridges", it seems more appropriate to use
> SGM than "classical multicast" as Yuji has explained in his note.
>
I don't know at all how you got there. I didn't respond to Yuji's note
because I assumed he was just pointing out that if you did (audio)
conference bridges with SGM, that would win over multi-unicast. If you
factor out the group-state-in-the-routers, the optimal strategy is each
source unicasting to the bridge, and the bridge unicasting back to the
active sources (since each sees a unique mix), and multicasting to the
non-active sources. Since any even half-way rational conference only has
multiple simultaneous talkers for a brief back-off period, I don't see how
you can do better than normal multicast from the bridge to the receivers.
There are also hybrid techniques which I won't go into that optimize the
multicast case further.

> On the larger point of making progress, I'm ok with either of the
> problem statements that you proposed for the working group in a note
> a little while back.  (If I had to choose I mightly lean slightly
> toward the first one.)
> And I haven't heard any feedback to the contrary so perhaps we should
> formally kick off an effort to address one or both of those problem
> statements.
>
I'm going to call the question at the end of the coming week.

> Is there any reason why we shouldn't?
>
Yes. I think the jury is still out. I'd really like to hear from a wider
audience than we've been hearing from.

Dave.

---

From: [email-masked]
Date: Wed, 30 Aug 2000 10:07:09 -0400

>supportable with analysis or hard facts. See below.

Dave,
I'm also ok with dropping this thread since this is, as you say, a side
issue wrt SGM.

I'm just saying that the the ability to selectively specify a subset of
the destinations and the ability to efficiently deliver data to a subset
of destinations lend themselves to reliable multicast since you can
do the re-transmissions efficiently if you want to.

But as I said, I agree that we can drop this thread since this is kind of
a side issue.
Rick

re:
>non-active sources.

Yuji's point was that when you multicast to the non-active sources, you
may need a number of different class-D addresses, one for each combination
of non-active sources ie. in a 5-party conference consisting of parties
1, 2, 3, 4 and 5, you need one multicast group for 2,3,4,5, and one for
1,3,4,5 and one for 1,2,4,5 ...  And you need one class D address for
each of the various combinations of 3 members, the combinations of 2
members etc.