Subject: [bmwg] bmwg-mcastm-08.txt: DUT priming

From: Kevin Dubray <[email-masked]>
Date: Tue, 03 Sep 2002 10:46:33 -0400

CC'ing group, who might have something to say about the
topic.

Debby Stopp wrote:

 >> Kevin wrote:

>>Hmmm. Simply, this is what I'm proposing:
>>
>>In section 3.1, add a new subsection, 3.1.6, "DUT/SUT Priming".
>>Such a section might say something like:
>>
>>An actual flow of test traffic may be required to prime related 
>>mechanisms, (e.g., process RPF events, build device caches, etc.) to 
>>optimally forward subsequent traffic.  Therefore, before an initial, 
>>measured forwarding test trial, the test apparatus MUST generate test 
>>traffic utilizing the same addressing characteristics to the DUT/SUT 
>>that will subsequently be used to measure the DUT/SUT response.
>>The test monitor should ensure the correct forwarding of traffic by
>>the DUT/SUT. The priming action need only be repeated to keep the 
>>associated information current.
>>
> 
> 
> Ok, that seems reasonable, one last comment, however.  If you say "may be
> required to prime related mechanisms", then why would we say "test apparatus
> MUST generate test traffic"?  Seems like if you have a DUT that doesn't
> require priming, the test doesn't need to send 'priming' traffic.

I can't make an assumption about every tested device or test topology.
But defining a universal procedural step, we increase the probability
of a normalized collection. (In practice, most folks send a short
burst of packets, if nothing else, to ensure they've cabled
or configured correctly!)  For DUT/SUT or scenarios where this
"priming" isn't needed, no harm.  For non-forwarding burdened metrics,
sections 4 and 5, you're still collecting a forwarding response
WITHOUT consideration  of overhead processing.  For forwarding
burden metrics (section 8), DUT priming might not be desirable.
(A note saying such should be added to the above text. (E.g.,
Priming is a requirement for section 4 and 5 metrics; priming is
not a requirement for section 8 (forwarding burdened) metrics. )

> & lastly, what about the proposed text for section 4.1 that I included in my
> last email?  should I just leave that bit out if section 3.1 is flushed out
> a bit?
> 
> thanks
> 
> d.

I think that if the generalized procedural step regarding DUT
priming is added, you don't need to replicate it in section 4.1.

-Kevin

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

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 03 Sep 2002 10:46:33 -0400

-Kevin