Subject: [magma] RE: [RMONMIB] RE: sspm mib for multicast source control

From: "STEPHAN Emile FTRD/DAC/LAN" <[email-masked]>
Date: Mon, 3 Jun 2002 11:41:34 +0200

Hi all,

The I-D draft-stephan-ippm-multicast-metrics-00.txt defines metrics for measuring "the aggregate behavior of a multicast group (average, variation, distribution)" and the management of musticast measures using SNMP and the IPPM MIB. Perhaps this management may to be added ton the RMON framework ?

regards
Emile

-----Message d'origine-----
De : Romascanu, Dan (Dan) [mailto:[email-masked]]
Envoyé : vendredi 31 mai 2002 09:23
À : Lester D'Souza; [email-masked]
Objet : RE: [RMONMIB] RE: sspm mib for multicast source control

Lester,

I am not sure that I understand your comments. 

The response to a multicast packet may certainly be an unicast packet - that's protocol and application dependent.

Also, for a multicast packet to pass the first router hop, it might need to be within a session and application set-up - this is true not only for multicast.

However, there are some applications based on multicast which are not well covered by OWDP. Actually excepting video distribution in its different variants, what other application is one-way only? A qualitative description of a  multicast session covering both OW and round-trip delay seems to be missing. That the data collection for this case is tricky (as Bob put it) and not covered by our current proposal, this is also true.

Regards,

Dan

> -----Original Message-----
> From: Lester D'Souza [mailto:[email-masked]]
> Sent: Thursday, May 30, 2002 10:30 PM
> To: [email-masked]
> Subject: Re: [RMONMIB] RE: sspm mib for multicast source control
> 
> 
> 
> 
> Hi,
> 
> As far as I know there is no responce for a multicast packet. 
>  A multicast
> packet is unidirectional.
> If the receiver wants to send a responce then it will have to  use a
> unicast packet or it can use a
> different multi-cast address.
> 
> Having said that does sspm mib support sending out a 
> multi-cast packet ?
> Certainly the MIB does
> not prevent this.  But the packet may not even go beyond the 
> first hop.  To
> make it reach the destination
> you will need to first have multi-cast applications running 
> on end nodes
> which will register with the
> routers for a multi-cast group.  For this you will need an end-to-end
> multicast support across the network.
> 
> So even though the MIB supports multicast there are a whole 
> lot of external
> factors which may not
> make it practical to use this source.  What will be more 
> useful in this
> situation is to use one way delay
> measurements.  This is already solved by using OWDP.
> 
> Lester...
> 
> 
> 
> 
> 
> 
> 
> 
>                                                               
>                                                               
>             
>                     "Cole, Robert                             
>                                                               
>             
>                     G (Bob),             To:     "Romascanu, 
> Dan (Dan)" <[email-masked]>, "Carl W. Kalbfleisch" 
> <[email-masked]>     
>                     ALASO"               cc:     "Fenner, 
> William C (Bill), ALRSC" <[email-masked]>, [email-masked]  
>                 
>                     <[email-masked]       Subject:     
> [RMONMIB] RE: sspm mib for multicast source control           
>                     
>                     m>                                        
>                                                               
>             
>                                                               
>                                                               
>             
>                     05/29/2002                                
>                                                               
>             
>                     01:41 PM                                  
>                                                               
>             
>                                                               
>                                                               
>             
>                                                               
>                                                               
>             
> 
> 
> 
> Dan,
> 
> > >
> > > For one way, you could then have multiple sinks.
> > >
> > > For round trip we might need to think about what happens to the
> > > responses. The stats that are there could be irrelevant 
> when there are
> > > multiple responders. For example the expectation rate would
> > > be different
> > > if there are multiple responders.
> > >
> >
> > It would be interesting to hear what is the trigger of the 
> question - do
> you have a real-life application in mind?
>      [Cole, Robert G (Bob), ALSVC]  Bill Fenner had suggested 
> using the
> sspm MIB to control the traffic
>      source and to use the RTP MIB for data collection as a means to
> monitoring RTP end points.
> 
> > I agree with Carl, that the stats need to be processed 
> differently for
> round trip. One possible way would be to define metrics for 
> the aggregate
> behavior of a multicast group (average, variation, distribution). If
> separate behavior with each member of the group is the 
> target, we need to
> have some awareness of the membership of the group, and a way 
> to discern
> between different sessions.
>      [Cole, Robert G (Bob), ALSVC]  I view these as seperable 
> issues, i.e.,
> traffic control and data collection.  I agree that
>      the metrics and their collection may be a tricky issue.
> 
>      Thanks,
>      Bob
> 
> > Regards,
> >
> > Dan
> >
> 
> _