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

From: Kevin Dubray <[email-masked]>
Date: Fri, 30 Aug 2002 10:20:56 -0400

Debby Stopp wrote:

> 
> 
>  > So, you're saying wording like "Multicast Latency MUST be collected
>  > at the measured MCT level of the DUT; multicast latency at other
>  > offered loads is OPTIONAL." should be added.  I think that's fine.
> 
> in order not to rewrite the entire paragraph, here's what I ended up w/:
> 
> In order to lessen the effect of packet buffering in the DUT/SUT, the 
> latency tests MUST be run such that the offered load is less than the 
> multicast throughput of the DUT/SUT as determined in the previous 
> section; multicast latency at other offered loads is optional. The tests 
> should also take into account the DUT's/SUT's need to cache the traffic 
> in its IP cache, fastpath cache or shortcut tables since the initial 
> part of the traffic will be utilized to build these tables.
> 
>

Nope.  I'm hearing that you MUST specify the collection ML at
the determined MCT; optionally at other offered loads.  Your
wording isn't reflecting that.

Also the last sentence isn't needed, as it's addressed later
in the methodology of ML.

To clarify my earlier mail on "transmit some learning frames to

the DUT," - that text was taken from J. Perser's post of
12/18/01.  I think such a statement (e.g., Priming the SUT) could
be placed in section 3.1, test considerations, easily.  And
the balance of the I-D quickly checked for consistency.  E.g.,
the 4th paragraph of the Latency methodology elevated to MUST.

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

---

From: Kevin Dubray <[email-masked]>
Date: Fri, 30 Aug 2002 10:20:56 -0400