Changes between Version 8 and Version 9 of Deter/NewExDesc

Timestamp:

Oct 8, 2010 4:05:19 PM (14 years ago)

Author:

sunshine

Comment:

--

Deter/NewExDesc

@@ -3 +3 @@
 === Metadescriptions ===
 
-The highest level is '''metadescription''' of that experiment class. It contains '''dimensions''' that are important to be defined for this class of experiments. Metadescriptions are created by experts in the given research area. Users usually don't touch them or if they do they start from an existing one and modify it. If there's no metadescription in a given field there should be a nice user-friendly process that lets experts create it from scratch by defining the required dimensions and then slowly add to it. Each dimension should allow for multiple choices and their combinations, e.g., multiple topologies connected together, multiple traffic streams, etc.
+The highest level is '''metadescription''' (Steve sometimes calls this '''model''') of that experiment class. It contains '''dimensions''' that are important to be defined for this class of experiments. Metadescriptions are created by experts in the given research area. Users usually don't touch them or if they do they start from an existing one and modify it. If there's no metadescription in a given field there should be a nice user-friendly process that lets experts create it from scratch by defining the required dimensions and then slowly add to it. Each dimension should allow for multiple choices and their combinations, e.g., multiple topologies connected together, multiple traffic streams, etc.
 
 Every metadescription has the following dimensions:
@@ -14 +14 @@
 Some metadescriptions contain more like: 
 
- * traffic (could be domain-specific, depending on type of traffic - mission vs background) - it's a little vague what portion of traffic gets defined in event timeline as opposed to here. We should have an option of defining multiple traffic streams at one place (here) if they are similar. Defining traffic means defining request/reply sizes, timing, content, etc. depending on the model being used for this dimension. If event timeline mentioned specific traffic (e.g., DNS) then here we'd offer models that can generate such traffic - for that particular event. In general we should offer here all models since users may want to generate some background traffic that's noise in the experiment.  
+ * traffic (could be domain-specific, depending on type of traffic - mission vs background) - it's a little vague what portion of traffic gets defined in event timeline as opposed to here. We should have an option of defining multiple traffic streams at one place (here) if they are similar. Defining traffic means defining request/reply sizes, timing, content, etc. depending on the generator being used for this dimension. If event timeline mentioned specific traffic (e.g., DNS) then here we'd offer generators (JTW sometimes calls this '''models''') that can generate such traffic - for that particular event. In general we should offer here all generators since users may want to generate some background traffic that's noise in the experiment.  
  * visualization (domain-specific) - LANGUAGE: Pointers to tools, their inputs and outputs
  * post-processing (domain-specific) - LANGUAGE: Pointers to tools, their inputs and outputs
@@ -20 +20 @@
  * whatever else makes sense for that class of experiments
 
-Each dimension can be output from multiple '''models'''. A model can be as abstract as an equation, or it could be an output of a simulation, or a set of data points, or pretty much anything else. Each model can have '''constraints''' pretty much describing its inputs and outputs such as "this equation creates Internet-like topologies only when they contain more than 50 nodes". Each model has an '''input''' set of variables and an '''output''' one where the output is in some common format (or translatable into it) for that dimension.
+Each dimension can be output from multiple '''generators'''. A generator can be as abstract as an equation, or it could be an output of a simulation, or a set of data points, or pretty much anything else. Each generator can have '''constraints''' pretty much describing its inputs and outputs such as "this equation creates Internet-like topologies only when they contain more than 50 nodes". Each generator has an '''input''' set of variables and an '''output''' one where the output is in some common format (or translatable into it) for that dimension.
 
 === Experiment Design ===
@@ -26 +26 @@
 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). 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.
+Starting from metadescription the system should be able to select a set of generators for each dimension that satisfy relevant invariants. These generators 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 generator 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.