Subject: [bmwg] Multiple source to multiple destination IP multicast

From: "Perser, Jerry" <[email-masked]>
Date: Wed, 12 Feb 2003 14:20:40 -0800

Kevin,

RFC2432, Section 1. Introduction, last Paragraph:

   Moreover, this document focuses on one source to many destinations
   profiling.  Elements of this document may require extension when
   considering multiple source to multiple destination IP multicast
   communication.

I would like to open a discussion about multiple source to multiple
destination testing and the possibility of extension to cover this
particular profiling.

The multicast benchmarking I have seen for publication, and for private
verification has all required multiple sources.  The testing has required
some percentage of the traffic to be mulcts spread across a group of ports.

I am very interested in hearing from other BMWGers, any experience or
requirements that use only one source to many destinations IP multicast.  So
far, no one has come forward with a real test case for this.

Jerry.

___________________________________________________________ 
Jerry Perser                         Spirent Communications
Director of Test Methodology         SmartBits Division 
Phone: 818.676.2320                  26750 Agoura Road 
Lab:   818.676.2337                  Calabasas, CA, 91302 
Cell:  818.292.6457                  Corp:  818.676.2300

_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg

---

From: "Perser, Jerry" <[email-masked]>
Date: Fri, 14 Feb 2003 11:00:18 -0800

Kevin,

My comment was misunderstood.  I wish to discuss the supplemental I-D, not
mcastm-11. I am assuming the recent changes to mcastm-11's authors will give
us a complete and meaningful methodologies.  If you believe I could help
with current multicast methodology I-D, please let me know.

I am getting requests for multicast methodology that are not covered in the
current multicast methodology I-D.  I would like to discuss the requirements
for a companion I-D.  I am seeing interest in:

 - Multiple source to multiple destination IP multicast

 - Mixed-class latency

 - Authenticated multicast

In lieu of a RFC or I-D, I am developing these methodologies independently.
I would rather this work to be part of a companion I-D.

Jerry.

> -----Original Message-----
> From: Kevin Dubray [mailto:[email-masked]]
> Sent: Thursday, February 13, 2003 6:17 AM
> To: David Newman
> Cc: Perser, Jerry; BMWG (E-mail)
> Subject: Re: [bmwg] Multiple source to multiple destination 
> IP multicast
> 
> 
> Folks, the scope of the current multicast methodology I-D was bound by
> RFC 2432. Hence, we're not limiting the I-D's utility as it's 
> utility is
> in providing methodology as prescribed by RFC 2432.
> 
> Let's stay the course.  Put your energies in addressing more complex
> test scenarios and methodologies in companion I-Ds.
> 
> Thanks,
> Kevin
> 
> David Newman wrote:
> 
> > I'm fine with doing the additional work in a separate 
> document. My concern 
> > is that we are severely limiting the utility of the current 
> ID by going 
> > with just one transmitter. 
> > 
> > dn
> > 
> >  On Wed, 12 Feb 
> > 2003, Kevin Dubray wrote:
> > 
> > 
> >>Jerry,
> >>
> >>The WG has discussed the N x M possibilities during the formation of
> >>RFC 2432.  It was agreed to bound the work to the 1 source port to N
> >>destination port, unidirectional traffic paradigm.  While we noted
> >>that this may not be the most "interesting" paradigm, we agreed the
> >>paradigm represented a good & useful first step.  We also agreed
> >>that more sophisticated testing should be addressed in 
> subsequent RFCs.
> >>
> >>In light of the above, any discussion regarding multiple source to
> >>multiple destination multicast would be for a supplemental I-D, not
> >>the one currently being discussed.
> >>
> >>So, let's focus on getting agreement in these simple cases 
> first, before
> >>we tackle the new and improved.
> >>
> >>-Kevin
> >>
>

---

From: "Perser, Jerry" <[email-masked]>
Date: Fri, 14 Feb 2003 11:00:18 -0800

Kevin,

 - Mixed-class latency

Jerry.