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

Kevin Dubray <kdubray@juniper.net> Tue, 03 September 2002 14:48 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29241 for <bmwg-archive@lists.ietf.org>; Tue, 3 Sep 2002 10:48:00 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83Emro28588; Tue, 3 Sep 2002 10:48:54 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83ElIo28489 for <bmwg@optimus.ietf.org>; Tue, 3 Sep 2002 10:47:18 -0400
Received: from magenta.juniper.net (natint.juniper.net [207.17.136.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29178 for <bmwg@ietf.org>; Tue, 3 Sep 2002 10:45:38 -0400 (EDT)
Received: from juniper.net (ssh.juniper.net [207.17.136.39]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id g83EkbR68886; Tue, 3 Sep 2002 07:46:37 -0700 (PDT) (envelope-from kdubray@juniper.net)
Message-ID: <3D74CB49.1090604@juniper.net>
Date: Tue, 03 Sep 2002 10:46:33 -0400
From: Kevin Dubray <kdubray@juniper.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Debby Stopp <dstopp@ixiacom.com>
CC: bmwg@ietf.org
References: <15FDCE057B48784C80836803AE3598D5265BD4@racerx.ixiacom.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [bmwg] bmwg-mcastm-08.txt: DUT priming
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

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
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg