Changes between Version 67 and Version 68 of ExDescLang

Timestamp:

Oct 20, 2010 4:49:52 PM (14 years ago)

Author:

sunshine

Comment:

--

ExDescLang

@@ -24 +24 @@
    * Additional actions are allowed vs not allowed 
    * An action can(not) be split into multiple smaller pieces that have the same effect
+   * All vs some vs none vs selected objects take some action or undergo a state transition
    * State changes in objects due to some action, at random, due to a timeout ... State changes that generate an action
    * Conditions that lead to state change or to an action
@@ -70 +71 @@
   * Other inputs of the generator, their range of values and their relationship to the parameters from the above two items
 
-= Mapping elements of metadescription to generators during experiment design =
+= Mapping elements of Meta-description to generators during experiment design =
 
+During experiment design the system identifies all the objects and events in the metadescription and tries to map them to possible generators. This mapping should occur by the following formula:
+  * For each object and each event find out what parameters it may have from the parameterization part of the knowledge DB
+  * Highlight those that we actually plan to customize based on the meta-description
+  * Find a set of generators that can customize these parameters (how the customization is done is also important but it's a little vague to me yet how to formalize this part of spec)
+  * Offer these generators to the user with a default option that she can just accept
+  * Each generator's output must be mapped to objects/events in the metadescription. This mapping may be 1-1 as in "we're generating DNS request/reply and that's exactly what's in the meta-description" or it may be N-1 as in "we're generating a topology and some nodes are objects X from the meta-description". We should provide some straightforward mappings such as:
+    * 1-1
+    * random
+    * for Topology type, random among edges or random among nodes of degree X or <X or >X or in between X and Y, or geographic
+Users must have a way to define their own mapping if they want.
+  * Users must have a way to combine meta-descriptions during experiment design just like I did in the examples, or to instantiate one meta-description (or portions of it) multiple times
+  * Users must have a way to define their own events/invariants on top of what we generate automatically
 
+= Experiment record =
 
+What completely describes an experiment is a meta-description plus the user input, i.e., generator selection and parameterization and any customization that happens on top of that. This record can be archived and reused assuming no manual action during an experiment. If there are some manual actions these should be inserted into the "timeline of events" part of the experiment design and this modified record saved.   
+  
 = TODO =
 
- * How is ordering of events defined?
- * What do we denote "all", "each", "none", "some"
- * How do we denote state transitions because of an event, vs. self-initiated, vs. those that emit an event
+ * How do we allow certain generators to generate state in the middle of a meta-description? For example, we can form a P2P network as I described in [BotnetExample] by exchanging messages with potential peers, and then we can send C&C traffic on it. But we can also just have some generator give us a P2P topology. We need a way to say, when we choose the second generator, that this is the same outcome as exchanging messages with potential peers. That is, the fact that peer requests and replies will be missing in the second case does not invalidate the experiment from P2P class of experiments.