Subject: Re: PIM-SO and RMT

From: Lorenzo Vicisano <[email-masked]>
Date: Fri, 10 Mar 2000 12:59:35 -0800

Dah,

The charter does not state that a "single source" model should
be assumed, however it is very likely that the future multicast
deployment will be largely based on single source.

Moreover, the current heterogeneity of multicast deployment does
not allow to assume the presence of multicast feedback (mainly
because providers do not allow "normal" customers to source multicast).
Nor it does allow to assume the presence of "dense mode" protocols only
(and most of the techniques you mentioned only work with dense mode).

For the above reasons, in the last meeting (at ACIRI) the group agreed
(I think) to assume no multicast back-channel (protocols can still take
advantage of it, if present, as an optimization). Note that this does
not exactly mean "assume Single Source".

I also have two personal remark:

  - establishing multicast distribution trees is much more expensive
    than using unicast, hence, I think, we should not abuse this --precious--
    resource if possible.

  - most of the techniques you mentioned do
    not work well with multicast back-channel, unless you assume the
    presence of a dense mode protocol (and this is not the case).
    E.g. expanding ring search is broken (most of the times) in PIM-SM
    because, it common cases, packets have to reach the RP first. On the
    other side there are application level algorithms that make *all* these
    techniques work without multicast back channels.

	cheers,
	Lorenzo Vicisano

> In the recent RMT Interim meeting in Berkeley, I learned from Brad Cain
> that we have to assume the IP multicast infrastructure is PIM-SourceOnly
> (or PIM-SO) and IGMPv3. In particular, this means we must assume that
> only one host can multicast to a given group.  This is confirmed by Mark
> Handley and Roger Kermode (see the meeting minutes under "My dream protocol"
> for example).
> 
> Later in separate discussions in the TREE BB subgroup, some stated that
> the PIM-SO (hence only one host can multicast per multicast address)
> is part of the RMT working group charter.
> 
> I am seeking a clear statement regarding this requirement.  I don't see
> "must assume PIM-SO" are part of the charter. If it is, can it be stated?
> Is it mandated as a requirement for the RMT?  Can someone succinctly
> summarize what is the PIM-SO requirement on RMT, and justify it?
> 
> I am pressing for this because the lack of many-to-many IP multicast
> capability means a lot of techniques/algorithms reported in the literature
> will not work any more.  For example:
> - A NACK protocol depends on the NACK be sent via multicast to suppress
>   redundant NACKs that cause implosion.
> - Some tree building protocols use Expanding Ring Search (ERS) to nearby
>   servers.  Although ERS is considered costly in terms of message overheads,
>   it can still be a useful autoconfiguration technique for many scenarios.
> - In a tree-based ACK protocol (TRACK), the repair heads should be able to
>   share multicast addresses for sending out multicast repairs.  This would
>   not be possible if only one host can send on a multicast address.
> 
> I understand that in the current public Internet, limiting multicast to a
> single sender fits certain business models of ISPs who can charge for
> multicast.  But this constraint is not needed in many intranet environments.
> 
> I understand many people support the Simple Multicast model, under which
> there is no single-source constraint.  Is that proposal still being studied
> by IETF?  Also, what is happening to the BGMP model that allows dense mode
> multicast in administrative domains?  Is the PIM-SO requirement premature?
> 
> Dah Ming Chiu
> Sun Labs
> 
>

---

From: "Michael D. Myjak" <[email-masked]>
Date: Fri, 10 Mar 2000 20:33:07 -0500

> deployment will be largely based on single source.

I take issue with this statement; Its about as far-sighted as next week.  How can
you possibly say, with any assurance or credibility, that future multicast
deployment will largely be based on single sources?? Are you not familiar with any
of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared
Collaboratories?  or DoEd's Advanced Distributed Learning?

Certainly to date, the predominate model has been point-to-multipoint.  But this
statement is as reassuring as "Certainly... 32-bits is more than enough address
space."   Oh Please...

--
All the best -
    _
___|0|_|___  Michael D. Myjak, Vice President R&D and CTO
 | N & W |   The Virtual Workshop, Inc.
= oo---oo =  P.O. Box 98 Titusville Fl 32781
email: <[email-masked]>  voice&fax: 321.264.0440

---

From: Lorenzo Vicisano <[email-masked]>
Date: Fri, 10 Mar 2000 18:09:24 -0800

> Collaboratories?  or DoEd's Advanced Distributed Learning?

Michael,

the context of my statement was in the RMT framework, which is
bulk-data transfer for IP multicast (as currently specified).
Moreover there was more in my email beside the statement that
you are quoting... 

I agree with you that interactive applications work much better
with a symmetric Multicast service and that this is probably the
main the reason why we should keep working on its deployment. However
this is out of the scope of RMT (please check the WG charter).

	Lorenzo Vicisano

---

From: "Michael D. Myjak" <[email-masked]>
Date: Fri, 10 Mar 2000 22:04:25 -0500

Lorenzo,

I read what you wrote... I'm just trying to earmark what's on the horizon. And I do
understand that the RMT charter is highly focused toward a narrow-cast solution
space.  Be that as it may, the issue in my mind irrespective of that, is that that
the prevailing mind set in this arena seems to be just as you stated - it prefers a
closed, unidirectional, asymmetrical point-to-multipoint communications path which
has little to no regard for application(s) performance (i.e., real-time).  (In
fact, the preferred application may be little more than a file or web site
mirror.)  Further, applications which are sufficiently "different" or fall outside
of this groups perceived "mainstream" scope may yet evolve and attempt to utilize
the approach developed here, whether we perceive it as applicable or not. (Ex.
Distributed Interactive Simulation [IEEE-1278] used subnet broadcasting to
accomplish what it could not using IP Multicast.  Clearly, subnet broadcasting was
never designed with such a (multipoint-to-multipoint) application in mind.)

In short, all I'm trying to say is that we cannot assume that this (or any)
specific application will be the only one(s) to use RMT.

---

From: Brian Whetten <[email-masked]>
Date: Sun, 12 Mar 2000 15:51:34 -0800

>statement is as reassuring as "Certainly... 32-bits is more than enough
address

Mike,
Even if a significant piece of multicast deployment eventually support
many-many, there will still be a big piece that does NOT.  We have to
design to the least common denominator.  As a side note, we'd all love to
see many-many worldwide multicast, but I think there is growing consensus
that it is extremely difficult to justify it economically.  The costs are
too high (the inter-domain issue is just too much) and the benefits too low
(there are much easier way to implement many-many apps on top of 1-many
multicast...Talarian has customers deployed with 10K client many-many
environments).  This does NOT mean that there are no compelling, scaleable
many-many apps...just that we don't necessarily need to support them with
true many-many multicast.

Brian

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 13 Mar 2000 08:57:09 +0000

Brian

yes...
i think another argument can show that we have a deployment credibility 
problem with the internet standard multicast service model ....we're already 
having a lot of ISPs clamp down on source addresses for unicast traffic so
that they can rapidly respond to Denial of Service attacks - whatever
the pro many=-to=many multicast people say (and i am one of them,
believe me), its at least n-fold harder to audit n sources than 1...

in fact ,there is going to be at least a BOF in adelaide on this topic
- i wonder if any multicast considerations are going to be represented
there?

 cheers

   jon