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
>>>
>>>
>>>
>>>
>>>
>>>    
>>
>>  
>