Re: Reacting to previous messages

["David R. Cheriton" <cheriton@DSG.Stanford.EDU>]

The point of the message was to suggest we agree on the >problem<
since I think that is what gives a WG focus and the basis for making
good decisions (and that means agreeing on applications in my mind).
I can't relate to a WG whose members are bound together by happening
to agree on portion of a >solution< ( (S,G) pair identification of 
tree) to some undefined problem.

I find your response "counterproductive" because you focus only on
this bi-direction tree issue, and dont provide any further
substantive input on what problem we are addressing.  It sounds like
you are just promoting this particular idea.  And, I'm not convinced
by random anecdotal comments like, the PIM crew thought bi- was good
so we should too. I want to well-reasoned quantitative arguments,
not selective quasi-blind copying of the decisions of others.

Looking over previous mail, the applications you propose are basically
the same as Cheng-Yin Lee except for something about data collection
and routing protocols.  If these are at all real, who wants this,
what data rate, etc. ?  I think the "new types of apps we haven't yet 
thought of" is a dangerous red herring.  In reality, the basic
patterns of communications with computers have been stable for 20
years, if not more, and things like email, web are just GUI'ed up
file transfer.  I'm more impressed on how little is new, no vice versa
Plus, designing beyond real requirements is a recipe for failure.

As for "distracting" the chairs trying to get this going, sorry,
but if I was them, I would like to have a clear problem statement
that stood up to scrutiny.
In that vein, I hope some devil advocate ISP rep. stands up and
calls us idiots because:
i) (as I argued before), most supposed multicast can be done with
  multiple unicast, and with bandwidth going up, even more can.
  And who wants it any way,  Pointcast reborn?  Recall what happened
  to the Web "push" fad - Good morning?
ii) multicast just saves the customer bandwidth/cost while leaving
   the ISP with a charging and delivery problem.
ii) multicast complicates running a network, a lot.
iv) after 15 years of IP multicast not going anywhere, perhaps we
   are just to invested in multicast to recognize it as empirically
   proven to be just one bad idea.  Is there other
  ideas that have been around this long, gone virtually no place,
  and we still think are good ideas?
....
I think we should try to have some good answers to these challenges.

DRC

At 05:08 PM 5/30/99 -0400, Radia Perlman - Boston Center for Networking wrote:
>Dave,
>
>I really don't understand the point of your message. I think it is
>counterproductive to continue arguing at this point about, essentially,
>unidirectional vs bidirectional trees. We should get the working group
>off the ground, and then argue the engineering tradeoffs of various things.
>Mostly I think bi vs uni is a minor point, and way too much bandwidth
>has been spent arguing about it. (Studying it is a different matter, i.e.,
>making lists of pros and cons, and I think that would be fine, but
>we should not distract the chairs from getting the working group
>off the ground by pretending this is a life and death issue that must
>be decided now, and if decided the "wrong" way, the entire working
>group is worthless.)
>Anything can be supported with
>either bi or uni trees, though bi will be more efficient for multisender
apps.
>The interesting question is, how much more expensive, if at all, would it be
>to support bi trees? What functionality, if any, is lost or gained?
>
>You asserted that you raised the question of whether there were any
>compelling applications for multisender groups and that "none came up".
>This isn't true. There were suggested applications.
>Maybe none of those were "compelling"
>to you, but reasonable people can disagree about how "compelling" they are.
>And even if the suggested apps are only slightly useful, if multisender
>apps can be supported AS EASILY as single sender apps, then ANY potentially
>useful apps, or the desire to be flexible enough for
>new types of apps we haven't yet thought of
>would be sufficient reason to support them. Note again that customer
>demand drove the PIM implementors to support bidirectional trees, not
>just researchers thinking it would be a cool thing to do, and that
>just doesn't seem to mesh well with the assertion that nobody can
>think of any worthwhile multisender apps.
>
>What I think most of the people in this working group agree on is that
>groups should be identified in such a way that multicast addresses are
>administered locally (by a single node), and be part of the group ID that
>endnodes join to eliminate the necessity for routing to figure out how
>to route to class D addresses. That's 90% of the
>spirit of both Express and SM, and I'd think any supporter of either
>approach should be happy with an outcome that preserves those properties.
>There's no reason to be divisive about
>details, especially at this point in the WG. And I fully support coming
>up with a different, neutral name at this point so it isn't an ego fight
>of "ours" vs "theirs", but instead is viewed as something we all contribute
>to and support.
>
>Radia
>
>