Subject: [bmwg] WG Last Call: draft-ietf-bmwg-mcastm-10.txt

From: Kevin Dubray <[email-masked]>
Date: Wed, 15 Jan 2003 09:27:22 -0500

BMWG'ers:

A WG Last Call period for the Internet-Draft on
       "Methodology for IP Multicast Benchmarking,"

       <draft-ietf-bmwg-mcastm-10.txt>

will be open from 15 January 2003 through 30 January 2003.

The editor feels this latest version of the I-D has addressed all 
outstanding feedback from the previous WG Last Calls.

If you feel that this draft should not be given to the Area Directors
for consideration in progressing the I-D to an Informational RFC,
please cite your basis to this list or [email-masked]. Weight
will be given to those issues for which alternative solutions
are offered.  This must be done prior to close of the last call
period. Of course, notes of support are always welcome.

A URL for the Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-mcastm-10.txt

-Kevin

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

---

From: "David Newman" <[email-masked]>
Date: Wed, 22 Jan 2003 15:58:02 -0800

I agree with comments posted by Jerry Perser and, at the risk of plagiarism,
I would like to add a few concerns of my own:

1. Section 4.1 on mixed class throughput is ambiguous because it does not
require that users declare the actual number of multicast and unicast
receivers, and the way in which they are combined.

With the current language it is possible to conduct two different tests,
both of which fully comply with draft 10, and yet obtain two very different
results because the user altered the number of multicast and unicast ports
and/or the ratio of the two.

This ambiguity can be elminated with the addition of two MUST declarations:
One covering the number and combination of unicast and mcast receiver ports
in use and one requiring that like be compared with like when assessing
results from different DUT/SUTs.

2. Section 5.1 on forwarding latency states that "the user of this data
SHOULD understand the nature of the latency values being reported." Here
it's the user, not the DUT/SUT, that has become the device under test. Is
not clear what metric can be used to determine whether a user truly does
understand (or even whether a single test can be applied in all cases). What
if the user is just reading off cue cards? :-)

While I understand the good intent of this statement, I believe this
recommendation falls into the category of things that can be neither proved
nor disproved. I would recommend its omission.

3. I have suggested in the past that the methodology address mixed-class
latency as well as mixed-class throughput. More and more, I am coming to
believe that latency is the more meaningful of the two metrics since it
affects every packet all the time. Throughput, on the other hand, is by
definition only of interest at maximum load.

4. In section 11 on references, there is a new requirement that documents
submitted to the IESG classify referrences as normative or informative. We
just had the firewall methodology draft bounced back for this reason. It'd
save you a trip to get this fixed now.

5. Also in references, Se98 references a URL, which is a no-no. For good
reason too: The link is broken.

dn

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Kevin
> Dubray
> Sent: Wednesday, January 15, 2003 6:27 AM
> To: [email-masked]
> Subject: [bmwg] WG Last Call: draft-ietf-bmwg-mcastm-10.txt
>
>
>
> BMWG'ers:
>

---

From: "David Newman" <[email-masked]>
Date: Wed, 22 Jan 2003 15:58:02 -0800

dn