Re: Simple Multicast - building a case for a BOF or WG

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

There has been lots of email agreeing that we need to focus on the "problem",
not specific protocols, responding in part to my query for applications
that drive the need for bi-directional shared trees.  I was actually trying
to understand what others considered the "problem", not discuss protocols.
I think the "problem" is multicast that supports applicaitons, so asking
for the applications is part of the problem definition in my mind.  If there
are no compelling applications, there is no problem because we dont need
multicast.
  Also, I guess I mistakenly used the term "bi-directional shared tree" as
defining a service model.  Is there a better term?  I was trying to designate
the service model provided by Simple, over and above Express, and understand
what problem it was trying to solve, what applications?
  Regarding problem, I regard the primary problem that multicast needs to
solve
is supporting Internet TV channels, many of them.  There is clearly huge
economic value there, huge benefits to scale wide-area, and the bandwidth of
the Internet will move up so that the bandwidth of a video stream to an end
point is no big deal.  (The app is described further in the EXPRESS paper,
which Hugh Holbrook@dsg.stanford.edu can provide, if you havent seen it.)
I think a few other applications may come along for the ride, but without
the prospect of Internet TV, I wouldnt even bother thinking about native
multicast in the Internet.
  In that vein, many (perhaps most) natural "multicast" applications are done
with repeated unicasts.  There are a lot of advantages to this approach,
and with the increasing bandwidth, not a significant bandwidth problem to
this until you reach reasonably large-scale, or operating at high bandwith.
I think one of the problems with multicast development in the past, including
what I have done, is too much attention to small-scale apps, familiar to the
research community, and not enough on really large scale, economically
compelling ones.
   Finally, I think we need to rethink multicast in the light of applications
that we can see as really compelling, and not worry initially about the
existing service model and protocols.  Given multicast has basically gone
nowhere in the past 10 years while the Internet has exploded, there is really
something missing or perhaps even completely wrong.  Significant changes,
such as restricting it to single source, make additions to the service model
for compelling applications feasible, making the likelihood of deployment
higher, at least IMHO.  Our grandchildren will thank us for a "clean"
well-thought out service model and protocols long after the existing stuff
is only of interest to computer archeologists.
  So, besides large-scale single-source applications such as Internet TV,
distance learning and multicast data delivery, what are the compelling
applications?  After working with multicast for the past 18 years, and on
EXPRESS for the past 3 years with Hugh, I'm not seeing any compelling
applications that arent quite implementable with single-source multicast.
Please tell me what I am missing!

DRC
ps I'll be out of email contact for next week so pardon any slow response.

At 02:12 AM 5/8/99 -0700, christophe diot wrote:
>>         I agree with Radia.
>> I believe that a flexible protocol that can be "fine-tuned"
>> to behave like others would be of benefit.
>> a. different applications have "conflicting" requirements.
>> b. much as we believe we can predict the evolution of the
>> structure and the technology, I don't think we can.
>>   If anyone can, by all means, let me know :-)
>
>for many reasons, I think we should first work on protocols that can be
>deployed by carriers and ISP (some constrains that may not be those of
>the application), and delegate to the applications more complex
>problems.
>
>>         I also agree with the comment (Joe Halpern I think)
>> that a working group should not focus on a solution, but
>> more on identifying the problem. Of course, we can use
>> some protocols as platfroms or reference points, but it could
>> be unhealthy to imply that the WG "prefers" some protocols
>> apriori.
>
>this is a consequence of the previous point. study application
>requirements, experiences of carriers that have deployed multicast, take
>into consideration carrier deployment constrains, and define one or more
>models. from this point, defining protocols should be easy.
>
>=======================================================
>
>christophe Diot         | tel: 1(650)375.4539
>Sprint ATL              | fax: 1(650)375.4490
>1 Adrian Court          | cdiot@sprintlabs.com
>Burlingame CA 94010     | www.sprintlabs.com
>USA                     |
>
>
>