Nabble - GENI Experiment Workflow and Services WG

Notes from the Experimenter Services and Tools WG.

2009-11-25T14:12:23Z

The Experimenter Workflow Tools and Services Working Group met on 17
November 2009 at the GEC held in Salt Lake City, Utah.

Vic Thomas, the GPO systems engineer supporting this WG, introduced the new
working group chairs (Prof. Jeannie Albrecht of Williams College and Prof.
James Griffioen of the U. of Kentucky) and thanked them for agreeing to
chair the WG. Vic went over the charter of the working group, documents
produced to date by the WG, and WG plans for Spiral 2.

In Spiral 2 of GENI the WG will focus on identifying tools and services
needs of the experiments planned for this spiral. The WG meeting agenda was
designed to understand the needs of the experimenters and assess how well
these needs are being met or will be met by tool and control framework
developers.

The first presentation at the meeting was by JongWon Kim who described a
service composition experiment on the Korean FIRST testbed.

This was followed by four talks by researchers planning on doing experiments
on GENI or building services that live within a GENI slice and hence look a
lot like experiments. The WG chairs, Jeannie and Jim, had asked the
speakers to provide a concise summary of their experiments and then talk
about their "experimentation requirements". In particular, they were asked
to address four possible dimensions of the "experiment space":
- Duration: Is the intended experiment short-lived (e.g., requiring more
interactive features) or long-lived (e.g., requiring (error) event
notification rather than interactive support)?
- Layering: What layer of abstraction does the experiment want to
control? (e.g., does it need to control the topology and link
characteristics? or does it need to completely replace IP with a new packet
format and router processing? does it need to control/install in-network
transport services e.g., retransmission or encryption, or ... service? or
does it need to control placement of application-level (e.g., P2P) services?
etc)?
- Domain: What type(s) of resources does the experiment need? (e.g.,
wireless, wired, mobile, sensor, storage, ..., or some combination)
- Scale: How many resources comprise the experiment? (e.g., very large
experiments will need tools that help manage large sets of resources
collectively rather than individually; whereas small experiments may want
tools that interact with each resource individually).

Felix Wu described his experiment "Davis Social Links" that plans on hosting
Facebook applications on GENI. Needs he identified included support for
24x7 operations, ability to quickly grow or shrink a slice to adapt to
quickly changing resource requirements of the applications, the ability to
load custom OS images onto nodes and the ability to replace the IP-based
Layer 3 protocols with his own Layer 3 protocol and routing mechanisms.

Emmanuel Cecchet described the data intensive applications being developed
by his group. These applications involve high bandwidth sensors such as
weather radars. He pointed out the need for large amounts of storage with
high-bandwidth access from the testbed. Cloud storage may not be suitable
for his applications because of limitations of bandwidth to/from the
storage.

Sonia Fahmy described the shared measurement system she is developing for
GENI. This is an active measurement system and she needs the ability to
install custom probes in or near routers. These probes are intended to
inject and measure traffic close to the routers and core of the network.

Finally, Beth Plale described her service to collect and record provenance
information for GENI experiments: Their lineage or historical trace that can
capture experiment conditions, time ordering, and relationships within the
experiment and across the application and infrastructure layer. The
expectation is much of this information will be inferred and will not be
explicitly provided by the experimenter. Some of this information is
available to the control framework and it would be helpful to be able to get
at this information.

These four talks were followed by panel discussion moderated by Jeannie
Albrecht. The panelists included representatives of each of the four
control frameworks: Ivan Seskar (ORBIT), Rob Ricci (ProtoGENI), Larry
Peterson (PlanetLab) and Jeff Chase (ORCA). The panelists were asked to
address specific needs identified by experimenters. Some needs, such as
supporting 24x7 operations, was deemed by the panel to be outside the scope
of the control framework; experiments but be prepared to deal with failures
of resources used by their experiments. Other needs such as loading of
custom OS images are already supported by some control frameworks. The WG
chairs felt this was the start of a useful dialog and there needs to be more
discussion on specific things the control framework developers can do to
make it easier for experimenters or those developing tools for
experimenters.

The meeting agenda and slides presented at the meeting are at
http://groups.geni.net/geni/wiki/GEC6ServicesWGAgenda.

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Agenda for the Experimenter Services and Tools WG Meeting at the GEC 6.

2009-11-12T19:03:04Z

The agenda for the Experimenter Tools and Services WG meeting has been
posted on the GENI wiki and is available at
http://groups.geni.net/geni/wiki/GEC6ServicesWGAgenda.

The current agenda is as follows (pl. see the wiki for the latest version):

3.30pm - 3.35pm: Introduction to the WG - Vic Thomas
3.35pm - 3.45pm: Service Composition Experiment with FIRST@PC OMX Toolkit
and MediaX Testbed - JongWon Kim
3.45pm - 4.45pm: GENI Experimenters Presentations
3.45pm: Felix Wu - Social Networking Apps and Gaming
4.00pm: Emmanuel or David - Data Intensive Applications
4.15pm: Sonia Fahmy - Shared Measurement Services
4.30pm: TBD
4.45pm - 5.15pm: Control Framework Panel: What we can/can't support
Panelists: Larry Peterson, Rob Ricci, Jeff Chase, Ivan Seskar
5:15pm - 5:30pm: Wrap-up - Outbrief Presentation and Discussion of WG
Findings

< Vic Thomas

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: Experimenter Tools and Services: Spiral 1 Capabilities.

2009-10-12T07:58:50Z

Re: [services-wg] Experimenter Tools and Services: Spiral 1 Capabilities. Justin,

You bring up a good point about including in the document tools such as those from Million Node GENI. The plan for this document was to catalog tools and services available from each of the 5 control frameworks for creating slices, provisioning them and running experiments. We were not thinking of tools from aggregate providers (e.g. Million Node GENI, CMU testbed, Kansei, etc). Correct me if I’m wrong, but tools from an aggregate will primarily be concerned with programming resources (slivers) from that aggregate and with aggregate specific experiment control functions . These tools won’t be used to register and authenticate GENI users, create slices, etc.

That said, many of the aggregates coming into GENI (including Million Node GENI) are standalone testbeds in their own right and already have a suite of experimenter tools. It is a good idea for the Experimenter Workflow Tools and Services WG to look at these tools and borrow concepts/tools from these testbeds. Perhaps this can be something we discuss at one of the upcoming GECs just as we looked at tools/services from the control frameworks at the last GEC.

Others pl. feel free to chime in with your comments/thoughts.

< Vic

On Oct 9 5:51 PM, "Justin Cappos" <justinc@...> wrote:

I don't know if this is intentional or not, but there is a lot of stuff related to Seattle / MillionNodeGENI that isn't included.

Should it be?

Thanks,
Justin

On Fri, Oct 9, 2009 at 2:43 PM, Vicraj Thomas <vthomas@...> wrote:

A survey of Experimenter Tools and Services from each of the Spiral 1
clusters has been posted at
http://groups.geni.net/geni/attachment/wiki/ExperimentLifecycleDocument/Spir
al1-Capabilities-appendix.pdf <http://groups.geni.net/geni/attachment/wiki/ExperimentLifecycleDocument/Spir%0Aal1-Capabilities-appendix.pdf> . This survey will be an appendix to the
Lifecycle of a GENI Experiment document that was published and reviewed
earlier this year.

Pl. review this document and email any comments/suggestions you might have
to me and to this mailing list.

Thanks!

< Vic

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Office: +1 952 545 5721
Mobile: +1 651 373 0287
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Experimenter Tools and Services: Spiral 1 Capabilities.

2009-10-09T14:43:08Z

A survey of Experimenter Tools and Services from each of the Spiral 1
clusters has been posted at
http://groups.geni.net/geni/attachment/wiki/ExperimentLifecycleDocument/Spir
al1-Capabilities-appendix.pdf. This survey will be an appendix to the
Lifecycle of a GENI Experiment document that was published and reviewed
earlier this year.

