During the discussions with respect to hardware requirements, it was decided to categorise experiments. An initial attempt at this categorisation is available at http://bscw.pangea.org/bscw/bscw.cgi/264404 . However, it turns out that this classification in four categories was not sufficient. Therefore, this page will allow categorisation of experiments in multiple categories.
To do: add your experiments and your categorisation suggestions. Do try to link to your experiment, so the table is not filled with complete experiment descriptions. Below the table is an explication of the different categorisation systems.
|Experiment/category||Active/passive?||Lowest impacted layer||Lowest accessed layer||CPU power and memory footprint||Bandwidth profile||Contact|
|Overlay / Peer-to-peer Networking||2 - Active, good “netizens”||7 - Application||FKIE|
|Application Usability Evaluation||2 - Active, good “netizens”||7 - Application||7 - Application||Embedded/Server/Desktop|
|Application Optimization||2 - Active, good “netizens”||7 - Application||3 - Network||Server/Desktop|
|Delay Tolerant Networking||2 - Active, good “netizens”||7 - Application||3 - Network||Server/Desktop|
|Content Distribution||3 - Active, potentially disturbing||7 - Application||3 - Network||Server/Desktop|
|Transport-Layer Optimization||3 - Active, potentially disturbing||4 - Transport||3 - Network||Embedded/Server/Desktop|
|Transport Protocol Stitching||3 - Active, potentially disturbing||4 - Transport||2 - Link (link info/routing tables)||FKIE|
|Hybrid routing in community networks||4 - Active, conflicting||3 - Network (custom protocol)||3 - Network (routing tables)||Embedded||low rate||iMinds|
|Multi-Topology Routing||4 - Active, conflicting||3 - Network (custom protocol)||3 - Network (routing tables)||Embedded||low rate||FKIE|
|Routing Security||4 - Active, conflicting||3 - Network (custom protocol)||3 - Network||FKIE|
|Link layer feedback mechanisms for routing protocols||4 - Active, conflicting||3 - Network (custom protocol)||2 - Link (MAC information required)||Embedded device||low rate||iMinds|
|Mesh Routing Scalability||4 - Active, conflicting||3 - Network (custom protocol)||2 - Link (link quality information)||FKIE|
|Cross Layer Routing Metrics||4 - Active, conflicting||3 - Network (custom protocol)||2 - Link (link quality information)||FKIE|
|Routing Protocol Auto Configuration||4 - Active, conflicting||3 - Network (custom configuration)||FKIE|
|Heterogeneous but Collaborative Routing||4 - Active, conflicting||3 - Network||2 - Link||Embedded|
|Separation of router and radio device||4 - Active, conflicting||3 - Network||2 - Link (link quality information)||FKIE|
|Router Power Consumption||1 - Passive (or higher)||1 - Physical (measurement HW)||3 - Network||FKIE|
|Policy enforced spectrum sharing||3 - Active, potentially disturbing||1 - Physical (channel switch)||2 - Link (link occupation)||UPC|
|Active Network Measurements||3 - Active, potentially disturbing||FKIE|
|Passive Network Measurements||1 - Passive||FKIE|
As initially suggested by Leandro in http://bscw.pangea.org/bscw/bscw.cgi/d260842-5/*/*/*/*/*/Testbeds-M12-TBD.htm , this categorisation refers to the impact on the community networks. Four categories have been defined:
1) Passive, historic: interested in only historic data extracted from the network (topology over time, aggregated traffic, aggregated load, sample traffic traces, routing logs, routing tables, etc.). These passive/off-line experiments might require an extra (active: active processes collecting data in the nodes or in certain servers within the network) effort to collect data. Good “netizens”. Traces, logs, data might be anonymized before made public. Real world example: On Incentives in Global Wireless Communities (testbed_mapping like but based on public CONFINE traces). Testbed requirement: means to extract info (logs), not necessarily open for any experimenter (only for trusted users that follow specified pre-processing before data is made public)
2) Active, good “netizens”: an experiment that cannot be distinguished from the normal usage of community networks. It uses existing interfaces, does not interfere with production networks. E.g. network performance experiments where a set of nodes make periodic measurements to specific hosts with minimal traffic, similar to http://projectbismark.net/ (testbed_mapping) Testbed requirements: means to deploy software packages/component, either initiated by the node owner or by the experimenter (node leaser).
3) Active, potentially disturbing: an experiment that is beyond normal usage and has the potential to disturb production networks. For instance because it affects lower levels of comms (e.g. channel assignments, address assignments) or generates traffic beyond normal limits (e.g. a stress test of parts of the network). Protection mechanisms may be required (e.g. traffic or CPU resource limits in Planetlab nodes). Real world examples: http://coralcdn.org/ (testbed_1 like). Testbed requirements: similar as above with more control (react to disturbance) …
4) Active, conflicting: needs access to third-party traffic (e.g. an experiment requiring access to data payload/deep-packet-inspection, affecting personal information), or affects key services (e.g. experimentation with DNS, routing tables, address assignments). Isolation (e.g. network virtualization/isolation such as a VPN), Filtering (e.g. an anonymizing intermediary) and containment mechanisms (e.g. any mechanism to protect/isolate the net from the experiment) may be required. Real world examples: an stress test of a new/modified ad-hoc routing protocol such as olsrd. (testbed_2, 3 like). Testbed requirements: similar as above + experiment isolation.
Following the ISO/OSI model, which is the lowest layer impacted by this experiment?
To define impact, consider the link to the node: will it see special L3 packets? New L2 MAC protocols? A different physical layer? A special L4 protocol? A new L7 application?
Following the ISO/OSI model, which is the lowest layer access by this experiment? I.e., which is the lowest layer where information is read from, rather than modified.
To define this, consider which information will be read and not changed. E.g. in cross-layer experimentation, information will frequently be used but only seldom will it be changed.
Which is the scale of required CPU power? Will this be an experiment requiring cluster class CPU power? Or is an embedded device sufficient?
Suggested replies: cluster, desktop, (multimedia) server, embedded device
How much bandwidth will be required over the run of the experiment? Will this experiment be bandwidth intensive or rather use almost no bandwidth?
Suggested replies: bandwidth intensive (specify peak rates), low bandwidth