User Tools

Site Tools


experiments:classes

Experiment categorisation

Introduction

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 Categorisation

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

Categorisation Systems

Active/Passive

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.

Lowest impacted layer

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?

Lowest accessed layer

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.

CPU power and memory footprint

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

Bandwidth profile

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

Conclusions

  1. The higher we get in terms of network layers, the better is the expected network behavior and the more compute power is needed. → Router HW might not need high compute power. Compute power intensive software will mostly run on hosts.
  2. A lot of experiments are concerned with applications and routing, but no experiment so far regards MAC Layer modifications. (NOTE: There might be some interesting experiments from mad-wifi / ath9k developers.)
  3. Many routing experiments need access to link layer information. → It might be a good idea to take a look at the DLEP Protocol (see experiment: “Separation of router and radio device”). We could use this as an abstraction mechanism to access link layer information in the node design.
experiments/classes.txt · Last modified: 2014/04/22 18:21 by esunly