Pl. review this document and email any comments/suggestions you might have
to me and to this mailing list.

Thanks!

< Vic

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Office: +1 952 545 5721
Mobile: +1 651 373 0287
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

GENI Experimenter Workflow and Services Working Group Meeting at the GEC5.

2009-07-24T11:12:51Z

The Services WG met on Tuesday July 21 at the GEC. The meeting was well
attended with over 30 participants. Meeting participants and speakers were
asked to address the following sets of questions:
- How are experiments specified in each of the Spiral 1 clusters? What
are the declarative and procedural aspects of this specification?
- How is this specification used by the tool chain available to
experimenters?
- What are the experimenter tools in one cluster that might be ported to
other control frameworks?
- What assumptions do tools make about the control framework? What
assumptions might be specific to their control framework?

Many of the tools described at the meeting were, in principle, control
framework independent though porting them to another control framework would
be non-trivial. However some of the tools described at the meeting have
been demonstrated to work with more than one control framework.

The meeting participants were asked to identify issues that cut across
working groups. Three such cross-cutting issues were identified: RSpecs,
experimenter identity and measurement.

Copies of slides presented at the meeting and the WG outbrief on
cross-cutting issues are at
http://groups.geni.net/geni/wiki/Gec5ServicesAgenda.

I thank all who participated in this meeting and encourage those who could
not attend to peruse the slides at the above URL.

< Vic

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Draft Agenda for WG Meeting at GEC5.

2009-07-14T14:43:20Z

Dear colleagues,

The Experimenter Services and Tools Working Group will meet at the upcoming
GEC on Tuesday July 21 from 3.30pm to 5.30pm. Jeff Chase (WG chair) and I
would like this meeting to focus on the following topic areas:
- How are experiments specified in each of the Spiral 1 clusters? What
are the declarative and procedural aspects of this specification?
- How is this specification used by the tool chain available to
experimenters?
- What are the experimenter tools in one cluster that might be ported to
other control frameworks?
- What assumptions do tools make about the control framework? What
assumptions might be specific to their control framework?

To facilitate this discussion we've invited speakers from each of the five
Spiral 1 clusters to give a brief overview of the experimenter tools from
their cluster and to address the above questions for their cluster. We've
set aside 20 minutes for each cluster for presentations and discussions.

The following is a draft agenda for this meeting. Not all speakers have
confirmed their ability to speak at the meeting.
3.30pm - 3.45pm: Goals and deliverables of the WG; Documents status -
Vic Thomas
3.45pm - 4.05pm: ORBIT experimenter tools - Max Ott
4.05pm - 4.25pm: ORCA experimenter tools - Yufeng Xin and David Irwin
4.25pm - 4.45pm: ProtoGENI experimenter tools - Rob Ricci
4.45pm - 5.05pm: PlanetLab experimenter tools - Jeannie Albrecht
5.05pm - 5.25pm: TIED experimenter tools - Ted Faber
5.25pm - 5.30pm: Wrap-up

We'd appreciate your giving some thought to these topics and coming prepared
to participate in the discussions.

Thanks v. much. I look forward to seeing you next week.

< Vic Thomas

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Notes from the review of the Instrumentation and Measurement System project's specification document.

2009-06-18T16:04:22Z

The document mentioned in the email below was reviewed on Tuesday June 16.
The notes from this review meeting are available at
http://groups.geni.net/geni/attachment/wiki/MeasurementSystem/GENI-GIMS-doc-
review-jun09.txt.

My thanks to all the people who read the document and participated in the
review. Special thanks to Mark Corvella for the meeting notes.

If you were not able to participate in the review you are still welcome to
email your comments to the document authors. Pl. copy your comments to the
services working group mailing list (services-wg@...).

Thank you very much!

< Vic

On Jun 5 4:27 PM, "Vicraj Thomas" <vthomas@...> wrote:

> Dear colleagues,
>
> You are invited to participate in a telephone review of the document titled
> "Requirements and Specifications for the Instrumentation and Measurement
> Systems for GENI" by Paul Barford (U. of Wisconsin), Mike Blodgett (U. of
> Wisconsin), Mark Corvella (Boston University) and Joel Sommers (Colgate
> University). The document is available at
> http://groups.geni.net/geni/attachment/wiki/MeasurementSystem/MeasurementSysSp
> ec.pdf.
>
> The review will be on Tuesday June 16 at 2pm ET. Call-in information will be
> sent 3-4 days before the review.
>
> Thanks v. much!
>
> < Vic Thomas

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Call-in information for the review of the Measurement System's project document on Tuesday June 16.

2009-06-11T14:38:41Z

Dear colleagues,

Following is information for the telephone review of the document titled
"Requirements and Specifications for the Instrumentation and Measurement
Systems for GENI" by Paul Barford, Mike Blodgett, Mark Corvella and Joel
Sommers. The review will be led by Joel Sommers.

Review date: Tuesday June 16
Time: 2pm ET
Call-in number & PIN: 866-453-5550 / 4873431#
Document:
http://groups.geni.net/geni/attachment/wiki/MeasurementSystem/MeasurementSys
Spec.pdf

< Vic

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Invitation to the review of the Measurement System's project document.

2009-06-05T14:27:49Z

Dear colleagues,

You are invited to participate in a telephone review of the document titled
"Requirements and Specifications for the Instrumentation and Measurement
Systems for GENI" by Paul Barford (U. of Wisconsin), Mike Blodgett (U. of
Wisconsin), Mark Corvella (Boston University) and Joel Sommers (Colgate
University). The document is available at
http://groups.geni.net/geni/attachment/wiki/MeasurementSystem/MeasurementSys
Spec.pdf.

The review will be on Tuesday June 16 at 2pm ET. Call-in information will
be sent 3-4 days before the review.

Thanks v. much!

< Vic Thomas

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Embedded Real-Time Measurements within GENI

2009-06-01T06:25:10Z

