| 14 | | 1. Logical topologies - both at the level of individual nodes or groups of nodes. We are expressing a ''logical'' topology of the experiment where there are '''objects''' that do something in the experiment - generate traffic, change state, hold data, whatever. Whether these objects are individually generated or generated as a group of entities, whether they are physical nodes or virtual, etc. does not matter. The expressiveness should be such that the actual implementation of objects and the cardinality of each object is orthogonal to the topology description. We should however be able to give hints such as "these objects are in the same network or on same physical node or object A resides on object B". These hints are called '''constraints'''. |
| 15 | | 2. Timeline of events - we need to express the ordering of actions that some objects will take in the experiment, their duration, repetition and concurrency. We also need to express state transitions in objects. In some domains this is called a ''workflow''. It could be pre-created in the experiment design stage or it could be generated manually during the experiment (mined from events that happen as user takes manual actions) or a mix of those. Each experiment class must have some default workflow that user can manipulate during experiment design. |
| 16 | | 3. Invariants - we need to express what MUST happen in the experiment for it to be valid. This is not a complete set, just the necessary one. If any of the invariants were violated the experiment would become invalid. Valid here means "for it to belong to a class of experiments whose metadescription we used" plus any other conditions that user wants to impose. There are two types of invariants: |
| | 14 | 1. '''Logical topology''' - both at the level of individual nodes or groups of nodes. We are expressing a ''logical'' topology of the experiment where there are '''objects''' that do something in the experiment - generate traffic, change state, hold data, whatever. Whether these objects are individually generated or generated as a group of entities, whether they are physical nodes or virtual, etc. does not matter. The expressiveness should be such that the actual implementation of objects and the cardinality of each object is orthogonal to the topology description. We should however be able to give '''hints'' such as "these objects are in the same network or on same physical node or object A resides on object B". Here is a rough list of hints we'd like to be able to give: |
| | 15 | * What type of object this is - we need to enumerate all possible types such as Node, Info, DNSRecord, ... As new meta-descriptions and new generators are added type list will grow |
| | 16 | * What is the cardinality of this object - this is just a hint about cardinality. I need to be able to say "this is one of many" vs "one and only one", like in [BotnetExample] I should have many vulnerable hosts, but in [MitmExample] I have exactly two nodes and one attacker in the middle of them. I could have multiple MITM triplets but the minimum size is 1 triplet. |
| | 17 | * Can objects overlap or are they distinct |
| | 18 | * An object is (not) located on another object (e.g., cache on a node) |
| | 19 | * An object is (not) contained in another object (e.g. cache record in cache) |
| | 20 | |
| | 21 | 2. '''Timeline of events''' - we need to express the ordering of actions that some objects will take in the experiment, their duration, repetition and concurrency. We also need to express state transitions in objects. In some domains this is called a ''workflow''. It could be pre-created in the experiment design stage or it could be generated manually during the experiment (mined from events that happen as user takes manual actions) or a mix of those. Each experiment class must have some default workflow that user can manipulate during experiment design. Here is a rough list of things to express here: |
| | 22 | * Parameters of an action |
| | 23 | * An action must happen vs may happen |
| | 24 | * Additional actions are allowed vs not allowed |
| | 25 | * State changes in objects due to some action, at random, due to a timeout ... State changes that generate an action |
| | 26 | * Conditions that lead to state change or to an action |
| | 27 | * One (or none or N) of a number of actions must happen |
| | 28 | * Loops with and without conditions |
| | 29 | |
| | 30 | 3. '''Invariants''' - we need to express what MUST happen in the experiment for it to be valid. This is not a complete set, just the necessary one. If any of the invariants were violated the experiment would become invalid. Valid here means "for it to belong to a class of experiments whose metadescription we used" plus any other conditions that user wants to impose. There are two types of invariants: |
