Changes between Version 3 and Version 4 of Deter/NewExDesc

Timestamp:

Sep 16, 2010 1:18:03 PM (14 years ago)

Author:

sunshine

Comment:

--

Deter/NewExDesc

@@ -25 +25 @@
 User comes to the testbed with some research hypothesis - "my worm can spread to all vulnerable machines in the network in 10 seconds provided that fan in/out is at least 3". 
 
-Starting from metadescription the system should be able to select a set of models for each dimension that satisfy relevant invariants. These models are shown as options to the user to choose from and parametrize. This interaction with the user is called '''experiment design''' (used to be '''template''' in June'10). During the design phase a user may decide they need another dimension or another model for an existing dimension. These should then be added to the metadescription.
+Starting from metadescription the system should be able to select a set of models for each dimension that satisfy relevant invariants. These models are shown as options to the user to choose from and parametrize. This interaction with the user is called '''experiment design''' (used to be '''template''' in June'10). Almost any choice should be coupled with a default value so that users can just accept defaults and run the experiment, while other users may decide to change the selection or parametrize it differently. During the design phase a user may decide they need another dimension or another model for an existing dimension. These should then be added to the metadescription.
 
 Making a selection for one dimension may reduce choices for other dimensions - this is where the system checks constraints against each other and against invariants and only keeps valid combinations around. 
 
+=== Experiment Start ===
 
+Based on user's choices the system generates the topology file and a '''set of scripts''' (SEER or others) that are directly runnable on the testbed (in June'10 we called this a '''recipe''').
+
+=== Experiment Runtime ===
+
+A '''validity monitor''' (experiment health) is always collecting data and making sure invariants hold. Users may define an empty workflow and experiment manually like now, or start with a workflow and manipulate it on the fly or start with a workflow and insert manual events into the stream. Once an invariant is violated we may or may not be able to tell the user exactly why this happened but we should be able to localize time/location where the failure occurred and provide logs for further analysis.
+
+Any monitors selected by the user in the design stage are also running, as is any processing of that data and visualization.
+
+=== Post Experiment ===
+
+Visual