The project group working on "Embedded Real-Time Measurements within
GENI" would like to announce the completion of Milestone 4
(http://groups.geni.net/geni/wiki/Embedded%20Real-Time%20Measurements)
and invite all interested parties to provide comments.

This milestone deals with the development of a measurement framework
based on GENI real-time measurement requirements and other
developments/resources within the GENI prototyping activities.
Interacting with other prototype efforts, we identify and leverage
relevant activities, software architectures, protocols, and products.
This work deals with a number of software architectures dedicated to
network measurements which could serve as an interface between a
unified measurement framework (UMF), the control framework, and the
GENI experimenter. We assess several network management protocols and
data exchange formats with respect to their ability of exchanging
measurement and control information between the substrate's
performance monitors and the UMF, as well as between the UMF and the
GENI control frameworks.

Thank you and best regards
Franz Fidler, Caroline Lai, Keren Bergman

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Updated version of Experiment Lifecycle document posted.

2009-05-08T13:12:42Z

Version 1.2 of the GENI Experiment Lifecycle document has been posted and is
available at http://groups.geni.net/geni/wiki/ExperimentLifecycleDocument.
Also available at this location is a version of the document that shows
changes from Version 1.1.

This version of the document incorporates comments and suggestions made at
the document reviews held on April 17 and 21. Many thanks to those who
participated in the review: Jeff Chase, Rob Ricci, Jeannie Albrecht, David
Irwin, Varun Marupadi, Aaron Falk and Harry Mussman.

Many of the topics discussed at the document review fell in the space where
the experimenter control tools meet the control framework (user
authentication, experiments vs. slices, monitoring liveness of resources
associated with a slice/experiment, etc.). We'll hope to have more clarity
on these topics as the design of the control framework and the needs of
experimenter tools evolve.

Comments on this document are still welcome.

Thank you,

Vic Thomas

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: Review of the Lifecycle of an Experiment Document---Part 2.

2009-04-20T13:10:56Z

Call-in information for the review tomorrow: 1 866 453 5550 / Pin: 4873431#.

On Apr 18 10:50 PM, "Vicraj Thomas" <vthomas@...> wrote:

> We will continue the review of the Lifecycle of an Experiment document on
> Tuesday April 21 from noon to 2pm ET.
>
> The review of the document this past Friday took us to Section 4.3.6 of the
> document. On Tuesday we expect to review the remainder of the document.
>
> On Monday I will email a teleconference bridge number for the review.
>
> You are welcome to join the review on Tuesday even if you could not make the
> last review.
>
> Thanks!
>
> < Vic

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Review of the Lifecycle of an Experiment Document---Part 2.

2009-04-18T20:50:04Z

We will continue the review of the Lifecycle of an Experiment document on
Tuesday April 21 from noon to 2pm ET.

The review of the document this past Friday took us to Section 4.3.6 of the
document. On Tuesday we expect to review the remainder of the document.

On Monday I will email a teleconference bridge number for the review.

You are welcome to join the review on Tuesday even if you could not make the
last review.

Thanks!

< Vic

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Reminder: Review of the GENI Experiment Lifecycle Document.

2009-04-14T10:10:32Z

Dear colleagues,

You are invited to participate in a review of the document titled "Lifecycle
of a GENI Experiment" on Friday April 17 2009 from 10am to 11.45am ET. The
current draft of this document is at
http://groups.geni.net/geni/attachment/wiki/ExperimentLifecycleDocument/Expe
rimentLifeCycle-v01.1.pdf.

Call-in number: 866-453-5550
Participant Pin: 6513886#

I hope you able to join us for this review.

< Vic

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Invitation to the review of the GPO document titled "Lifecycle of a GENI Experiment".

2009-03-27T09:07:26Z

Dear colleagues,

You are invited to participate in a review of the document titled "Lifecycle
of a GENI Experiment" on Friday April 17 2009 at 10am ET. The current draft
of this document is at
http://groups.geni.net/geni/attachment/wiki/ExperimentLifecycleDocument/Expe
rimentLifeCycle-v01.1.pdf.

I will send you a reminder and call-in information a week before the review.
I sincerely hope you are able join us in the review of the document.

Thanks v. much!

< Vic

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Updated Experiment Workflow and Services WG Meeting Agenda.

2009-03-26T15:42:47Z

An updated agenda for the Experimenter Services WG meeting at the upcoming
GEC has been posted at http://groups.geni.net/geni/wiki/GEC4SvcsWGAgenda.
The meeting will take place on Wednesday April 1 from 3.30pm to 5.30pm.

PRELIMINARY Agenda

* Welcome and WG Overview - Jeff Chase, WG Chair (15 mins)

* Lifecycle of an Experiment Document: Overview and Status - Vic Thomas, WG
SE (15 mins)

* Instrumentation and Measurement Framework for GENI - Paul Barford,
University of Wisconsin (15 mins)

* External Measurement Tools for GENI - Deniz Gurkan, University of Houston
(15 mins)

* SILO: A Framework for Composable Software - Ilia Baldine, RENCI (15 mins)

The agenda is designed to allow plenty of time for discussions during and
after talks.

< Vic

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Invitation to present at the Experimenter Workflow and Services WG meeting at the GEC.

2009-03-22T13:45:25Z

Invitation to present at the Experimenter Workflow and Services WG meeting at the GEC. Please let me know as soon as possible if you'd like to make a presentation at the Experimenter Workflow and Services WG meeting at the upcoming GEC. The following are agenda items we have so far (exact talk titles still TBD):

Welcome and WG Overview -- Jeff Chase, WG Chair
Lifecycle of an Experiment Document: Overview and Status – Vic Thomas, WG SE
Instrumentation and Measurement Framework for GENI -- Paul Barford, U. of Wisconsin
External measurement tools for GENI -- Deniz Gurkan, U. of Houston
SILO: A framework for composable software — Ilia Baldine, RENCI

Please let me know by the COB on Monday March 23 if you’d like to be added to this agenda. Even if don’t have a formal presentation we’d appreciate your active participation in the WG meeting.

Thanks!

< Vic

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: [geni-dev] CF Requirements: 3) Slice Controller

2009-03-20T09:56:21Z

Thus spake Jeff Chase on Thu, Mar 19, 2009 at 07:08:03PM -0400:

> Since a key objective is to make GENI easy to use, we want the
> slice/experiment controllers to be easy to program and we want the code
> to be maximally reusable. That is always hard, but declarative
> representations of experiments (like your ExpSpec suggestion) seems the
> right ideal to pursue. Orca's slice controller toolkit is more
> procedurally oriented, so it is rather primitive in that
> respect...unless it is running something like Gush layered above it.
> But that is one area where I think Orbit really excels (cf. Max Ott's
> slides from the GEC 3 services-wg meeting). Gush and Orbit are the
> right places to start from with that, IMHO, unless there are other
> ExpSpecs that I am not yet aware of.

The obvious one missing from your list is the Emulab NS file (based on
NS-2), which in addition to describing network topologies, can also
describe software to distribute, programs to run, packet traces to
gather, etc. and lets you script all this stuff as well. Some
documentation:
http://users.emulab.net/trac/emulab/wiki/nscommands
http://users.emulab.net/trac/emulab/wiki/AdvancedExample

There's also the "Expermenter's Workbench" on Emulab which extends the
above with notions like formal parameters to experiments, a more
complicated experiment structure (for example, breaking up experiments
into potentially multiple "runs"), as well as adding a bunch of other
abstractions:
http://www.cs.utah.edu/flux/papers/workbench-nsdi07-base.html

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: [geni-dev] CF Requirements: 3) Slice Controller

2009-03-19T16:08:03Z

Jeannie,

Your message raises a number of interesting issues about the structure
of slice controllers. I'm cc'ing the services-wg because I think it
points the way for a discussion there about the "ecosystem" of
experiment control tools and how they interface to the control framework.

To answer your question, I do consider Gush to be a "full-blown" slice
controller (SC) in the best way: it serves as the experimenter's primary
interface to the control framework (CF), it is programmable, and it
persists to monitor the slice and adapt it as needed to meet the
experimenter's objectives.

I agree that the SC is largely independent of the underlying CF. For
example, most of the heavy lifting in Gush involves interacting with the
experiment itself and supporting code running within the slivers. That
part is generally independent of the CF.

Even so, the connection to the CF is crucial: from the point of view of
other entities (actors) in the CF, Gush is the thing that issues the
user's requests to obtain resources and launch slivers and stitch them
into a slice. That is why it is important to have a name in the CF to
talk about that thing.

And I prefer the name "slice controller" over "experiment controller"
for that purpose, for two reasons. First, when we talk about it from
the point of view of the CF, we only care about its interactions with
the CF, and those interactions focus on controlling the slice,
independent of any richer experiment control functions it might also
have. Second, it will someday be that not every slice is an experiment.
Anyway, as noted in an earlier message, for GENI there could be many
different experiment control tools involved, but from the point of view
of the CF it seems reasonable to talk about each SC as a single logical
actor, especially if it defines an endpoint for receiving callbacks.

Moving outside of control-wg and into services-wg, we should consider
how tools and functions can be layered above a common programmable SC
core to build more sophisticated controllers that control the experiment
and the slice it runs in together. Gush is a good example that shows
how the programmable toolkit approach can work. I like to think of it
as a single controller actor that has both slice control and experiment
control functions. I persist in thinking of it that way even though the
Gush-over-Orca implementation is a little awkward because Gush is
written in C++ and the Orca core (Shirako) is written in Java, so we had
to run two separate processes and lash them together with XML-RPC.

