Re: Reacting to previous messages

[John Crawford <J.S.Crawford@ukc.ac.uk>]

I agree with the idea of Maria that you should look at the 
application area to drive the multicast design. Heavyweight 
multicast (static group membership, known before hand, e.g. 
a private meeting) has very different characteristics from 
lightweight multicast (dynamic group membership, unknown at 
all times, e.g. open video lectures, etc).

jc,

University of Kent at Canterbury.

On Wed, 02 Jun 1999 10:06:35 +0200 "Maria F. Ramalho" 
<ramalhom@rc.bel.alcatel.be> wrote:

> after the inter-continental time difference ... and thus a late re-action
> (incredible what happens in the other side of the atlantic while I am sleeping
> ;-) ... and what happens here while you also drowse away.
> 
> Well, (at least!) here goes my re-action although I do not know to which message
> I am re-acting to.
> 
> The addition of the core/source address to the group address seems to me one of
> the nicest ideas to tackle the problem of multicast address scarceness and thus
> the idea of having a WG joining efforts to see it implemented re-assures me that
> some people believe in "simple solutions to big problems". 
> 
> The idea of a new protocol to compete with PIM-SM is for me not so clear,
> though. This is partially, because I am doing at present a survey on multicast
> routing protocols and the list of protocols to be surveyed has been increasing
> day by day. Thus, I think that another protocol, for the sake of a competing
> protocol, be it SM or Express will just create a feeling of
> "yet-another-protocol" for people who are eager to see whether this thing called
> Multicast strives or not... and none of the present proposals convinced me for
> the inter-domain routing case. 
> 
> On the other hand, it is also not clear for me whether a protocol like PIM-SM
> (adding 4 bytes worth of address or not) can be a compelling protocol for all
> types of applications. It looks more to me that PIM-SM is a hybrid of all the
> new (and GOOD) ideas that have come out lately like:
> 
> 1: the shared tree for group membership management;
> 2: the bidirectional trees for sources that are also members;
> 3: the soft state with RPF check forwarding for flexible adaptability to routing
> changes;
> etc, etc
> ... and I would not be surprised if in the future the glue of the extra 4 bytes
> will be another addendum...
> 
> However, if you want to implement PIM-SM good luck! take some holiday first and
> save your breath: it is not an easy task! And why should multicast routing
> require such a complexity anyway?
> 
> As far as multicast applications is concerned, I have been longing to see
> "interactive" applications considered seriously as multicast applications rather
> than passive "push" applications like Internet TV that might generate a lot of
> revenue but that give me the feeling of "I have better things to do then stay
> home and watch TV". The argument that such applications are not there yet is not
> valid, in my opinion. Virtual reality based entertainemt and educative
> applications can become a reality as soon as network engineers can come up with
> a network that enables these applications to "navigate" well!
> 
> Interactive applications do not require such a complex protocol like PIM-SM. A
> single, bidirectional shared tree protocol scales well, is simple to implement
> and easy to maintain. Feel worried about traffic concentration? create another
> group and another shared tree. It might be  even better for the sake of traffic
> engineering, since with a new core, the data might be using different links than
> the original one.
> 
> I am going a bit away from the main issue here which was the need to create a
> new WG. Moreover, the charter of the new WG as defined by Cheng-Yin Lee did not
> mention anything about a new protocol, if I got it right. However, I could not
> help myself to express that if a new protocol could be designed having in mind a
> clearly defined application domain (and I have to give my credits to
> Hoolbrook&Cheriton for Express in what concerns Internet TV) that would seem
> advantageous for the multicast routing challenge. Interactive applications
> (where most sources are receivers and there can be many) is probably an
> inspiring domain both from a technical and business point of view (after all
> deep inside of every computer user there is always a "games-freak" teenager ;-)
> 
> Maria 
> 
> > ubject: 
> >         Re: Work Proposal
> >    Date: 
> >         Wed, 19 May 1999 12:08:43 -0400
> >    From: 
> >         Cheng-Yin Lee <leecy@nortelnetworks.com>
> >      To: 
> >         "sm-interest@cs.ucl.ac.uk" <sm-interest@cs.ucl.ac.uk>
> > 
> > 
> > 
> > 
> > Jon suggested  timescales as well, so here is a strawman proposal
> > 
> > The primary goal of the group is to develop specifications that will ease
> > the scaling (in the longer term) of current multicast routing protocols
> > targeted for these type of applications:
> > * Internet wide information distribution (eg 'webcast', content
> > subscription/distribution)
> > * Internet wide interactive information exchange (eg
> > conferencing/discussion, games).
> > 
> > The approach taken will allow the root (source or core) of the multicast
> > distribution tree to allocate logical  addresses that can be used to
> > address multicast groups. Since address management is local to the root, it
> > will not require Internet wide coordination and will also facilitate
> > applications to use the address space in a creative and application
> > specific manner (eg content filtering/naming, layered data) where
> > applicable.
> > 
> > The scope of work is as follows:
> > 
> > * extend the current multicast API to use this new addressing
> > - the group multicast address will consist of both the root (source or
> > core) of the multicast tree and a
> > multicast address.
> > 
> > * extend the current multicast data forwarding to forward based on
> > <root, multicast address>.
> > The address encoding should allow :
> > - routers which do not understand this new addressing to forward packets
> > non natively (unicast)
> > - current hardware to forward packet with this new addressing when the
> > root is the source of the multicast  group in the initial implementation
> > and deployment,
> > - for hardware to be upgraded to forward packet with the core as root.
> > 
> > * changes to control messages will be defined generically in TLV format.
> > The group will coordinate with the respective WGs for these to be
> > implemented in PIM/CBT/BGMP.
> > 
> > * migration/interoperability issues related to the above
> > 
> >   Goals and Milestones:
> > 
> >    Jul 99   Charter WG and specify goals and deliverables
> >    Oct 99  Issue first Internet-Draft on extensions to IP multicast
> >    Dec 99  Achieve concensus on the extensions
> >    Mar 00  Issue detailed specifications on host and router extensions
> >    Nov  00  Submit specifications to IESG as proposed standards
> > 
> > Reference:
> > * "Multicast Requirements for the Definition of New IP Multicast
> > Services"
> >   Christophe Diot, Bryan Lyles, Sprint ATL
> >   Brian Neil Levine, Consultant, Sprint ATL
> >   Ramanan Shanmugam, Amir Tabdili, Hassan Kassem, Sprintlink
> > 
> >