Community-Lab introduction

Check-in [b7b5e1df07]
Login
Overview
Comment:Turn narrative of experiments support upside-down.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk | cnbub-2012-1.1.0
Files: files | file ages | folders
SHA1: b7b5e1df078938171c14702a67ff86fcdc32fe40
User & Date: ivan on 2012-10-08 00:12:19
Other Links: manifest | tags
Context
2013-01-14
13:33
Update subtitle, testbed and node architecture diagrams and copyright years. check-in: 7b838f07a8 user: ivan tags: trunk
2012-10-08
00:12
Turn narrative of experiments support upside-down. check-in: b7b5e1df07 user: ivan tags: trunk, cnbub-2012-1.1.0
2012-10-07
23:19
Don't zoom over node architecture diagram. check-in: 0a9f73abee user: ivan tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Modified script.txt from [62be460f20] to [6c76a054b8].

134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
      isolation and node stability.
    - uses traffic control, filtering and anonymization to ensure network
      stability, isolation and privacy (partialy implemented).
- The recovery device (not implemented) can force a remote hardware reboot of
  the RD in case it hangs.  It also helps with upgrade and recovery. *##*

* Experiments support
# Axel: Turn around as of mail: from PoV of researcher: 1) testbed through API, choose nodes, 2) login OoB, 3) auto creation, 4) specific interfaces.
Researchers can configure slivers with different types of network interfaces
depending on the connectivity needs of experiments.  For instance, to *##*

- mimic a home PC: use the private interface, *##* which has L3 traffic
  forwarded using NAT to the CN but filtered to ensure network stability. *##*
- implement a network service: create a public interface, *##* which has a CN
  address and L3 traffic routed directly to the CN but filtered to ensure
  network stability. *##*
- experiment with routing algorithms: create an isolated interface, *##* which
  uses a VLAN on top of a direct interface.  All L2 traffic is allowed, but
  only between other slivers of the same slice with isolated interfaces on the
  same physical link.

These were demonstrated with BitTorrent and mesh routing experiments at IEEE
P2P'12 Conference.  *##* Future support is also planned for experiments that:

- analyze traffic: create a passive interface *##* to capture traffic on a
  direct interface, which is filtered and anonymized to ensure network
  privacy. *##*
- perform low-level testing: *##* the sliver is given free raw access to a
  direct interface.  For privacy, isolation and stability reasons this should
  only be allowed in exceptional occasions. *##*

Besides experiments run in slices, researchers will soon be able to collect
link quality and bandwidth usage measurements of all RDs' interfaces through
the DLEP protocol. *##*

Moreover, the server and nodes will soon publish management information
through an API that can be used to study the testbed itself, or to implement
external services like node monitoring and selection.

** An example experiment
to show how the testbed works.  We'll create two slivers which ping each
other. *##*

1. The researcher first contacts the server and registers a slice description
   which specifies a template for slivers (e.g. Debian Squeeze) and includes







|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<
<
<







134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168



169
170
171
172
173
174
175
      isolation and node stability.
    - uses traffic control, filtering and anonymization to ensure network
      stability, isolation and privacy (partialy implemented).
- The recovery device (not implemented) can force a remote hardware reboot of
  the RD in case it hangs.  It also helps with upgrade and recovery. *##*

* Experiments support
These testbed and node architectures offer varied support for experiments. *##*

- Researchers can query testbed management information via server and node
  APIs.  This can help them implement external services to help monitor and
  choose the most appropriate nodes. *##*
- Researchers can log into their running slivers using SSH out-of-band access
  against the node to run arbitrary programs. *##*
- A researcher can use a sliver as a home PC with L3 traffic forwarded using
  NAT to the CN but filtered to ensure network stability. *##*
- A researcher can offer a network service in a sliver by using a public
  interface, which has a CN address and L3 traffic routed directly to the CN
  but filtered to ensure network stability. *##*
- Routing experiments can use an isolated interface in a sliver, which uses a
  VLAN on top of a direct interface.  All L2 traffic is allowed, but only
  between other slivers of the same slice with isolated interfaces on the same
  physical link. *##*

These were demonstrated with BitTorrent and mesh routing experiments at IEEE
P2P'12 Conference.  *##* Future support is also planned for experiments that:

- analyze traffic: using a passive interface to capture traffic on a direct
  interface, which is filtered and anonymized to ensure network privacy. *##*
- perform low-level testing: the sliver is given free raw access to a direct
  interface.  For privacy, isolation and stability reasons this should only be
  allowed in exceptional occasions. *##*

Also, researchers will soon be able to collect link quality and bandwidth
usage measurements of all RDs' interfaces through the DLEP protocol. *##*




** An example experiment
to show how the testbed works.  We'll create two slivers which ping each
other. *##*

1. The researcher first contacts the server and registers a slice description
   which specifies a template for slivers (e.g. Debian Squeeze) and includes

Modified slides.svg from [588d09f7be] to [a52fbaac08].

cannot compute difference between binary files