Since a key objective is to make GENI easy to use, we want the
slice/experiment controllers to be easy to program and we want the code
to be maximally reusable. That is always hard, but declarative
representations of experiments (like your ExpSpec suggestion) seems the
right ideal to pursue. Orca's slice controller toolkit is more
procedurally oriented, so it is rather primitive in that
respect...unless it is running something like Gush layered above it.
But that is one area where I think Orbit really excels (cf. Max Ott's
slides from the GEC 3 services-wg meeting). Gush and Orbit are the
right places to start from with that, IMHO, unless there are other
ExpSpecs that I am not yet aware of.

Jeff

Jeannie Albrecht wrote:

> Hi Jeff,
> Just to make sure I'm understanding your views, would you consider
> Gush a SC? If seems to me that Gush is a slice controller, and if
> that is the case, I also mostly agree with your ideas.
>
> One point that I'd like to emphasize is that I think the functionality
> of the SC should be largely independent of the underlying control
> framework. I realize that we have all been assigned to control
> framework clusters, which may make this difficult, but ultimately I
> feel that the needs of the SC and more generally the
> experimenter/researcher should be an almost entirely separate
> discussion from that of the underlying control framework structure.
> Clearly some of the implementation details (e.g., communication with
> the Clearinghouse) might be tied to a specific control framework in
> the short term, but I believe that a single SC could actually work
> across Clearinghouses. Or maybe there needs to be an Experiment
> Controller that is built on top of a Slice Controller, so the slice
> controller handles only CF-specific actions. (This is basically how
> we've structured Gush to work with both PlanetLab and Orca using the
> same front-end.) Then multiple control frameworks could essentially
> co-exist in GENI, and researchers would only have to know one
> interface/front-end for managing experiments.
>
> As we flesh out the requirements of the SC, at some point we should
> start thinking about what defines a GENI experiment. (Although
> perhaps the experiment workflow working group is a better place for
> that discussion.) We have had numerous discussions on RSpecs, for
> example, but as far as I know we have yet to talk about an ExpSpec
> (experiment specification language). How should a GENI researcher
> define a GENI experiment? I personally believe that one component of
> an ExpSpec is an Rspec, but there are many other factors to consider
> here as well. Similarly, as we move forward with the discussion of
> Slice Controllers, it might be useful to talk about exactly what level
> of control are we defining. I'm assuming that the SC is responsible
> for controlling experiments. Are Experiment Controllers and Slice
> Controllers the same thing, or should they actually be viewed as
> separate components in the GENI architecture?
>
> Jeannie
>
>
>

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: [geni-dev] working group meeting time question

2009-03-19T13:23:47Z

Following up on this... We'll have both wg meetings in parallel, as
planned. There have been a few additional agenda requests for the
service-wg, which should be posted shortly. The meeting rooms are
adjacent so it will be straightforward for folks to move between
meetings if they wish. And there will be an audio archive.

I recognize that having sessions in parallel means that it isn't
possible to attend all meetings. However, it does0 allow meeting time
to have ample face-to-face discussion. There's a tradeoff here and
we'll continue to fine tune it over time. Don't hesitate to send me
your thoughts. Additionally, there's time on the agenda for folks to
give feedback to the GPO on Thursday. Discussion of the agenda
structure is certainly a valid topic for this session.

--aaron

Aaron Falk wrote:

> Folks-
>
> We've heard some rumblings that there is sufficient interest in the
> control-wg agenda that people might not attend the services-wg,
> scheduled to meet at the same time. So, we are considering a little
> meeting agenda bashing.
>
> The control-wg will be discussing RSpecs and security. The agenda for
> the services-wg (as yet unannounced) would probably be a review tools
> and services of the various clusters.
>
> It would be helpful to hear from folks who are definitely interested
> seeing the services-wg meet in Miami.
>
> --aaron
>
>

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

working group meeting time question

2009-03-18T12:22:53Z

Folks-

We've heard some rumblings that there is sufficient interest in the
control-wg agenda that people might not attend the services-wg,
scheduled to meet at the same time. So, we are considering a little
meeting agenda bashing.

The control-wg will be discussing RSpecs and security. The agenda for
the services-wg (as yet unannounced) would probably be a review tools
and services of the various clusters.

It would be helpful to hear from folks who are definitely interested
seeing the services-wg meet in Miami.

--aaron

--
Aaron Falk
Engineering Architect
GENI Project Office
http://www.geni.net, http://groups.geni.net

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Version 1.1 of the Lifecycle of a GENI Experiment Document posted.

2009-03-04T15:21:36Z

Dear colleagues,

I've posted on the GENI wiki an updated "Lifecycle of a GENI Experiment"
document. The most significant addition in this version is a "usage
narrative", a fictional story describing a GENI experiment from its
conception to its archival. This document is at
http://groups.geni.net/geni/attachment/wiki/ExperimentLifecycleDocument/Expe
rimentLifeCycle-v01.0.pdf.

We will schedule a telecon to formally review this document. In the
meanwhile please post any comments you might have to the working group
mailing list (services-wg@...).

Thank you very much.

< Vic

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: two issues of terminology

2009-02-23T23:13:55Z

Yeah, I agree with John on this one, where it runs isn't the right place
to make the distinction.

As an example, Emulab offers a lot of tools that are clearly
experimenter tools - they install software, help launch processes,
distribute events, etc. We have a portal that lets you create slices on
PlanetLab using Emulab, and one of the things that comes along is all
these experimenter tools. They do exactly what you describe below, and
bootstrap themselves inside of the slice. They get installed by
'pushing' them in from outside the slice, and much of the control
infrastructure resides outside, in Emulab, but the tools themselves
pretty clearly run inside the slice.

Thus spake Jeff Chase on Mon, Feb 23, 2009 at 04:42:42PM -0500:
> But that almost suggests that the System Under Test cannot notify the
> experimenter tools (e.g., slice controller) about events within the
> SUT.

Yeah, this is definitely a weakness with this definition, but maybe it
points out the place (roughly) where something crosses from a pure
experimenter tool and starts blurring into a programming tool.

> - An "experiment tool" is a tool that manages a slice on the
> experimenter's behalf, but does not run within a sliver or produce code
> that runs within a sliver. That sort of makes sense...certainly a
> slice can't pull itself up by its own bootstraps, i.e., the code that
> initially sets up a slice can't run within any of the slice's slivers.
> Experiment tools should strive to be general across many
> component/sliver technologies, although they will have to "talk about"
> various component/sliver technologies, i.e., they might have to produce
> and consume various metadata or representations.

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: two issues of terminology

2009-02-23T21:30:44Z

I agree there's a distinction in here somewhere, but I think it's
more functional than where code runs. DETER has an experiment control
tool that closely matches Jeff's last paragraph - implemented as a
distributed agent system (agents generally run in slivers, could also
run "under" them) with a front end (runs outside silvers) and some
other outside-sliver mechanism. Much of the tool is common to any
technology; some of the agents would be technology-specific. Etc.

So the brightest line around seems to me to be Vic's "program slivers
or to manage experiments" - all else is -awfully- flexible..

--john

At 4:42 PM -0500 2/23/09, Jeff Chase wrote:

