----------
> From: Dan Connolly <connolly@w3.org>
> To: FoRK@xent.ics.uci.edu
> Subject: Review requested: Self-Organizing Multicast I-D
> Date: Wednesday, February 18, 1998 1:29 PM
>
> Has anybody read this in detail? It claims to solve
> a VERY interesting (to me) problem...
>
> "MTP/SO: Self-Organizing Multicast", Joerg Ott, C. Bormann, N. Seifert,
> 12/04/1997.
> (54401 bytes)
>
> ftp://ietf.org/internet-drafts/draft-bormann-mtp-so-01.txt
>
> Multiparty cooperative applications have recently received much
> attention, as has
> the multicasting of datagrams in the internet. The internet
> datagram multicasting
> mechanism is not reliable, often requiring a higher level protocol
> to achieve the level
> of reliability required for an application. Much of the extensive
> work on reliable
> multicast protocols has assumed relatively stable groups that need
> to ensure that all
> messages are received by all members of this well-defined group.
> Recently, work
> on loosely coupled teleconferencing has directed attention to a
> class of multicast
> applications that scale up to an extent where this assumption is no
> longer practical.
> An interesting multicast transport protocol is defined in RFC 1301.
> MTP provides
> globally ordered, receiver reliable, rate controlled and atomic
> transfer of messages
> to multiple recipients. A revised, more practical version of MTP,
> the Multicast
> Transport Protocol MTP-2 has been in use for some time.
> Self-Organizing Multicast,
> MTP/SO, uses MTP-2 as a basis and adds spontaneous
> self-organization of the
> members of the group into local regions. Scalability is increased
> by providing
> passive group joining and local retransmission of lost packets.
> This version of the
> document is not yet complete but contains most of the vital parts.
>
> --
> Dan
> http://www.w3.org/People/Connolly/
Thanks for the reference, Dan. I agree with you - I'm very interested
in this sort of stuff too.
Here are some observations based on one read-through.
First, a quick summary. Then, the detailed observations for
those who care.
(BTW - I've cc'd the authors of this Draft, so that if I've made
any grievous errors in my interpretation of their work, they
can correct me).
Summary of my comments:
---------------------------------------
Leader based, NAK based,
no protocol-support for application state-transfer
and late-joiners. "Self organization" deals with an adaptive
scheme to choose repeaters, not with any application-level
self-organization.
Should be applicable to applications which want to scale
to large groups, but with relatively few senders (senders<<receivers),
and which are willing to manage state-transfer to new members,
and new-join processing in general, on their own.
Details:
-----------
1. It's a leader-based protocol, i.e. there's a coordinator in the group
which assigns tokens to senders. Hence, the coordinator is
effectively the throttle on the group - permission to send
is serialized through it, it generates sequence IDs,
and confirmations of receipt are based upon it. There is support for
multiple streams, meaning you can have multiple concurrent
senders, but of course there won't be any ordering between these
prioritized channels - effectively each priority channel forms its
own ordered group.
This should certainly work fine for small groups -
but of course, that's boring
and not the intent of this protocol anyway, which is explicitly
targetted at large-sized Internet groups. For those, my guess
is that it also works fine for large groups which have relatively
small numbers of senders contending for tokens from the coordinator.
But if you have a large number of prospective senders vying for
tokens all from one centralized coordinator, I think this may bottleneck.
In general, I wonder about leader based protocols for large
groups. If for no other reason, it just seems wrong on grounds
of symmetry- here's a group broken into a hierarchy of scopes,
and the (universal) coordinator has to live in only one bottom-most
scope. That seems lopsided- giving unfair connectivity and access
to members who happen to share the same scope with the
coordinator. I'd be curious about efforts to build similar
large groups that are not leader-based, but are fully distributed.
The other thing
I've never liked about leaders is that when they fail, the protocols
required to detect their failure, elect a new coordinator, and ensure
that coordinator picks up where the old one left off - are all
themselves distributed, so why not use such protocols all the time,
and dispense with leaders altogether?
Or not.... am I being too hard on leader-based designs?
Werner? Silvano? Esti? Doug? others? Comments welcome on this.
(to sum up the above - coordinator bottleneck would appear to be
a function of the number of prospective _senders_ in a group, not
the group membership per se. Hence, it could scale very well
for large groups with limited senders - eg a few video broadcasters,
many receivers).
2. There is no protocol-support for join-in-progress, or application
state-transfer.
> We assume that the application
> protocol will have a way to handle receivers that experience such a
> long gap in reception, because it already needs a way to treat new
> members that appear late in the group. (Note that for applications
> where this is undesirable, MTP/SO could be augmented by log
> servers as in [3].)
and in fact, within the protocol, messages are only kept for a maximum
(retention+4 heartbeats) time at the sender. (Presumably at the
repeaters too? Unstated, but I would assume so.)
Hence, any long-term
state memory and transfer within the group is punted to the application
layer. That's a resonable engineering decision to keep the protocol
streamlined and performant, but it then limits the useablity to
those applications willing to manage such state transfers and
late-joiners on their own. Late-joiners are probably not a big
deal in small groups. But with groups on order of 10**5, 10**6
members or more, it's unfeasable to restrict membership
to being defined at group formation time. Nor is it very nice
to punt the problem of adding members and passing them state
to the application.
3. The "self organization" property, which is the main addition
of this protocol, deals with the dynamic election of repeaters.
That seems quite nice, in fact. There is a repeater per scope,
and the scopes are nested - 4 layers - site, country, continent,
global. (why 4? why magic numbers generally? why geographic
names, as opposed to subnets/routers..?). Repeaters can
duke it out based upon their advertised-ability to best take
on the function of repeater - this is the self-organizing stuff.
Repeaters compete with each other
based upon a property of "reception quality" - ie the fraction
of successful messages they've been receiving. Hence, it's
a good measure of the error-free connectivity of the repeater.
But one would think there are other vital statistics a good
repeater should have. E.g., since it needs to buffer messages from
all senders in order to acheive retransmits within its scope,
a repeater presumably also needs copious storage and cycles.
What good is a repeater that is well-connected, but is unable
to cache messages on behalf of senders?
Also worth noting - the title of the paper, and the name of the
protocol - "self organizing/ SO", are apt in this description of
repeater choice. But I fear they may lead to confusion amongst
"application level" folks (like you or me, Dan), who hear
"self organization", and think about smart, emergent, application-level
properties of "self-organization". That's not the case here!
Application level usage of these multicast groups can be as static
and rigid, or as dynamic and self-adaptive, as the app. designer
chooses to make them.
Hope that helps.
Ron.
-- Ron Resnick DiaLogos Incorporated Experts in Java and CORBA Technologies http://www.dialogosweb.com