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