Changes between Version 11 and Version 12 of Deter/NewExDesc


Ignore:
Timestamp:
Oct 11, 2010 11:59:20 AM (14 years ago)
Author:
sunshine
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Deter/NewExDesc

    v11 v12  
     1This document sets up the terminology for new experiment design. The language for the design is discussed in [ExDescLang].
     2
    13We start from a class of experiments that we want to define - e.g., DDoS experiments.
    2 
    3 [ExDescLang]
    44
    55=== Metadescriptions ===
    … …  
    99Every metadescription has the following dimensions:
    1010
    11  * topology (could or could not be domain-dependent. we move the domain-dependent part into invariants. for example "cong. control experiments need a common core where congestion occurs.) - LANGUAGE: TopDL with understanding that there's a way to translate this into NS
    12  * invariants (statements that must be true for this class of experiments to be valid, and conditions for this to happen. domain-specific) - LANGUAGE: Arun's DETERmine grammar ss final output but user may interact with a translation of it in English
    13  * actors are defined separately - actors map to topology somehow - there may be additional directives to denote how to do this mapping. For each actor you may choose to use one or many, or you could group them and use one or many actor groups in your experiment (e.g. simultaneous DDoS attacks) - LANGUAGE: TBD but pretty simple
    14  * event timeline (JTW calls this '''workflow''', domain-specific) - LANGUAGE: Arun's DETERmine grammar;
     11 * objects that either act in the experiment or are acted upon (nodes that send traffic, caches that get changed, ...)
     12 * event timeline (JTW calls this '''workflow''') 
     13 * invariants (statements that must be true for this class of experiments to be valid, and conditions for this to happen)
    1514
    16 Some metadescriptions contain more like:
     15Every dimension can have '''constraints''':
     16 * e.g., what topologies work for given objects, what kind of traffic generators can be used to generate traffic in the event timeline, etc.
    1717
    18  * 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. 
    19  * visualization (domain-specific) - LANGUAGE: Pointers to tools, their inputs and outputs
    20  * post-processing (domain-specific) - LANGUAGE: Pointers to tools, their inputs and outputs
    21  * monitors (domain-specific) - LANGUAGE: Pointers to tools, their inputs and outputs
     18Some metadescriptions contain more dimensions, like:
     19
     20 * background traffic
     21 * visualization
     22 * post-processing
     23 * monitors
    2224 * whatever else makes sense for that class of experiments
    2325
    24 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.
     26Each 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. A generator belongs to a '''class''' of generators depending on what it generates. So far we can foresee several classes:
     27 * topology
     28 * traffic
     29 * routes
     30 * malware
     31
    2532
    2633=== Experiment Design ===
    … …  
    3441=== Experiment Start ===
    3542
    36 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''').
     43Based on user's choices the system generates the topology file and a '''set of scripts''' (SEER or Eclipse or something else) that are directly runnable on the testbed (in June'10 we called this a '''recipe''').
    3744
    3845=== Experiment Runtime ===