>It seems we all agree that there is a useful distinction between
>"programming tools" and "experimenter tools" for a slice. And we're
>still trying to pin down the exact nature of the distinction.
>
>IMHO, we shouldn't work too hard to make the definition precise, because
>there is no bright line. There may be tools that cross whatever line we
>draw. This definition seems pretty good:
>
>Robert P Ricci wrote:
>> ...
>> An experimenter tool *sets up* the environment in which a system under
>> test runs, a programming tool is (may be?) *part* of that environment.
>>
>> More specific, but maybe not quite right:
>>
>> A programming tool is one that is in the "codepath" (broadly defined) of
>> the system under test - that is, it's directly involved in the
>> experiment because my application calls it as a library, makes syscalls
>> into it, sends packets through it, etc. An experimenter tool is outside
>> this codepath in that the interaction is one way - the experimenter tool
>> might "call into" the SUT to start it, modify its configuration, etc,
>> but the SUT doesn't "call into" the experimenter tool. (And in the case
>> of collaboration tools and similar things, the tool may never really
>> interact with the SUT at all.)
>>
>>
>But that almost suggests that the System Under Test cannot notify the
>experimenter tools (e.g., slice controller) about events within the
>SUT. We can dodge that by saying that the SUT exposes/publishes events
>and the external controller subscribes to those events, so that the SUT
>does not have to invoke the controller or know about it. But that just
>encapsulates the line in a publish/subscribe system somewhere. (Not
>that there's anything wrong with that.)
>
>To me it seems most straightforward to think in terms of where code
>runs, something like so:
>
>- A "programming tool" consists of or produces
>(creates/generates/combines/links) code to run within some sliver.
>Different component/sliver technologies might come with their own
>programming tools or libraries of off-the-shelf programs or modules
>specific to those kinds of slivers. That's one reason why the
>distinction seems useful: so we can talk about programming tools for
>specific kinds of components or slivers. (Of course, the programming
>tool itself could run anywhere.)
>
>- An "experiment tool" is a tool that manages a slice on the
>experimenter's behalf, but does not run within a sliver or produce code
>that runs within a sliver. That sort of makes sense...certainly a
>slice can't pull itself up by its own bootstraps, i.e., the code that
>initially sets up a slice can't run within any of the slice's slivers.
>Experiment tools should strive to be general across many
>component/sliver technologies, although they will have to "talk about"
>various component/sliver technologies, i.e., they might have to produce
>and consume various metadata or representations.
>
>I emphasize again that it's not a bright line. I could imagine an
>experiment tool that does some management or control that is specific to
>a particular kind of sliver and/or comes with an agent that runs within
>specific sliver types. And we all want long-running slices to be
>self-monitoring and self-managing, so there could be families of tools
>for programming some kind of reflection into slices---what are they?
>One reason to draw the line is to make it more interesting to cross it.
>
>Jeff
>
>
>_______________________________________________
>services-wg mailing list
>services-wg@...
>http://lists.geni.net/mailman/listinfo/services-wg

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: two issues of terminology

2009-02-23T13:42:42Z

It seems we all agree that there is a useful distinction between
"programming tools" and "experimenter tools" for a slice. And we're
still trying to pin down the exact nature of the distinction.

IMHO, we shouldn't work too hard to make the definition precise, because
there is no bright line. There may be tools that cross whatever line we
draw. This definition seems pretty good:

Robert P Ricci wrote:

> ...
> An experimenter tool *sets up* the environment in which a system under
> test runs, a programming tool is (may be?) *part* of that environment.
>
> More specific, but maybe not quite right:
>
> A programming tool is one that is in the "codepath" (broadly defined) of
> the system under test - that is, it's directly involved in the
> experiment because my application calls it as a library, makes syscalls
> into it, sends packets through it, etc. An experimenter tool is outside
> this codepath in that the interaction is one way - the experimenter tool
> might "call into" the SUT to start it, modify its configuration, etc,
> but the SUT doesn't "call into" the experimenter tool. (And in the case
> of collaboration tools and similar things, the tool may never really
> interact with the SUT at all.)
>
>

But that almost suggests that the System Under Test cannot notify the
experimenter tools (e.g., slice controller) about events within the
SUT. We can dodge that by saying that the SUT exposes/publishes events
and the external controller subscribes to those events, so that the SUT
does not have to invoke the controller or know about it. But that just
encapsulates the line in a publish/subscribe system somewhere. (Not
that there's anything wrong with that.)

To me it seems most straightforward to think in terms of where code
runs, something like so:

- A "programming tool" consists of or produces
(creates/generates/combines/links) code to run within some sliver.
Different component/sliver technologies might come with their own
programming tools or libraries of off-the-shelf programs or modules
specific to those kinds of slivers. That's one reason why the
distinction seems useful: so we can talk about programming tools for
specific kinds of components or slivers. (Of course, the programming
tool itself could run anywhere.)

- An "experiment tool" is a tool that manages a slice on the
experimenter's behalf, but does not run within a sliver or produce code
that runs within a sliver. That sort of makes sense...certainly a
slice can't pull itself up by its own bootstraps, i.e., the code that
initially sets up a slice can't run within any of the slice's slivers.
Experiment tools should strive to be general across many
component/sliver technologies, although they will have to "talk about"
various component/sliver technologies, i.e., they might have to produce
and consume various metadata or representations.

I emphasize again that it's not a bright line. I could imagine an
experiment tool that does some management or control that is specific to
a particular kind of sliver and/or comes with an agent that runs within
specific sliver types. And we all want long-running slices to be
self-monitoring and self-managing, so there could be families of tools
for programming some kind of reflection into slices---what are they?
One reason to draw the line is to make it more interesting to cross it.

Jeff

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: two issues of terminology

2009-02-20T14:46:20Z

Thus spake Vicraj Thomas on Thu, Feb 19, 2009 at 11:19:43AM -0600:
> I propose:
> - We distinguish between programming tools and experimenter tools
> - The distinction is not based on whether the tools run inside a slice
> or outside. Rather the distinction is based on whether the tool is used to
> program slivers or to manage experiments. (I realize this isn't a precise
> distinction---I'll try to come up with something better.)
> - Experimenter tools include provisioning tools, experiment control
> tools, instrumentation tools, collaboration tools, etc..

I think this definition is basically going in the right direction. Let
me take a couple tries at alternate versions.

Still vague:

An experimenter tool *sets up* the environment in which a system under
test runs, a programming tool is (may be?) *part* of that environment.

More specific, but maybe not quite right:

A programming tool is one that is in the "codepath" (broadly defined) of
the system under test - that is, it's directly involved in the
experiment because my application calls it as a library, makes syscalls
into it, sends packets through it, etc. An experimenter tool is outside
this codepath in that the interaction is one way - the experimenter tool
might "call into" the SUT to start it, modify its configuration, etc,
but the SUT doesn't "call into" the experimenter tool. (And in the case
of collaboration tools and similar things, the tool may never really
interact with the SUT at all.)

--
/-----------------------------------------------------------
| Robert P Ricci <ricci@...> | <ricci@...>
| Research Associate, University of Utah Flux Group
| www.flux.utah.edu | www.emulab.net
\-----------------------------------------------------------

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Re: two issues of terminology

2009-02-19T09:19:43Z

Jeff,

I understand the distinction you are making. There are tools and frameworks
an experimenter may use to program slivers of components. These include
programming language compilers/interpreters, FPGA programming tools,
frameworks such as SILO and x-kernel, and even debuggers. These are your
"programming tools".

Then there are tools that an experimenter uses to deploy, control, monitor
and instrument experiments and even tools to collaborate with other
experimenters. These are your "experimenter's tools" or "experiment control
tools".

I agree it is useful to distinguish the two types of tools. I think of
"programming tools" as being very specific to the technology used to
implement the component being slivered and to the technology being
investigated by the experiment. These tools may or may not run within a
slice.

"Experimenter tools" on the other hand are mostly independent of the
technology of the components (or slivers) used by the experiment. They
operate at the level of a slice or sliver and don't particularly care about
how the sliver was programmed. I say "mostly independent" since some tools
such as provisioning tools will likely need to know if they are installing
software in a machine with an OS or loading FPGA configuration files.
However the level of abstraction seen by all experimenters is roughly the
same and is independent of the technology used to implement the components
or the technology being studied. These tools may run inside a slice or
outside or both.

I propose:
- We distinguish between programming tools and experimenter tools
- The distinction is not based on whether the tools run inside a slice
or outside. Rather the distinction is based on whether the tool is used to
program slivers or to manage experiments. (I realize this isn't a precise
distinction---I'll try to come up with something better.)
- Experimenter tools include provisioning tools, experiment control
tools, instrumentation tools, collaboration tools, etc..
- The focus of GENI be on experimenter tools. There are, in addition,
operations and management tools of course but that's the OMIS WG's problem.
:-)

The Experiment Lifecycle document focuses on "Experimenter Tools". The
document says a resource's Rspec may have pointers to tools and techniques
for programming the resource (i.e. Programming Tools). The Resource
Discovery experimenter tool that is used to find resources suitable for an
experiment may read this Rspec and point the experimenter to relevant
programming tools.

Comments?

< Vic

On Feb 18 11:30 AM, "Jeff Chase" <chase@...> wrote:

> Vic, thanks, I'm nodding my head at the rough-cut taxonomy in your
> e-mail. But I think it illustrates exactly the distinction I was trying
> to make, and the need for that distinction. In particular, you said:
>
> Vicraj Thomas wrote:
>> - Provisioning tools. These are the first category of tool you mention
>> in your email and is used to program components: Load software into
>> components and configure them. Raven is an example of such a tool for the
>> PlanetLab control framework.
>>
> But no! Raven loads code into a sliver, but it is not a tool(kit) to
> create that code. So it is distinct from the first category of tool
> that I mentioned in my e-mail. SILO, Click, x-kernel, etc., are
> toolkits for creating programs that will run inside slivers/slices. For
> example, they might include libraries of off-the-shelf operators and so
> on that are useful in programming certain kinds of components (e.g.,
> routers or edge stack implementations), and various ways of combining
> those operators and coordinating them to create a program. Then Raven
> (or whatever) loads the program into the sliver.
>
> If we consider that distinction, then all of the categories in your
> taxonomy are tools that run outside of a slice. Raven runs outside of
> a slice. And my view is that "experiment control tools" or
> "experimenter tools", e.g., as we use the term in the CF docs, should
> include all the things in your list but exclude the distinct category of
> programming tools, the first category in my e-mail. It is a useful
> distinction.
>
> [There are some interesting examples that cross the boundary of course
> (e.g., for feedback-driven slice adaptation), which comes back to the
> second point about "slice controller". In general, any of these tools
> that run "outside" a slice might have some minimal hooks "inside" the
> slice. Analogy: "VMware tools" if you have ever worked with VMware.]
>
> Also, I note that GUSH has elements of your first two categories:
> resource discovery, and provisioning. At least it acts as the client
> side for those services. My point is that the distinction between
> "experimenter tools" and "experiment control tools" (as a subcategory)
> seems less useful to me.
>
> Jeff
>> - Experiment control tools: These are the second category of tools you
>> mention in your email. GUSH is an example of such a tool.
>>
>> I include other tools under "Experimenter Tools" such as:
>> - Debugging tools
>> - Collaboration tools for use by researchers based in different
>> locations
>> - Search tools to find resources
>>
>> < Vic
>>
>>
>>
>> On Feb 17 12:41 PM, "Jeff Chase" <chase@...> wrote:
>>
>>
>>> Folks,
>>>
>>> Two quick questions/proposals on terminology. These might be comments
>>> for the CF requirements doc. But they have also come up in drafting
>>> spiral 2 proposals.
>>>
>>> Both deal with what has been called "experimenter tools" or "experiment
>>> control tools" in various GENI docs.
>>>
>>> (1) There is a useful distinction between code that runs inside a slice
>>> vs. code that runs outside a slice. Code that runs inside a slice
>>> falls under the category of "component programming" and the
>>> programmability requirement (S 5.5.5 in the CF requirements doc). The
>>> question is: do we have an accepted name for toolkits or other
>>> off-the-shelf software artifacts whose purpose is to support
>>> easy/flexible programming of various components? An example from the
>>> literature might be Click or Ilia's SILO framework. The specific
>>> question that drove this concerns whether it is right to refer to SILO
>>> as "experimenter tools". I would argue that we should not consider
>>> these as "experimenter tools" so as not to blur this useful distinction.
>>>
>>> (2) I think we have reached some kind of consensus (within services-wg
>>> and I think in my discussions with GPO folks) for a first-class
>>> entity/actor that controls and monitors a slice. I think Gush is
>>> perhaps the best-known example. The defining element that makes such an
>>> entity "first-class" is that it is persistent so that other actors in
>>> the control framework, or slivers in its slice, can send unsolicited
>>> messages/notifications to it. And it may respond by taking autonomous
>>> actions to control the slice on behalf of an experimenter. Previously
>>> we haven't had a name for this entity. I propose that it be called
>>> "slice controller". (Note: in Orca-world we presume/require/support
>>> such a beast: we have called it "service manager" since the SHARP days
>>> in 2003, and then started talking about "guest controller" plugin to the
>>> SM that implements a control policy.) The specific question that drove
>>> this is whether we will be understood by GPO if we say "slice
>>> controller". I think David Irwin had told me he though Harry's
>>> preferred term was "experiment controller", but I'm not seeing any
>>> "controller" term now in the CF req doc.
>>>
>>> Jeff
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

FW: two issues of terminology

2009-02-18T15:10:47Z

------ Forwarded Message

> From: Jeff Chase <chase@...>
> Date: Wed, 18 Feb 2009 12:30:44 -0500
> To: Vicraj Thomas <vthomas@...>
> Cc: Harry Mussman <hmussman@...>, Aaron Falk <falk@...>, ibaldin
> <ibaldin@...>
> Subject: Re: two issues of terminology
>
> Vic, thanks, I'm nodding my head at the rough-cut taxonomy in your
> e-mail. But I think it illustrates exactly the distinction I was trying
> to make, and the need for that distinction. In particular, you said:
>
> Vicraj Thomas wrote:
>> - Provisioning tools. These are the first category of tool you mention
>> in your email and is used to program components: Load software into
>> components and configure them. Raven is an example of such a tool for the
>> PlanetLab control framework.
>>
> But no! Raven loads code into a sliver, but it is not a tool(kit) to
> create that code. So it is distinct from the first category of tool
> that I mentioned in my e-mail. SILO, Click, x-kernel, etc., are
> toolkits for creating programs that will run inside slivers/slices. For
> example, they might include libraries of off-the-shelf operators and so
> on that are useful in programming certain kinds of components (e.g.,
> routers or edge stack implementations), and various ways of combining
> those operators and coordinating them to create a program. Then Raven
> (or whatever) loads the program into the sliver.
>
> If we consider that distinction, then all of the categories in your
> taxonomy are tools that run outside of a slice. Raven runs outside of
> a slice. And my view is that "experiment control tools" or
> "experimenter tools", e.g., as we use the term in the CF docs, should
> include all the things in your list but exclude the distinct category of
> programming tools, the first category in my e-mail. It is a useful
> distinction.
>
> [There are some interesting examples that cross the boundary of course
> (e.g., for feedback-driven slice adaptation), which comes back to the
> second point about "slice controller". In general, any of these tools
> that run "outside" a slice might have some minimal hooks "inside" the
> slice. Analogy: "VMware tools" if you have ever worked with VMware.]
>
> Also, I note that GUSH has elements of your first two categories:
> resource discovery, and provisioning. At least it acts as the client
> side for those services. My point is that the distinction between
> "experimenter tools" and "experiment control tools" (as a subcategory)
> seems less useful to me.
>
> Jeff
>> - Experiment control tools: These are the second category of tools you
>> mention in your email. GUSH is an example of such a tool.
>>
>> I include other tools under "Experimenter Tools" such as:
>> - Debugging tools
>> - Collaboration tools for use by researchers based in different
>> locations
>> - Search tools to find resources
>>
>> < Vic
>>
>>
>>
>> On Feb 17 12:41 PM, "Jeff Chase" <chase@...> wrote:
>>
>>
>>> Folks,
>>>
>>> Two quick questions/proposals on terminology. These might be comments
>>> for the CF requirements doc. But they have also come up in drafting
>>> spiral 2 proposals.
>>>
>>> Both deal with what has been called "experimenter tools" or "experiment
>>> control tools" in various GENI docs.
>>>
>>> (1) There is a useful distinction between code that runs inside a slice
>>> vs. code that runs outside a slice. Code that runs inside a slice
>>> falls under the category of "component programming" and the
>>> programmability requirement (S 5.5.5 in the CF requirements doc). The
>>> question is: do we have an accepted name for toolkits or other
>>> off-the-shelf software artifacts whose purpose is to support
>>> easy/flexible programming of various components? An example from the
>>> literature might be Click or Ilia's SILO framework. The specific
>>> question that drove this concerns whether it is right to refer to SILO
>>> as "experimenter tools". I would argue that we should not consider
>>> these as "experimenter tools" so as not to blur this useful distinction.
>>>
>>> (2) I think we have reached some kind of consensus (within services-wg
>>> and I think in my discussions with GPO folks) for a first-class
>>> entity/actor that controls and monitors a slice. I think Gush is
>>> perhaps the best-known example. The defining element that makes such an
>>> entity "first-class" is that it is persistent so that other actors in
>>> the control framework, or slivers in its slice, can send unsolicited
>>> messages/notifications to it. And it may respond by taking autonomous
>>> actions to control the slice on behalf of an experimenter. Previously
>>> we haven't had a name for this entity. I propose that it be called
>>> "slice controller". (Note: in Orca-world we presume/require/support
>>> such a beast: we have called it "service manager" since the SHARP days
>>> in 2003, and then started talking about "guest controller" plugin to the
>>> SM that implements a control policy.) The specific question that drove
>>> this is whether we will be understood by GPO if we say "slice
>>> controller". I think David Irwin had told me he though Harry's
>>> preferred term was "experiment controller", but I'm not seeing any
>>> "controller" term now in the CF req doc.
>>>
>>> Jeff
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>

------ End of Forwarded Message

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

FW: two issues of terminology

2009-02-18T15:10:12Z

------ Forwarded Message

> From: Vicraj Thomas <vthomas@...>
> Date: Wed, 18 Feb 2009 10:09:53 -0600
> To: Jeff Chase <chase@...>, Harry Mussman <hmussman@...>
> Cc: Aaron Falk <falk@...>, ibaldin <ibaldin@...>
> Subject: Re: two issues of terminology
>
> Jeff,
>
> I've been using the term "Experimenter Tools" to refer to any tool available
> to the experimenter that makes it easier to use GENI from experimentation.
> These include tools such as:
> - Resource discovery tools
> - Provisioning tools. These are the first category of tool you mention
> in your email and is used to program components: Load software into
> components and configure them. Raven is an example of such a tool for the
> PlanetLab control framework.
> - Experiment control tools: These are the second category of tools you
> mention in your email. GUSH is an example of such a tool.
>
> I include other tools under "Experimenter Tools" such as:
> - Debugging tools
> - Collaboration tools for use by researchers based in different
> locations
> - Search tools to find resources
>
> < Vic
>
>
>
> On Feb 17 12:41 PM, "Jeff Chase" <chase@...> wrote:
>
>> Folks,
>>
>> Two quick questions/proposals on terminology. These might be comments
>> for the CF requirements doc. But they have also come up in drafting
>> spiral 2 proposals.
>>
>> Both deal with what has been called "experimenter tools" or "experiment
>> control tools" in various GENI docs.
>>
>> (1) There is a useful distinction between code that runs inside a slice
>> vs. code that runs outside a slice. Code that runs inside a slice
>> falls under the category of "component programming" and the
>> programmability requirement (S 5.5.5 in the CF requirements doc). The
>> question is: do we have an accepted name for toolkits or other
>> off-the-shelf software artifacts whose purpose is to support
>> easy/flexible programming of various components? An example from the
>> literature might be Click or Ilia's SILO framework. The specific
>> question that drove this concerns whether it is right to refer to SILO
>> as "experimenter tools". I would argue that we should not consider
>> these as "experimenter tools" so as not to blur this useful distinction.
>>
>> (2) I think we have reached some kind of consensus (within services-wg
>> and I think in my discussions with GPO folks) for a first-class
>> entity/actor that controls and monitors a slice. I think Gush is
>> perhaps the best-known example. The defining element that makes such an
>> entity "first-class" is that it is persistent so that other actors in
>> the control framework, or slivers in its slice, can send unsolicited
>> messages/notifications to it. And it may respond by taking autonomous
>> actions to control the slice on behalf of an experimenter. Previously
>> we haven't had a name for this entity. I propose that it be called
>> "slice controller". (Note: in Orca-world we presume/require/support
>> such a beast: we have called it "service manager" since the SHARP days
>> in 2003, and then started talking about "guest controller" plugin to the
>> SM that implements a control policy.) The specific question that drove
>> this is whether we will be understood by GPO if we say "slice
>> controller". I think David Irwin had told me he though Harry's
>> preferred term was "experiment controller", but I'm not seeing any
>> "controller" term now in the CF req doc.
>>
>> Jeff
>>
>>
>>
>>
>>
>

------ End of Forwarded Message

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

FW: two issues of terminology

2009-02-18T15:07:54Z

I'm forwarding to this mailing list an email discussion thread started by
Jeff Chase. Please feel free to join the discussion and please include the
mailing list on your emails on this topic.

This is the first of three emails on this thread. I'll forward the other
two shortly.

< Vic

------ Forwarded Message

> From: Jeff Chase <chase@...>
> Date: Tue, 17 Feb 2009 13:41:43 -0500
> To: Harry Mussman <hmussman@...>, Vicraj Thomas <vthomas@...>
> Cc: Aaron Falk <falk@...>, ibaldin <ibaldin@...>, Jeff Chase
> <chase@...>
> Subject: two issues of terminology
>
> Folks,
>
> Two quick questions/proposals on terminology. These might be comments
> for the CF requirements doc. But they have also come up in drafting
> spiral 2 proposals.
>
> Both deal with what has been called "experimenter tools" or "experiment
> control tools" in various GENI docs.
>
> (1) There is a useful distinction between code that runs inside a slice
> vs. code that runs outside a slice. Code that runs inside a slice
> falls under the category of "component programming" and the
> programmability requirement (S 5.5.5 in the CF requirements doc). The
> question is: do we have an accepted name for toolkits or other
> off-the-shelf software artifacts whose purpose is to support
> easy/flexible programming of various components? An example from the
> literature might be Click or Ilia's SILO framework. The specific
> question that drove this concerns whether it is right to refer to SILO
> as "experimenter tools". I would argue that we should not consider
> these as "experimenter tools" so as not to blur this useful distinction.
>
> (2) I think we have reached some kind of consensus (within services-wg
> and I think in my discussions with GPO folks) for a first-class
> entity/actor that controls and monitors a slice. I think Gush is
> perhaps the best-known example. The defining element that makes such an
> entity "first-class" is that it is persistent so that other actors in
> the control framework, or slivers in its slice, can send unsolicited
> messages/notifications to it. And it may respond by taking autonomous
> actions to control the slice on behalf of an experimenter. Previously
> we haven't had a name for this entity. I propose that it be called
> "slice controller". (Note: in Orca-world we presume/require/support
> such a beast: we have called it "service manager" since the SHARP days
> in 2003, and then started talking about "guest controller" plugin to the
> SM that implements a control policy.) The specific question that drove
> this is whether we will be understood by GPO if we say "slice
> controller". I think David Irwin had told me he though Harry's
> preferred term was "experiment controller", but I'm not seeing any
> "controller" term now in the CF req doc.
>
> Jeff
>
>
>
>
>

------ End of Forwarded Message

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Lifecycle of a GENI Experiment document posted.

2009-01-19T14:44:50Z

Dear colleagues,

I've posted the first draft of a document titled "Lifeycle of a GENI
Experiment" on the GENI wiki pages
(http://groups.geni.net/geni/attachment/wiki/ExperimentLifecycleDocument/Exp
erimentLifeCycle-v01.0.pdf). This document describes an experimenter¹s view
of the lifecycle of an experiment in the GENI environment. The objective of
this document is to understand the workflow of the experimenter and identify
tools and services needed to simplify experimentation in GENI.

I'd greatly appreciate your reviewing this document and emailing comments to
this working group mailing list.

Thank you very much.

< Vic Thomas

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

Minutes of the Experimenter Workflow and Services WG Meeting.

2008-11-11T09:40:45Z

Dear colleagues,

The minutes of the Experimenter Workflow and Services WG meeting held at the
GEC 3 are attached to this email. They have also been posted on the WG wiki
(http://groups.geni.net/geni/wiki/GeniServices). Please let me know if I
missed anything in the minutes or misrepresented anybody.

< Vic Thomas

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

ExptSvsWG-minutes.txt (9K) Download Attachment

Experimenter Workflow and Services Working Group: Presentations at the GEC 3.

2008-11-03T21:00:55Z

Dear colleagues,

Thank you for your participation in the Experimenter Workflow and Services
working group session at the GEC last week. Copies of presentations made at
this session are available at
http://groups.geni.net/geni/wiki/presentations.

Jeff Chase and I plan on using this mailing list to continue the discussions
that started at the WG session. Please feel free to start new discussion
threads or to chime in on any on-going discussions.

Best regards,

< Vic

--
Vicraj Thomas, Ph.D.
BBN Technologies, Inc.
5775 Wayzata Blvd, Ste 630
St. Louis Park, MN 55416

Phone: +1 952 545 5721
Fax: + 1 952 545 5727

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

agenda for services-wg@GEC3

2008-10-24T13:54:39Z

Folks, I look forward to seeing you all at GEC 3. Here is a sketchy
agenda for the services WG session on Thursday morning.

Jeff

--------

1. Chase intro (5 minutes)

2. Vic Thomas: intro and highlights of Lifecycle of a GENI experiment.
Objective: Get people thinking about how their ideas and projects
align with or are in conflict with workflow presented, and set up for
discussion of focus issues: slice control, programmability/image
management, and instrumentation. (15 minutes including discussion)

3. Slice control (40 minutes)
-- Jeannie Albrecht (GUSH)
-- Lightning talk on Kansei (Anish Arora or student)

4. Information plane: (60 minutes)
-- Lightning talk (Mark Crovella)
-- Lightning talk on Orbit (Max Ott)
-- Instrumentation Tools (Jim Griffioen)
-- Optical layer measurements (Deniz Gurkan)

5. Programmability and image management (45 minutes)
-- John Hartman (STORK) and discussion
-- Lightning talk: David Irwin on Vise
-- Lightning talk: Larry Lannom of CNRI

6. WG futures (Vic) (15 minutes)
-- recap of experiment lifecycle, other issues
-- System Engineer's role in support of the WG
-- WG deliverables for Spiral 1

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg

onward to GEC3

2008-10-01T08:16:03Z

With the GENI Spiral 1 prototype contracts out, this working group will
be a forum to reconcile various views of the researcher interfaces to
GENI, and the toolsets to extend those interfaces.

Also, we now have a systems engineer supporting the Experiment Services
and Workflow WG: Vic Thomas (see bio below). Among other things, Vic has
been working on the usage scenarios document, a "taxonomy" of researcher
tools and services, and the schedule for the upcoming GEC3. He will also
be working on the security architecture for GENI, which cuts across all
of the working groups.

For the usage scenarios and taxonomy documents, the goal is to trace the
end-to-end "life cycle" of a few specific experiment examples in depth,
in order to flesh out the tools and services needed to support those
examples.

Most of the Spiral 1 projects are built around some ideas about what
those are. So please feel free to send or post your ideas for the most
illuminating usage scenarios and/or the important tools/services to
support them.

In particular, I propose we focus the GEC3 discussions around the Spiral
1 services and interfaces for the first three of the subareas identified
at GEC2:

1. Slice control. The Spiral 1 projects include several efforts to build
controller servers and related tools that run on behalf of a researcher
to construct, deploy, monitor, and adapt slices. The GENI architecture
does not define this entity, but I propose we call them "slice
controllers". They run outside of the slice and do their work by
invoking clearinghouse, component managers, etc. GUSH and Stork in
Cluster B are two notable examples, and Cluster D uses the Orca "guest
controller". What about Cluster A (Deter) and C (ProtoGENI)?

In general, for such tools, how does a user specify an experiment? How
does a user program the slice controller? What other services does a
slice controller interact with? What are their interfaces? What are the
requirements for the control plane interfaces used by the slice controller?

2. Information plane. Several of the Spiral 1 projects deal directly
with instrumentation services for specific groups of components. How
will researchers or slice controllers specify the instrumentation data
they want to collect? How/where will it be stored and made available to
the researcher? How much processing/analysis occurs as the experiment
runs? What tools and interfaces are needed for post-processing? What
data formats will those tools assume?

3. Building blocks. How does a researcher or slice controller specify
the code that will run in the programmable slivers in the slice? How are
code artifacts stored for reuse and sharing with other researchers? How
are they named, typed, certified, rated, etc.? How are they delivered to
the slivers for deployment? What constraints do code artifacts place on
the slivers? How is a sliver "qualified" to run a code artifact?

Clearly there are tight relationships among these three subareas.

I invite representatives of the various Spiral 1 projects, or anyone
else, to chime in here on these questions or others we should focus on
at this stage.

Jeff

Dr. Vicraj (Vic) Thomas expertise lies in the area of highly-dependable
systems, distributed systems protocols and architectures and wireless
sensor networks. Before joining BBN Technologies he was with the
Honeywell Laboratories where he developed technologies related to
wireless networks for flight-essential avionics applications and to the
assessment of the quality of information from sensor networks. Dr.
Thomas was the Industrial Technology Area Leader for the sensors
research area within the US-UK International Technology Alliance (ITA)
program. He has helped define the research area related to the
assessment of the quality of information from sensor networks and will
be co-chairing a workshop on this topic in conjunction with the Mobile
Ad-Hoc Sensors and Systems (MASS) conference. He was the PI for
Honeywell’s DARPA NEST and Ultra*Log projects and was proposal lead for
the Honeywell DARPA CyberPanel project that led to the development of a
very successful aggregator of alerts from intrusion detection systems.
As part of this project he made technical contributions to the IETF
Intrusion Detection Working Group. He has also a systems architect on
the NASA C3I network for the Orion program and a member of the
architecture team responsible for the design of the Boeing FCS SOSCOE
system (middleware for the FCS system of systems). He was the lead
software architect for a NIST funded effort that developed a large
distributed collaboration system for operators in industrial process
control plants. Dr. Thomas has been invited to speak at workshops
including the NSF/Japan Society for the Promotion of Science Workshop on
Sensors, Smart Structures and Mechatronic Systems (Tokyo 2005), the EU
Workshop on Next Generation Sensor Actuator Systems (Edinburg 2007) and
the International Workshop on Cyber-Physical Systems Challenges and
Applications (Santorini 2008).

_______________________________________________
services-wg mailing list
services-wg@...
http://lists.geni.net/mailman/listinfo/services-wg